Qt 5.13 Released | Hacker News Reader

Qt 5.13 Released

blog.qt.io

88 pointsjcelerier41 comments

I've looked into Qt several times in the past two decades as a cross platform SDK for some app ideas I had, but one thing that kept stopping me is the confusing multiple offerings they had. It reminded me of Windows programming: do I choose Windows Forms, WPF, or UWP? Same thing with Java, should I learn Swing or JavaFX? Qt has a similar story lately, I think there's an "old fashioned" API, and a JavaScript API, and a XML-like thing too, and I just don't know where to get started with 100% confidence that I'm not learning the wrong thing.

[Edit] None of this is meant to be a criticism, but constructive feedback as to how to win over users like me who just wanted a stable, high quality SDK to use. If I'm not the target audience then that's fine too.

naive ?: wouldn't you just use your programming language's bindings for Qt?

That would be the "old fashioned" option, or what their site seems to call Qt GUI, and not compatible with Qt QML or Qt Quick (or Qt Quick Controls 2 which I think are just an upgrade)... I think.

QML and Quick are basically the same in colloquial use. Technically QML is the language and Qt Quick the UI system built on top of it. Qt Quick Components (2) are some higher level building blocks for UIs.

It isn't widely used yet (as far as I know) but there's a library to use QML as the language for building QtWidget-based apps:

https://www.kdab.com/declarative-widgets/

It looks a lot like SwiftUI, although I know they work fundamentally differently. I wonder if Qt could adopt that approach somehow, maybe with new C++ features, or maybe by adopting Swift...

If you're building for mobile or want a "modern" UI, go with Qt Quick. If you're building for the desktop, and want a conventional UI, use Qt Widgets.

I'd go with Qt Widgets by default, unless I was building an app that needed very strong branding, a unique UI, and had design help, then I'd go with Qt Quick. Curious to hear what others think.

(I've built a handful of desktop apps with Qt, but they're all tools for music or radio, so a flashy flat UI never made sense, so I've always stuck with Qt Widgets. No regrets.)

Where would the graphics view framework fit? Wouldn't that potentially be a good fit for modern UI on desktop when you want a custom and consistent look-and-feel on all platforms?

Graphics View is just a fancy widget for when you want to do loads of custom drawing of "items" on a canvas. "Qt provides [a] powerful graphics engine that supports easy visualization of items, with support for rotation and zooming. Additionally it provides an event propagation architecture for interaction." --> This is what QGraphicsView and QGraphicsScene accomplish for you.

See:

https://doc.qt.io/qt-5/qgraphicsview.html

https://doc.qt.io/qt-5/qgraphicsscene.html

https://doc.qt.io/qt-5/examples-graphicsview.html

Take a look at the types of applications they used for the examples. It'd be a good solution for something like a CAD layout widget, or maybe a maps widget. You use it together with Qt Widgets or Qt Quick, not instead of it.

> Where would the graphics view framework fit? Wouldn't that potentially be a good fit for modern UI on desktop when you want a custom and consistent look-and-feel on all platforms?

Qt Quick 1 was based on QGraphicsScene / QGraphicsView. Qt Quick 2 was created because they couldn't achieve the performance they wanted (60 fps animations on mobile basically) with the QPainter API and QGraphicsScene.

It still has its uses for technical apps I would say - I personnally use it for the main view of ossia score (https://ossia.io) and am able to get 120 fps with thousands of elements on a 4k screen... so I'm not too stressed about it :-)

> Qt has a similar story lately, I think there's an "old fashioned" API, and a JavaScript API, and a XML-like thing too, and I just don't know where to get started with 100% confidence that I'm not learning the wrong thing.

Qt is way simpler and straight to the point than you believe it is.

Qt's UI files are XML files that offer a convenient way to design layouts which are intended to be used during the build process to generate C++ code. You are free to manually define layouts by instantiating Qt Widget objects but what's masoquism.

It's also possible to use the same XML documents to dynamically generate the UI, but I never saw a project using that in any way.

Then there's Qt Quick. That's an entirely different beast. The UI is defined with a DSL designed for this very purpose, and javascript can be used to handle UI events.

"It's also possible to use the same XML documents to dynamically generate the UI, but I never saw a project using that in any way."

This application: https://github.com/xtuple/qt-client, does precisely that.

It's an ERP application, the bulk of the system uses the XML files to generate into C++ as is usually the case, but they use the dynamic approach as a means by which to offer ad hoc customization support for their clients. In that case, and assuming a fully bespoke form, you use Qt Designer to create the XML ui file as you normally would, but that XML ui file ends up in a text field in the database rather than getting compiled into a C++ application. When the form is loaded, the C++ application loads the XML ui from the database, along with JavaScript to back it, and then dynamically renders the UI using the XML definition. On its own, that technique actually works surprisingly well for that use case and isn't distinguishable from the compiled forms in regard to function or performance at a practical level... maybe some delay in opening the form if the network is slow.

Disclosure: My consultancy is a business partner of the company that makes that application.

This is one thing that C# finally fixed. If you go to the downloads:

https://dotnet.microsoft.com/download/dotnet-core/2.2

you get "Build apps - SDK" and "Run apps - Runtime". So you know what to download depending on your situation. for years it would just say "SDK" and "Runtime", which to a new user means pretty much nothing.

I think Java still uses the confusing style, they should stop it as well.

I don't see how that's any better than JRE + JDK. Runtime environment + development kit, with the ubiquitous J- prefix.

I remember terrible confusion in the blog comments back when they first announced .NET Core. It was not helped by the fact, that, for example, you can build ASP.NET Core applications to target either the .NET Core runtime, or the "classic" .NET. You can build libraries to target "classic" .NET, .NET Standard, or .NET Core.

I'd say the situation is worse than in Java world. It'll probably resolve itself though once they merge everything into a single framework.

Java has stopped doing that with Java 9, with introduction of modules and linker.

You are now supposed to bundle an application specific runtime tailored to your application.

Which is also the path that .NET is taking forward with .NET Core.

I don't see how Java modules have anything to do with the UI framework. Swing is still part of JRE and JDK, and JavaX is now a third party framework, but that's as far as I can tell how that concept is related here.

Because modules and the linker work together, reducing the needless fat when creating an application specific runtime.

Oh I understand. You're talking about stripping down the final Java output to not include more than what's needed, for a better end-user-experience. I was talking about which UI module to include and target from a developer's stand-point. They're both related to modules though, just from different sides of the same coin.

Qt has two main GUI APIs :

- Qt Widgets is a traditional desktop-app-looking UI toolkit, which can integrate with host operating system widgets and is mainly used through C++, Python or the QML language through https://www.kdab.com/declarative-widgets/.

Examples of apps made with Qt Widgets include: Guitar Pro, Unity3D bug reporter, Dolphin (both the emulator and the file manager), Calibre, Krita, VLC, VirtualBox, QTractor, LMMS, Mixx, and many KDE apps ...

Qt Widgets comes with a form designer (called Qt Designer) which generates XML files which can either be compiled to C++ (and basically just new's and set properties on widgets) or parsed at run-time.

- QtQuick is a fancy-looking, GPU-based, scene-graph backed, UI toolkit. It cannot integrate easily with, say, Win32 or Cocoa widgets because everything is rendered on a GL or D3D canvas if possible - as such, it is closer to game engines in terms of rendering than Qt Widgets. However, it supports fluid animations, and fancy effects akin to what you see on mobile or web apps.

It is mainly used through the QML language, but some classes have C++ bindings (and you can create your own QtQuick items in C++).

Examples of apps made with QtQuick include Substance Painter, Blizzard launcher, Native Access, Microsoft OneDrive (the desktop one AFAIK)... and it is used by the Jolla OS and plenty of embedded systems.

Qt Quick also comes with a designer (called Qt Quick Designer) - however in Qt Quick the code is much more integrated with the UI layout.

> which generates XML files which can either be compiled to C++

Additionally, both Python bindings (PySide/Qt for Python and PyQt) have a compiler to turn these XML files into Python code.

You're not the target.Qt is a stable, high quality SDK, but using high end tech tools is not for the confused.

Qt is $5508 per developer for the commercial version. It appears they are only targeting larger enterprises at this point in time.

Well I guess because the multiple attempts to have regular devs sponsor their work failed, so they turned to the only market that is willing to pay for their tooling.

Just like most companies selling software development tools.

I hope developers allocate some money of their annual salary and use it to buy tools. We need to create financial incentives for people to build good tools.

Pretty sure that's not how the laws of supply and demand work. If people need it, someone will fill that need at an affordable price. If we don't need it, we'll survive without it.

To this newcomer to Qt, distributing standalone apps seems like a disaster. Binaries built for macOS link against Qt libraries in /usr/local; on Windows, you need to copy a dozen .dll files until your executable launches, or otherwise rebuild all of Qt (!) to support static linking.

QT is distributed under LGPl so by statically linking you must also distribute your program as LGPL. My understanding is that allowing a user to link their own version of QT (ie shared/dynamic libraries are acceptable) fulfils the criteria to avoid licensing your project under LGPL.

>on Windows, you need to copy a dozen .dll files until your executable launches

Presumably you're new to Windows development? as long as you place the libraries in the same folder as the executable, add the QT install directory to your path, or add the install direvtoey to your debigging Environment variable, you're laughing - it's as straightforward as DLLs on Windows come.

> QT is distributed under LGPl so by statically linking you must also distribute your program as LGPL

AFAIK, static linking doesn't necessary make the whole project LGPL. You just need to provide users relink LGPL part of the library.

Would that mean that distributing object files and letting the user link their own QT would work? I'm not totally sure on the nuanced here unforrunately

Yes

Exactly. For example if you make a project with Qt5.11 then the user should be able to rebuild the project with Qt5.12.

yes, according to the GPL authors : https://www.gnu.org/licenses/gpl-faq.en.html#LGPLStaticVsDyn...

Cool, thanks! I've learned something today!

And bear in mind that 'object file' here could consist of simply a single 'ar' format file containing all the other static code that needs one simple link command.

> as long as you place the libraries in the same folder as the executable

The problem is that I don't know which libraries I need. For a very small project I just kept launching the .exe and reading error messages until I had gathered all the DLLs. It's not a sound way to do it, in case a library is loaded dynamically.

For Qt dlls, use windeployqt. For third-party libs you will still need to copy manually though

> For Qt dlls, use windeployqt.

This, and there are also applications which state which DLLs are missing from a deployment.

How would you have figured out which libraries you need if you were linking it statically? I'm not going to apologise for Windows DLL behaviour (side note, you can use `dumpbin /dependents` or `DependencyWalker` to track them down) as it's awful, but this is categorically nothing to do with QT.

If QT is the best cross platform GUI framework that could come out in the last 20 years, then maybe it's time Electron would be the leading framework for that role.

Thankfully PWAs will kill Electron, as per my prognosis.

XUL and HTA apps also had their fad phase.

Well that's stupid.

Reply on news.ycombinator.com