Hacker News Reader

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)

The Python bindings to Qt don't require compilation. QML is an interpreted gui declaration, and Qt Quick allows programming behavior in Javascript.

PyQt is nasty GPLv3 or commercial license only. (And no, PySide is not an option: their last stable release is years old and for Qt 4.)

You are not comparing apples to apples.

Try finding any native code static typing compiler with RAD on board featuring quick compilation within 2x C++ resulting binary speed.

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?

> 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?

The eco-system of companies selling components for every possible use case.

Most VB/Delphi shops would get early licenses from such companies. DevExpress is a surviving company from those days.

https://www.devexpress.com/Products/VCL/ (over 210 controls)

So you had a huge toolbox full with components for the majority of enterprise most common use cases.

As far as I am aware, there aren't any company selling components for Qt.

There are, but they're few and far between and certainly not as diverse as what you've described.

> 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.

> Qt's layout management was made expecting programmers to do layouts via code

what ? no.

For widgets: http://doc.qt.io/qt-5/designer-layouts.html

For QML: http://doc.qt.io/qtcreator/quick-screens.html

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.

Have you tried QtQuick/QML? It sounds like its anchor/grid/constraints-based layouts work very similarly to Lazarus.

QtQuick, on the other hand, uses non-native widgets - the whole thing is rendered as an OpenGL scene.

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.

> 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

> Isn't that a JSON-like language?

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.

You can do a lot of things graphically : http://blog.qt.io/blog/2017/05/24/qt-quick-designer-qt-creat...

There is https://blind.guru/qta11y.html as a problem with QT, I think it made to HN like three days ago.

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?

The discussion you mentioned is here, btw, and it seems to have mixed views: https://news.ycombinator.com/item?id=14946358

> 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.

Apparently GTK2 doesn't fare better with JAWS: https://stackoverflow.com/a/4136662/1495627

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.

X rough, python no not-bad native widgets, Qt not well designed(@see blog don't use Qt, G)

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.