- Installation of Qt binaries will require a Qt Account
- Long-term-supported (LTS) releases and the offline installer will become available to commercial licensees only
---
Starting with Qt 5.15, long term support (LTS) will only be available to commercial customers. This means open-source users will receive patch-level releases of 5.15 until the next minor release will become available. This means that we will handle Qt 5.15 in the same way as e.g. 5.13 or 5.14 for open source users.
So how does this make Qt "anti open-source"? I'm not saying that they aren't, but they are under no obligation to provide binaries to anybody (under any free software license). Many bona-fide free software packages do not provide binaries at all.
> Starting with Qt 5.15, long term support (LTS) will only be available to commercial customers. This means open-source users will receive patch-level releases of 5.15 until the next minor release will become available. This means that we will handle Qt 5.15 in the same way as e.g. 5.13 or 5.14 for open source users.
It has nothing to do whether mirrors do exist or not, when there will be nothing to mirror.
That's incorrect. The 5.15 branch is and will be public. Most if not all changes to that branch will go via the dev (Qt 6) branch, which is also public.
> Starting with Qt 5.15, long term support (LTS) will only be available to commercial customers. This means open-source users will receive patch-level releases of 5.15 until the next minor release will become available. This means that we will handle Qt 5.15 in the same way as e.g. 5.13 or 5.14 for open source users.
Qt have indicated to KDE that they'll be lagging the open source code behind the binaries by upwards of twelve months. [0]
> But last week, the company suddenly informed both the KDE e.V. board and the KDE Free QT Foundation that the economic outlook caused by the Corona virus puts more pressure on them to increase short-term revenue. As a result, they are thinking about restricting ALL Qt releases to paid license holders for the first 12 months. They are aware that this would mean the end of contributions via Open Governance in practice.
Qt is released under two different licenses: there's the open source release and the commercial release.
Qt hasn't for a while distributed binaries for the open source release, but there were publicly downloadable binaries for the trial version of the commercial release which is what has now gone. But as you say, nothing stops _others_ from distributing binaries for the open source release.
> Can't I host a compiled copy of Qt and let the world install it?
Of course you can do that, as long as you respect the LGPL. That's what pretty much every Linux distribution is doing. It's just that the old Qt offline installer by the QtCompany is no longer available.
If you compiled it yourself, yes. The Qt source code is available under the LGPL (among other options), the binaries provided on the Qt website are not.
As a matter of fact, all the Linux distribution distribute Qt and I don't remember creating an Qt Account for downloading the KDE/Qt applications I use and Plasma from my distro.
The Qt company owns the copyright to the Qt source code so they can sell (L)GPL exceptions. Bundling LGPL code in a binary, as mobile may require, instead of loading as dynamic library, requires you to get an LGPL exception from the copyright holder (or provide an object file for the user to relink). Other licenses, like Apache and the EPL, do not have this issue.
Companies can do this for open source projects. They require you to sign a contributor agreement handing over over copyright or require you license the code to them under the MIT. For the most part, differs based on region and IANAL.
Edit: corrected in () that you can comply with the LGPL with static binaries with providing an object file to the user to relink with.
> Bundling LGPL code in a binary, as mobile may require, instead of loading as dynamic library, requires you to get an LGPL exception from the copyright holder.
How come? The LGPL allows people to distribute statically compiled binaries that use Qt, you do not need an exception for that.
> The LGPL allows people to distribute statically compiled binaries that use Qt
Hmmm... you can as long as you provide an object. Learned something new today. I do remember Mike discussing that on Coder Radio that would be an issue in the security industry. I assuming there were some aerospace libraries that are NDAed/restricted by national security laws.
Can’t you bundle it in a binary as long as you provide an upgrade path for the QT part? I know this doesn’t work for mobile because users can’t do it due to the app stores, but for an embedded MCU application you could allow re-linking and reflashing of the hardware.
Sure you can, but QT will not be responsible for compatibility of your binaries, and I for example would not use yours, instead I'll try use some official biniries from Canonical for example even older ones.
Well, when you target Windows or Mac it's a mess anyway: when your project reaches certain level of complexity then you probably build Qt alongside with it.
But I think that adding friction to the "download binaries from some site" is doing nothing more than alienating Windows developers. Qt just must add something like "Sign in with Google/Facebook with one click" because this audience cares about convenience.
It is free software. The complaints are for people that want LTS binary builds for free. I mean how dare someone ask money for their work. You can make your own builds or fork it.
Isn't Red Hat doing the same thing, even worse I think they were obfuscating some stuff just to make things harder for competition.
Any good alternatives to Qt? I remember looking into the cross-platform desktop development landscape a while ago and being disappointed by the options (Qt, Gtk, Electron).
If the app is free, I would just politely ask such users to eff off. On the other hand I am probably as far away from iPad-damaged demographic that you can come: Emacs isn't enough of an OS, I have to leave it a couple of times a day and I hate every single minute of it.
Everything I do on a computer, apart from the odd movie I watch, is centered around information in text form, yet literally every program except decent text environments try their best to ruin working with text. The only place where I think a non-text-based ui actually adds something is in calendar applications, yet most of the suck as well.
So I sit here alone with the marvel that is 1980s technology, thinking most things regarded as "modern" in computing are a farce.
The only new general purpose tool I can stand is VSCode, where my o my critique is that it isn't emacs (and that multiple cursors are a decent but not a great replacement for macros)
Electron is slow and lethargic. Even the highly optimised VS Code makes me switch to gvim several times a day because input doesn't go in sequence; it seems to process easier input first rather than earlier input first.
You can use Gtk to make executables on Windows and MacOS, but it's not comfortable and the resulting guis are ugly. They do not take advantage of the full provisions of the platform. Gtk is less cross platform, and more a foundational Gnome library that someone has ported to Windows and MacOS. No support for two major operating systems.
Qt I can't speak to.
WxWidgets seems to be a little .. dated. The screenshots on their website look like programs that were acceptable for a technical user 15 years ago. Has it moved on from that? Dunno. No support for two major operating systems.
Instead, I’m looking for a static, strongly typed language, that gives me native bindings for each platform’s gui. I think I’m fine with doing the abstraction bit myself, where and when needed. Any recommendations?
Last time I had to do a gui, I chose JavaFX, and it was fine. But I’m still looking for native options, even if I have to implement the ui 3 times.
Edit: to clarify, I’m looking for something beyond C/C++
Unless you consider HTML5 in the browser, the options are quite limited (I guess you do, as you included Electron).
GTK is always GNOME first and has issues most other places or just looks ugly.
wxWidgets always looked off and had the weirdes issues.
Qt (or at least QtWidgets) was fairly solid in design and implementation. Then they kind of put that on ice and started with a second GUI framework (QML) that didn't fit together whatsoever. Now it has a split personality and the widgets part has a hard time to keep up with modern problems like high-resolution screens and and scaling (I'm writing this from KDE, so I know first hand).
Then everyone tried to re-invent the user interface paradigm and that's how we ended up in the current mess. Consistent buttons, input boxes and frameworks were replaced by flashy but fairly unusable interfaces, which of course did not work out. So now we have this weird mix of not letting go and not knowing where to go.
In what way does wx look "off"? To me Qt is the one that looks "off"... it doesn't feel native. But wx looks and feels like any native app... because it uses native controls...
Wx is native, but you really need to pay attention to what are the defaults on your platform. Wx either doesn't have those, or they don't align that well with other apps in the system, which is where the "off" feeling may come from. If you spend time designing it to look nice, it will look nice - but it doesn't exactly go out of its way to help you. Then ensure the same for each platform you target. (My experience, YMMV)
Yes, pretty much this. The last time I tried it, the platform had a dark theme style that wx tried to apply, but then ended up with light grey borders within the dark parts of the widgets and there really wasn't a simple solution - there was an unresolved bug ticket.
yeah, I was a bit ambitious and required an AVX cpu for the alpha but you're the second person with a CPU without even SSE4 in less than two weeks so I'll revert to a SSE2 baseline :/
I'm just doing stuff myself, using C with OpenGL and some platform code. I can already target the web using emscripten. I'll be able to compile to Android in the future.
It is a tough learning curve but I'm starting to see the light. Depending on your application, completely self-contained GUIs don't actually need that much code - it's mostly the knowledge of how to architect them.
A hard problem is how to approach construction of Widgets and hierarchies of control elements. The traditional OO centric approach is far too much boilerplate to be practical without a huge third-party library, but the Immediate GUI approach which got talked about a lot recently is maybe a little simplistic. I think I've found a good middle ground between "immediate" and "retained".
That would require knowledge of every platform specific graphics stack (wayland, win32, cocoa, ndk). How is this a feasible approach? Are you making your own custom cross platform framework?
No I'm just doing OpenGL. This is about cross platform - I don't really use the platform specific fuss. I need a window to draw to, and maybe a little file writing or networking code.
I don't do Macs so far, so I can't tell you about that. I have a little boilerplate for setting up a window and getting input events for X11 (Linux) and Win32/GDI. It's about 300-400 lines each.
You can opt to use GLFW3 instead to target all the big platforms with a single file that is also 300-400 lines. Mac is supported, too. I have mostly ceased to use GLFW since I prefer to code the stuff myself to have absolute control in case I need it, and to understand the issues of the platforms I have dealt with - but frankly GLFW is a very good and sleek library to get an OpenGL window and some inputs.
Getting to the web using emscripten was similar. They support an older GLFW2 API so it was a matter of maybe 30 minutes to convert my GLFW code to run on the web. They also have a HTML5 API (html5.h) which is probably better, so I expect to add another couple hundred lines later at some point for that.
Emscripten / the Web required me to port my desktop OpenGL code to OpenGL ES 3.0, which was quickly done and a very good idea to do anyway.
And after all, the OpenGL rendering backend code is not that big either if your architecture is right. Mine is currently 700 lines, and it supports solid faces, textured faces, alpha-channels, subpixel font rendering - all of course for 2D and 3D.
You should look at modern UI libraries like Flutter or SwiftUI. It's a lot like immediate UI, but:
- it is capable of storing state: storing position in scroll view, which page is currently visible, etc.
- it tracks dependencies, so ideally UI building code is executed again only if something changed that would affect it's output.
The approach I currently take is I just re-layout on each frame. If you have <1000 elements visible on the screen, I don't think that will ever be a problem. I currently have only about 20 though, so I don't really know.
The important point is that I don't allocate and re-initialize the state of all controls. It's enough if you do from scratch the layout - that gets much simpler if you don't have to code a diff against the previous state.
So I basically have a simple Widget abstraction - a draw function and a process-input function + some identification data (implemented as a union of void-ptr and int). I can then make lists of these abstract Widgets, and each list represents the set of childs of a superordinate element.
This abstraction allows me to construct hierarchies and to have unabstracted and very flexible code for the layout, while the layout and input processing code can be generic - it's a simple loop over the list, calling the callback with the abstract handle.
If there are ever performance problems you can still fluidly move more towards some retained layout state. This for sure will require more complex code, but if you just do it for complex layouts with lots of elements, I figure you get the best of both worlds.
Mouse and drag handling is a little bit tricky as well - how to keep sending events to the slider control widget for example even if the mouse is temporarily outside the widget? The important realization is that dragging needs global state. You set the mouse globally as "grabbed" and provide a callback to execute when there are more mouse events.
I still think the FOX Toolkit deserves another chance. A lightweight C++ GUI toolkit for Linux and Windows. But I can see that the hard-coded Windows 95 theme, lack of modern browser integration, and little recent activity (but non-zero), might be off-putting.
- Decades of active development
- Proven concepts (same paradigm as .Net, VB and Delphi)
- Supports a lot of OS/CPU.
Edit: To get started easily with tasks like cross-compiling, getting the trunk edition, and so on, use (https://wiki.lazarus.freepascal.org/fpcupdeluxe) to perform the download and installation.
One wonders why there isn't something like it, but that you can use with any language instead of just Pascal or BASIC or QML+Cpp or whatever the crap Qt uses these days.
Being a very long time Delphi and FreePascal user with tens of thousands of lines of code in active use today, I never understood why pascal wasn't running way out front of Go, Rust, Java and all these other performant languages. It's so straight forward and such a pleasure to work with.
Because Turbo Pascal/Delphi was the ideal Pascal dialect (after Apple's Object Pascal) and Borland screwed it up.
If Borland had kept their indies demographic, hadn't made their half-backed attempt to Linux with Kylix, the history would most likely played in a different direction.
LTS releases are very welcome, more open source software should adopt this release style. So far the Linux kernel, NodeJS, LibreOffice, Django have LTS candidates. Would love Python to join that list.
Hmm. I just started playing with QT and I really like how easy it was to create simple database interface. It may not be pretty, but it is very functional. The change to commercial is a little sad, and I understand the money part. I just wish they did not require an account to do it.
> we have started working on an abstraction layer for [OpenGL/Vulkan/Metal/Direct3D] a bit more than a year ago. It's called the Qt Rendering Hardware Interface (RHI)
Looks cool, but makes me sad that they have to do it. This industry is so annoying sometimes.
Also, sad to see classic widgets continue to get no love. I know it's a lost cause, I'm just sentimental about it.
100 comments
[ 3.9 ms ] story [ 168 ms ] thread> Qt is available under the GNU Lesser General Public License version 3.
- Installation of Qt binaries will require a Qt Account
- Long-term-supported (LTS) releases and the offline installer will become available to commercial licensees only
---
Starting with Qt 5.15, long term support (LTS) will only be available to commercial customers. This means open-source users will receive patch-level releases of 5.15 until the next minor release will become available. This means that we will handle Qt 5.15 in the same way as e.g. 5.13 or 5.14 for open source users.
How is this compatible wit the LGPL? Can't I host a compiled copy of Qt and let the world install it?
Or, in more words as Qt pusts it:
> Starting with Qt 5.15, long term support (LTS) will only be available to commercial customers. This means open-source users will receive patch-level releases of 5.15 until the next minor release will become available. This means that we will handle Qt 5.15 in the same way as e.g. 5.13 or 5.14 for open source users.
It has nothing to do whether mirrors do exist or not, when there will be nothing to mirror.
> Starting with Qt 5.15, long term support (LTS) will only be available to commercial customers. This means open-source users will receive patch-level releases of 5.15 until the next minor release will become available. This means that we will handle Qt 5.15 in the same way as e.g. 5.13 or 5.14 for open source users.
> But last week, the company suddenly informed both the KDE e.V. board and the KDE Free QT Foundation that the economic outlook caused by the Corona virus puts more pressure on them to increase short-term revenue. As a result, they are thinking about restricting ALL Qt releases to paid license holders for the first 12 months. They are aware that this would mean the end of contributions via Open Governance in practice.
[0] https://mail.kde.org/pipermail/kde-community/2020q2/006098.h...
Qt hasn't for a while distributed binaries for the open source release, but there were publicly downloadable binaries for the trial version of the commercial release which is what has now gone. But as you say, nothing stops _others_ from distributing binaries for the open source release.
Of course you can do that, as long as you respect the LGPL. That's what pretty much every Linux distribution is doing. It's just that the old Qt offline installer by the QtCompany is no longer available.
Companies can do this for open source projects. They require you to sign a contributor agreement handing over over copyright or require you license the code to them under the MIT. For the most part, differs based on region and IANAL.
Edit: corrected in () that you can comply with the LGPL with static binaries with providing an object file to the user to relink with.
How come? The LGPL allows people to distribute statically compiled binaries that use Qt, you do not need an exception for that.
Hmmm... you can as long as you provide an object. Learned something new today. I do remember Mike discussing that on Coder Radio that would be an issue in the security industry. I assuming there were some aerospace libraries that are NDAed/restricted by national security laws.
https://stackoverflow.com/questions/10130143/gpl-lgpl-and-st...
http://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic
Is this possible on iOS? Not familiar with iOS dev, but I assume Apple may have some TOS problems with that.
See the note here at the end: https://github.com/freedesktop/gstreamer/blob/master/README....
vcpkg install qt5
With vcpkg and other alteratives in the picture, it's far less hassle to use that than mess around with the slow and flaky installer tool.
Distributions ship binaries with OS anyways. You won't have to build it yourself.
Project like VLC or QGIS have releases not only for Linux, but for Windows and Mac too.
But I think that adding friction to the "download binaries from some site" is doing nothing more than alienating Windows developers. Qt just must add something like "Sign in with Google/Facebook with one click" because this audience cares about convenience.
Isn't Red Hat doing the same thing, even worse I think they were obfuscating some stuff just to make things harder for competition.
Also - while a lot more low-level - Skia. Sublime Text/Merge and Aseprite are using it.
But show an app made with it to anybody below 30 and they will call you an ancient fossil.
If something doesn't have transition and gesture nowaday, you better market it to accountants because the general public won't want it.
Everything I do on a computer, apart from the odd movie I watch, is centered around information in text form, yet literally every program except decent text environments try their best to ruin working with text. The only place where I think a non-text-based ui actually adds something is in calendar applications, yet most of the suck as well.
So I sit here alone with the marvel that is 1980s technology, thinking most things regarded as "modern" in computing are a farce.
The only new general purpose tool I can stand is VSCode, where my o my critique is that it isn't emacs (and that multiple cursors are a decent but not a great replacement for macros)
You can use Gtk to make executables on Windows and MacOS, but it's not comfortable and the resulting guis are ugly. They do not take advantage of the full provisions of the platform. Gtk is less cross platform, and more a foundational Gnome library that someone has ported to Windows and MacOS. No support for two major operating systems.
Qt I can't speak to.
WxWidgets seems to be a little .. dated. The screenshots on their website look like programs that were acceptable for a technical user 15 years ago. Has it moved on from that? Dunno. No support for two major operating systems.
Last time I had to do a gui, I chose JavaFX, and it was fine. But I’m still looking for native options, even if I have to implement the ui 3 times.
Edit: to clarify, I’m looking for something beyond C/C++
It you want to explore the Rust option, here is an overview of the status of GUI toolkits in Rust: https://areweguiyet.com/
GTK is always GNOME first and has issues most other places or just looks ugly.
wxWidgets always looked off and had the weirdes issues.
Qt (or at least QtWidgets) was fairly solid in design and implementation. Then they kind of put that on ice and started with a second GUI framework (QML) that didn't fit together whatsoever. Now it has a split personality and the widgets part has a hard time to keep up with modern problems like high-resolution screens and and scaling (I'm writing this from KDE, so I know first hand).
Then everyone tried to re-invent the user interface paradigm and that's how we ended up in the current mess. Consistent buttons, input boxes and frameworks were replaced by flashy but fairly unusable interfaces, which of course did not work out. So now we have this weird mix of not letting go and not knowing where to go.
You could go very old school though, with something like http://www.fox-toolkit.org or https://www.lazarus-ide.org/
wxWidgets?
For audio-related software (such as Helio Workstation[0]) there is JUCE.[1]
[0] https://github.com/helio-fm/helio-workstation
[1] https://en.wikipedia.org/wiki/JUCE
It is a tough learning curve but I'm starting to see the light. Depending on your application, completely self-contained GUIs don't actually need that much code - it's mostly the knowledge of how to architect them.
A hard problem is how to approach construction of Widgets and hierarchies of control elements. The traditional OO centric approach is far too much boilerplate to be practical without a huge third-party library, but the Immediate GUI approach which got talked about a lot recently is maybe a little simplistic. I think I've found a good middle ground between "immediate" and "retained".
I don't do Macs so far, so I can't tell you about that. I have a little boilerplate for setting up a window and getting input events for X11 (Linux) and Win32/GDI. It's about 300-400 lines each.
You can opt to use GLFW3 instead to target all the big platforms with a single file that is also 300-400 lines. Mac is supported, too. I have mostly ceased to use GLFW since I prefer to code the stuff myself to have absolute control in case I need it, and to understand the issues of the platforms I have dealt with - but frankly GLFW is a very good and sleek library to get an OpenGL window and some inputs.
Getting to the web using emscripten was similar. They support an older GLFW2 API so it was a matter of maybe 30 minutes to convert my GLFW code to run on the web. They also have a HTML5 API (html5.h) which is probably better, so I expect to add another couple hundred lines later at some point for that.
Emscripten / the Web required me to port my desktop OpenGL code to OpenGL ES 3.0, which was quickly done and a very good idea to do anyway.
And after all, the OpenGL rendering backend code is not that big either if your architecture is right. Mine is currently 700 lines, and it supports solid faces, textured faces, alpha-channels, subpixel font rendering - all of course for 2D and 3D.
- it is capable of storing state: storing position in scroll view, which page is currently visible, etc. - it tracks dependencies, so ideally UI building code is executed again only if something changed that would affect it's output.
The important point is that I don't allocate and re-initialize the state of all controls. It's enough if you do from scratch the layout - that gets much simpler if you don't have to code a diff against the previous state.
So I basically have a simple Widget abstraction - a draw function and a process-input function + some identification data (implemented as a union of void-ptr and int). I can then make lists of these abstract Widgets, and each list represents the set of childs of a superordinate element.
This abstraction allows me to construct hierarchies and to have unabstracted and very flexible code for the layout, while the layout and input processing code can be generic - it's a simple loop over the list, calling the callback with the abstract handle.
If there are ever performance problems you can still fluidly move more towards some retained layout state. This for sure will require more complex code, but if you just do it for complex layouts with lots of elements, I figure you get the best of both worlds.
Mouse and drag handling is a little bit tricky as well - how to keep sending events to the slider control widget for example even if the mouse is temporarily outside the widget? The important realization is that dragging needs global state. You set the mouse globally as "grabbed" and provide a callback to execute when there are more mouse events.
http://fox-toolkit.org/screenshots/iims3.png
edit Too late I see skriticos2 already mentioned FOX.
And their commercial offerings are very pricey indeed ($6000 a year).
I'd recommend users to switch to wxWidgets.
See my other comment: https://news.ycombinator.com/reply?id=23322197&goto=item%3Fi...
- Decades of active development - Proven concepts (same paradigm as .Net, VB and Delphi) - Supports a lot of OS/CPU.
Edit: To get started easily with tasks like cross-compiling, getting the trunk edition, and so on, use (https://wiki.lazarus.freepascal.org/fpcupdeluxe) to perform the download and installation.
Now if there were something like Lazarus, but for Rust, the HN crowds would go nuts.
If Borland had kept their indies demographic, hadn't made their half-backed attempt to Linux with Kylix, the history would most likely played in a different direction.
Is it a campaign or something?
When you choose this wording or stuff like "someone is worried" then it's a plain FUD.
https://download.qt.io/archive/qt/5.15/5.15.0/single/
Python is supported for ~5 years (closer to 6 in practice) without any promise of an lts release. https://www.python.org/dev/peps/pep-0537/#lifespan Would you want more than that?
Looks cool, but makes me sad that they have to do it. This industry is so annoying sometimes.
Also, sad to see classic widgets continue to get no love. I know it's a lost cause, I'm just sentimental about it.