I mentioned Lazarus in other threads a few days ago (since my kids are playing around with it) and it's great to see it as a top-level post. Some random thoughts:
- It's somewhat amusing to realize that in 2017 this is pretty much the easiest way to do a desktop app (besides RealBasic/Xojo which I've yet to try - was put off by their mandatory registration)
- I wish we had RAD environments like this for more languages (Racket, Python, etc. - even JS).
- On the Mac, installation is a bit fiddly. It needs a little polish and support (a standalone, integrated bundle would be better, or at the very least a unified installer).
- We've been retrofitting web UIs to desktops to such an extent (I'm looking at you, Electron) that the tiny, supremely efficient apps Lazarus spits out put the last couple of years into stark perspective (2GB RAM used by Slack, etc.)
I love Lazarus, and hope it helps resurrect the RAD approach for other languages - if anyone knows of any similar environments (besides QtCreator, etc.), could you share the links?
I've not used Lazarus or Delphi, so I can't really compare properly. Perhaps I'm missing something. But:
> if anyone knows of any similar environments (besides QtCreator, etc.)
Why "besides QtCreator, etc"? It sounds to me almost like "do you know any X besides all of the popular X". Is there any particular reason you discount QtCreator? Does it not work for your purposes? Or is it just a case of you already know about it and want to hear about more obscure tools?
> It's somewhat amusing to realize that in 2017 this is pretty much the easiest way to do a desktop app
I've found Qt with QtCreator to be an incredibly productive way to develop desktop applications. Both old-school QWidgets-based Qt with QtDesigner (the RAD portion of QtCreator for pre-QtQuick) and QtQuick/QML with and without its RAD interface.
> I wish we had RAD environments like this for more languages (Racket, Python, etc. - even JS).
I've used the Python version of Qt with QWidgets in the past and it was a pretty nice workflow. I've never done it personally, but I know of people who use Python + QtQuick/QML and seem pretty happy with it. There's also various "app builder" tools for JS, but I don't know how good they are.
As a Delphi/FPC/Lazarus veteran (10+ years), comparing one of the quickest compilers with Qt/Boost C++ development cycle looks like a joke. Much faster edit-compile cycle which scales without issues up 1e6+ LOC (yes, modules/incremental compilation done right right from the start)
Not apples to apples, but its a pretty good tradeoff for C++ IMO: you get super high turnaround times because the bulk of the UI tweaking cycle is in QML or the RAD tools and you only need slow-compiling-C++ where native performance is required.
For me, while I like fast compile times as much as the next person, its not a deal breaker -- the workflow/environment and library features are. Ie can they easily deliver the required value to my customers. QML gives me a good middle ground between productivity & quick turnaround time, native integration and native performance. If you're unwilling to make that tradeoff, well... then you're limiting yourself to the tools that don't make that tradeoff (which may be perfectly fine, of course).
It's not a good trade off for the end user. As it's not native you end up with a much slower running application with more memory overhead and bloat. Lazarus is compiled to small native applications that are easily installable for the user, fast, with both small memory and disk space usage.
I say this next piece as both a developer and an end user; developers of desktop applications are getting out of hand with how they treat these things. We are now to the point where a large segment of the developer population has so little regard for the end user that they believe bloatware Electron solutions are a good choice for "native" text based chat application.
EDIT: reading your reply to sibling comment, I think I probably misinterpreted what you are referring to here so my below response maybe is replying to the wrong thing.
Regarding your first paragraph, Qt/QML performance is very, very good, memory use isn't insane (in my personal experience at least), rendering is solid 60fps and animations are ultra smooth. Maybe Lazarus is better, but not being a good tradeoff for the user, at least in Qt's case, just isn't true.
Regarding your second paragraph, I completely agree, it those are C++ developers using frameworks like Qt doing that. They're primarily web developers who are using what they're familiar with (JavaScript) to develop desktop applications. An Electron application is very different from a Qt application.
Even with QML, which uses JavaScript, the bulk of the Qt framework is written in C++, the declarative QML is compiled to a scene graph on load, the rendering is done in OpenGL and shaders, and any heavy lifting or performance sensitive code can be done in C++ (Qt makes it VERY easy to call C++ from JS and JS from C++). Typically only non-performance-sensitive glue logic is in JS. This is very different front Electron and Qt (even with QML) is still primarily a C++ framework.
> As it's not native you end up with a much slower running application with more memory overhead and bloat.
For Qt that's just not true: you can reach 1080p / 60fps fluid animated UI on small embedded boards such as raspberry pi's. All the rendering is done using a nifty OpenGL pipeline.
To clarify, I was referring to the language choices here. Comparing Lazarus as opposed to Python in the particular case, as well as referring to even worse performance on Electron/NodeJS.
I certainly was not intending to imply that Qt is not performant as it certainly is. Qt is the default UI for Lazarus applications as well, but it does support other UI toolkits (such as Tk) out of the box.
Because QtCreator isn't up to the job compared even with Delphi 1 for Windows 3.x, but sadly the younger generations never got to use it professionally.
Delphi and Visual Basic, were like the Smalltalk/Lisp Machine (I am exaggerating a bit) of the RAD programming generation.
Try to create a database frontend or image manipulation program in QtCreator just with the GUI designer.
The UI part of a database frontend is trivial and the code is very minimal in Qt (but there still code involved, for sure).
An image manipulation program, what does Delphi provide out of the box for this? I would assume that if you have anything non-trivial, you'd have some custom code to write? I mean, they can hardly have built-in components for every possible use case so I don't have to write any code. What am I missing here?
> Why "besides QtCreator, etc"? It sounds to me almost like "do you know any X besides all of the popular X". Is there any particular reason you discount QtCreator?
I know Lazarus (almost) inside out and i've tried several times to use QtCreator, mainly because C++ would allow me to reuse some of my C code. However i could never get used to how QtCreator expects from me to do more stuff, how unweildy the laying out widgets is (this is natural since Qt's layout management was made expecting programmers to do layouts via code but compared to Lazarus' alignment and anchor based layouts they feel like taking a step back - although the same can be told with Lazarus' layout if you try to do it via code) and other not necessarily big issues but still annoying enough for me to always drop it.
You misunderstood, i meant that the programmers who designed Qt's layout systems expected the programmers who will use Qt would prefer to write code for laying out their UIs (most likely because this is what most UI libraries did and still do) so they designed the APIs with that in mind. I didn't mean that Qt required from them to do it via code.
This is in contrast to Lazarus' layout system, the programmers of which expected ("assumed", "thought", "believed", etc) that the programmers that will use Lazarus will create the UIs using the IDE's UI desiger and so made the layout system be more UI friendly as opposed to code-friendly.
True. Some people may find that as a deal-breaker. Personally, with the age of web-UI's (that look very different from each other and certainly don't look like the native widgets), I don't see QtQuick's native-styled-but-non-native widgets a problem (and the OpenGL-based system has proven to be really great for performant animation).
But I can see that if you require platform-native widgets, QtQuick is probably not an option. I just think that most people don't need this ;-)
I'd argue that at this point, if you're building a desktop application, one of your goals is probably going to be the use of native widgets, which could be for e.g. accessibility concerns. Else you might as well build a web application.
The reasons to use something like Qt instead are many:
- While the widgets aren't platform-native, they emulate the native look and feel, so look a lot more native than your web application. Yes, yes, you likely won't have the accessibility features, so if that's a concern (which it probably should be), sure, Qt and other such libraries won't help. (Note that even MS don't use their own "native" widgets in, eg, Office and Visual Studio, so even within first-party windows applications, you lose consistent look and feel)
- Battery life. A C++ Qt application typically uses much less battery than a similar web application. This may or may not be a concern.
- Smooth animation. QML's OpenGL-based widget rendering has incredibly smooth animation support (and its super easy to add to your applications). Anecdotally, much nicer animations than I've ever seen in web applications.
- Platform access or native libraries. Even though your widgets aren't native widgets, you might still want to manually access platform features or C/native libraries. While some web-applications-in-a-webview tools do allow you to do this, Qt makes it trivial since you can drop down to C++ with ease. With conditional compilation, you can even make this work cross platform.
- Performance. Sometimes you have requirements that simply require C++ performance. Many industrial users of Qt, for example.
- Qt is also used for embedded UI's where a web application may not be feasible.
My point is that there are many reasons why you might choose to use a toolkit like Qt for desktop applications even if you don't need native widgets.
Isn't that a JSON-like language? I find describing UIs in text instead of "drawing" them like done in Lazarus to be going backwards.
Although TBH i haven't really looked into that. Most QtQuick programs i've seen look like something you'd see in a mobile phone or tablet instead of a normal desktop application, so i didn't had the incentive
It is (but its actually good!), but QtCreator also has a design tool to visually create QML-based UI's.
> I find describing UIs in text instead of "drawing" them like done in Lazarus to be going backwards.
This is a preference thing I guess - some people prefer visual design tools, some prefer text. I quite like QML's approach of giving me a simple declarative text description language and then providing me with a visual design tool to author it with if I prefer to do so.
> Most QtQuick programs i've seen look like something you'd see in a mobile phone or tablet instead of a normal desktop application
Early QtQuick was very much like this, but nowadays it has pretty good platform-style emulation (QtQuick Controls). How many applications use it, I don't know, especially nowadays that QtQuick has iOS and Android support. Also, since it gives you full styling freedom, I guess (for better or worse) many people make use of them rather than trying to look native. I've seen some very non-mobile style QtQuick applications too though, including desktop mail clients and such and they looked great.
Whether or not that is a negative point for Qt depends on your perspective. I mean, Qt never claimed to have JAWS support and the guy is free to submit a patch. Its unfortunate, for sure, that Qt doesn't support popular accessibility tools, but that's hardly a problem unique to Qt or open source tools. This "If you want to support users with disabilities, you probably should not rely on hippie coders right now" is unfortunately true for most open source tools, but also for many commercial offerings. Does Lazarus/Delphi fare better with accessibility and JAWS support specifically?
Also from your link: "For now, you will need to write a native UI for every platform you want to support." -- is the Lazarus/Delphi story any better in this respect?
> Does Lazarus/Delphi fare better with accessibility and JAWS support specifically?
For this particular issue, yes, because Lazarus uses Win32 for Windows applications. For Linux it uses GTK2 (can also use Qt instead) which AFAIK has good accessibility support. For Mac OS X it uses Carbon (there is a Cocoa backend but it is still in prealpha) so... it depends on how accessible Carbon apps are i suppose.
I don't think there is any special support for accessibility however, it is all about what the underlying widgets provide out of the box.
That isn't relevant to Lazarus though since - from what i can tell from its site - JAWS is a Windows-only program and Lazarus uses the native Win32 controls under Windows. So it should work fine.
I want more tools. Qt is popular and I've tried it before, but it keeps cropping up as "the new RAD" in these discussions and I was (unsuccessfully) trying to steer the discussion away from it.
You're saying that Qt is not well designed because it's accessibility support does not include certain apis needed for the JAWS screen reader? That's a very narrow definition of "not well designed". I personally find Qt 5+ with QtQuick (not the older QWidgets) very well designed and I've looked into a large number of GUI frameworks over the years in a variety of languages.
"It's somewhat amusing to realize that in 2017 this is pretty much the easiest way to do a desktop app (besides RealBasic/Xojo which I've yet to try"
If you're interested in Basic programming then Gambas might interest you. Although not a clone of VB, it can be roughly considered being to VB what Lazarus is to Delphi: a 100% Open Source implementation.
I would prefer Lazarus anyway, but it's indeed nice to see different alternatives to proprietary dev systems.
I remember one BASIC, called RapidQ, which I really enjoyed playing with a long time ago (which was freeware, but unfortunately I think it stopped being maintained as the source was sold to another company).
It had a rather cool graphical interface to create GUIs, kind of like VisualBasic I think.
As awesome as Lazarus appears to be here, Rebol is even more amazing in my opinion. There is no designer, but the GUI DSL is mind bending. Red is a Rebol inspired language that is also tiny with a compiler as well so you can build a nice cross-platform-native GUI and distribute it as a tiny executable (~1.5 MB). You can see the GUI stuff for both Rebol and Red. There's a YouTube video by Nick Antonnacio (spelling) that shows him building something like 40 GUI apps in an hour ranging from email apps to games like tic-tac-toe and snake...it was pretty crazy to see the first time.
Very cool, the examples that he builds are very similar to what I've built when I stated in Delphi (simple chats, word processors, music players) but to course Rebol is much more concise. I wish the controls would look more "native". Currently they look like Windows 3.11. Also... Downloading code over plain HTTP? Not good idea...
- It's somewhat amusing to realize that in 2017 this is pretty much the easiest way to do a desktop app (besides RealBasic/Xojo which I've yet to try - was put off by their mandatory registration)
- I wish we had RAD environments like this for more languages (Racket, Python, etc. - even JS).
- On the Mac, installation is a bit fiddly. It needs a little polish and support (a standalone, integrated bundle would be better, or at the very least a unified installer).
- We've been retrofitting web UIs to desktops to such an extent (I'm looking at you, Electron) that the tiny, supremely efficient apps Lazarus spits out put the last couple of years into stark perspective (2GB RAM used by Slack, etc.)
I love Lazarus, and hope it helps resurrect the RAD approach for other languages - if anyone knows of any similar environments (besides QtCreator, etc.), could you share the links?