Qt 6.0(qt.io)
qt.io
Qt 6.0
https://www.qt.io/blog/qt-6.0-released
371 comments
[deleted]
it's so expensive, too bad there are no good alternatives to this
Looks like it's available under the fairly permissive LGPL licence - https://doc-snapshots.qt.io/qt6-dev/licensing.html
It's worth noting that there are specific add-on modules that are only available under the GPLv3 license. Qt6 doesn't have all of them yet, and they (supposedly) will be coming in the 6.1-6.2 releases.
Qt5: https://doc.qt.io/qt-5.15/qtmodules.html#gpl-licensed-addons
Qt6: https://doc.qt.io/qt-6/qtmodules.html#gpl-licensed-addons
Qt5: https://doc.qt.io/qt-5.15/qtmodules.html#gpl-licensed-addons
Qt6: https://doc.qt.io/qt-6/qtmodules.html#gpl-licensed-addons
Well, the more software uses GPLv3 the better. All the locked bootloader shenanigans and software patent FUD is really getting out of hand and more widely used GPLv3 software can help at least a bit.
For commercial purposes it is actually very expensive.
(Source: Used to work for Nokia)
EDIT:
(Source2: https://www.qt.io/pricing)
(Source: Used to work for Nokia)
EDIT:
(Source2: https://www.qt.io/pricing)
It's perfectly possible to use an LGPL library for commercial purposes (and lots of companies do). There's just some criteria you have to follow like allowing end-users to re-link their own version of the library and giving back any code changes made to the library itself (which in my experience it was never necessary to make any patches to Qt itself). Whether that extra burden is worth it vs. just paying for a commercial license is up to the individual company.
Your software would have to be very locked down to preclude using LGPL libraries.
Even Tesla were able to use LGPL Qt in their cars: https://electrek.co/2018/05/19/tesla-releases-softwar-open-s...
(which is a shitty thing to do when you're not a mom&pop shop but a company like https://news.ycombinator.com/item?id=25344677)
(which is a shitty thing to do when you're not a mom&pop shop but a company like https://news.ycombinator.com/item?id=25344677)
Following the license should not be considered a "shitty thing to do". In fact, it's a perfectly reasonable thing to do.
> In fact, it's a perfectly reasonable thing to do.
Just like my answer to the other comment, there are a ton of "perfectly reasonable" things that one can do, that are still shitty behaviour.
That's like when someone leaves free books for anyone to take, you'd take one but never put another one for other people. You're not breaking any laws or rules. Still shitty. Especially if you have enough money to build a whole freaking library.
Just like my answer to the other comment, there are a ton of "perfectly reasonable" things that one can do, that are still shitty behaviour.
That's like when someone leaves free books for anyone to take, you'd take one but never put another one for other people. You're not breaking any laws or rules. Still shitty. Especially if you have enough money to build a whole freaking library.
I do agree with you, but in the specific case of free book sharing - I hear that most of the time, the problems is too many books rather than too few, so you should really not worry about taking a book even if you are not sure you're going to put another one for other people.
But Qt chose to release under the LGPL. If they had wanted to restrict unpaid use of Qt to Free and Open Source software, they could have done so with the GPL licence.
the point is not to restrict - it's to give back when you have more than enough capital to do so.
Like, anyone can go to a food bank charity to have a free meal. If you have a 5-digit monthly salary, that is still a very shitty thing to do, even if you and everyone else plays by the rules.
Like, anyone can go to a food bank charity to have a free meal. If you have a 5-digit monthly salary, that is still a very shitty thing to do, even if you and everyone else plays by the rules.
Sure, I see your point, especially as Tesla:
1. Could easily afford it, as you say
2. Presumably aren't releasing their software as Free and Open Source
1. Could easily afford it, as you say
2. Presumably aren't releasing their software as Free and Open Source
> which is a shitty thing to do when you're not a mom&pop shop but a company like...
Why? That's the whole point of LGPL, it doesn't matter how big you are, so long as your users can replace your copy of Qt with a modified copy you can use it under LGPL.
Why? That's the whole point of LGPL, it doesn't matter how big you are, so long as your users can replace your copy of Qt with a modified copy you can use it under LGPL.
I really wonder how Tesla thinks I'm going to replace libQtCore.so, given that I'd presumably need to root the OS first...?
Even Autodesk, which uses Qt for pretty much all its products, including Maya, doesn't pay a cent for Qt. Same with The Foundry. As soon as Nokia made LGPL licensed python bindings for Qt, they dropped PyQt, stopped paying or contributing, and just went on freeloading.
glibc is also LGPL, but basically everything uses that unless you're going for musl.
I'm curious what price range you feel a library like Qt can justify?
(genuine question, I'm doing a bit of market research in this area)
(genuine question, I'm doing a bit of market research in this area)
I think combination of JUCE/IntelliJ pricing and Unreal Engine model would be a sweet spot:
1) Personal License - free if <50k annual revenue
2) Startup License - keep current price (500usd/month) but
a) allow 1 month subscription commitment instead of paying 1 year upfront
b) when subscription not get extended you should still be allowed to distribute product that is not updated
c) if you payed for 1-2 years of subscriptions and cancelled subscription after 1-2+ year, you should be able to keep using the version of Qt the moment when you first signed for .
3) allow Startup to choose another licensing option. Instead of paying upfront licensing fee, just allow paying annually 5% of revenue from products that keep using Qt.
1) Personal License - free if <50k annual revenue
2) Startup License - keep current price (500usd/month) but
a) allow 1 month subscription commitment instead of paying 1 year upfront
b) when subscription not get extended you should still be allowed to distribute product that is not updated
c) if you payed for 1-2 years of subscriptions and cancelled subscription after 1-2+ year, you should be able to keep using the version of Qt the moment when you first signed for .
3) allow Startup to choose another licensing option. Instead of paying upfront licensing fee, just allow paying annually 5% of revenue from products that keep using Qt.
of course they don't advertise the per-device royalty for embedded - do you (or anyone else here) have an idea what it costs?
everything...
The company behind Qt has been getting very passive-aggressive in the last 1..2 years about using the LGPL version for commercial projects. They didn't shut it down (yet?) but they're definitely not happy about it. Personally I wouldn't consider Qt for future projects because the writing is on the wall.
Luckily the LGPL license can never be revoked on previously released versions. So it's possible to use Qt 5 and never have to worry (as long as you follow the requirements of the license in terms of dynamically linking the libraries).
That’s true for 6 as well. I believe there are clauses in Qt’s ownership documents that prevent it from ever becoming closed source without automatically invalidating previous licenses and becoming GPL-only, or something to that effect. The poison-pill was designed when Trolltech first sold away Qt, if i remember correctly.
[deleted]
Did you mean to comment on https://news.ycombinator.com/item?id=25344762 instead ? xD
There's CopperSpice.
https://www.copperspice.com/
https://www.copperspice.com/
Maybe not a "good" alternative, but its at least an "ok" alternative!
https://www.wxwidgets.org/
https://www.wxwidgets.org/
I used to use wxWidgets a lot back in the day when I was developing software for academia (about 5 years ago). Is it not considered good any more? It used to be pretty useful for developing GUI, although I think OSX implementation was buggy?
Used it for my last side project (https://github.com/atbswp). On Linux it looks fine (because GTK), but on Windows iirc it still uses Win32 which looks a bit archaic.
The widget screenshot comparison shows a Win7 style which isn't that archaic.
This thread seems to indicate that Win10 style is also possible which would make sense since it uses native elements https://forums.wxwidgets.org/viewtopic.php?t=46574
This thread seems to indicate that Win10 style is also possible which would make sense since it uses native elements https://forums.wxwidgets.org/viewtopic.php?t=46574
Re: "too bad there are no good alternatives to this"
What about the Tk/Gtk family of products?
What about the Tk/Gtk family of products?
Sciter (https://sciter.com) and Sciter.JS ( https://github.com/c-smile/sciter-js-sdk ) can be considered as alternative I think.
Sciter supports same platforms as Qt and uses H/W acceleration (DirectX, OpenGL) in 10 years or so.
Everything that you can do in Qt you can do in Sciter.
Just in case: Sciter.JS that is in alpha/beta now is aimed as a direct ElectronJS replacement as it uses standard JavaScript (ES6). It already supports MithrilJS and Svelte applications running transparently as in SciterJS as in browsers. React (PReact in particular) out of the box support is coming. The main goal of SciterJS is to provide compact (5mb runtime) desktop runtime environment that can use components and designs made for Web.
Sciter supports same platforms as Qt and uses H/W acceleration (DirectX, OpenGL) in 10 years or so.
Everything that you can do in Qt you can do in Sciter.
Just in case: Sciter.JS that is in alpha/beta now is aimed as a direct ElectronJS replacement as it uses standard JavaScript (ES6). It already supports MithrilJS and Svelte applications running transparently as in SciterJS as in browsers. React (PReact in particular) out of the box support is coming. The main goal of SciterJS is to provide compact (5mb runtime) desktop runtime environment that can use components and designs made for Web.
Sciter could be considered a competitor to Qt Quick, but probably not even to Widgets or any of the other (many) modules that are part of the core (not to mention add-ons), considering that Sciter is just an UI library.
> Sciter could be considered a competitor to Qt Quick
Yes and no.
Yes, it allows to create declarative UI.
And no, not just declarative UI. It supports immediate mode graphics for example and use of native UI components including existing HWND, GtkWidget, NSView, etc. based ones.
As of other non UI parts of Qt... Sciter does not provide all that beauty, yes. Host application (C/C++, Go, Rust, etc) that uses Sciter UI layer is free to use whatever libraries/runtime they prefer, and usually each runtime is superior to what Qt provides.
That's the cornerstone idea of its design - it is embeddable UI layer. While Qt is a foundation (a.k.a. framework) similar to MFC, Gtk and other frameworks.
At early stages of C++ having things like CList & Co did make sense. But not in recent 10 years. Yet I am silent about Go, Rust, Python and other languages / runtimes that use Sciter.
Yes and no.
Yes, it allows to create declarative UI.
And no, not just declarative UI. It supports immediate mode graphics for example and use of native UI components including existing HWND, GtkWidget, NSView, etc. based ones.
As of other non UI parts of Qt... Sciter does not provide all that beauty, yes. Host application (C/C++, Go, Rust, etc) that uses Sciter UI layer is free to use whatever libraries/runtime they prefer, and usually each runtime is superior to what Qt provides.
That's the cornerstone idea of its design - it is embeddable UI layer. While Qt is a foundation (a.k.a. framework) similar to MFC, Gtk and other frameworks.
At early stages of C++ having things like CList & Co did make sense. But not in recent 10 years. Yet I am silent about Go, Rust, Python and other languages / runtimes that use Sciter.
I think it would be better to put a disclosure that you are creator of sciter.
[deleted]
Website being blocked for me by NextDNS:
> www.qt.io (→ 149513g13.secure0130.hubspot.net) is being blocked by NoTrack Tracker Blocklist.
> www.qt.io (→ 149513g13.secure0130.hubspot.net) is being blocked by NoTrack Tracker Blocklist.
Heads up for anyone on a commercial license (this does not affect the LGPL-Version): Qt6 does not offer a perpetual license anymore, you need to switch to a subscription license. The catch is that you need a subscription license not only for development but also for distribution, meaning: you need to have a subscription for as long as you distribute your software with Qt6 under the commercial license!
Again: This only affects the commercial version! Nothing changes if you're using the LGPL version.
See also: (German) https://www.heise.de/news/Qt-6-Abomodell-koennte-zum-Fallstr...
(Google translate/English): https://translate.google.com/translate?hl=en&sl=de&u=https:/...
https://www.qt.io/faq/tag/subscription
EDIT: You also need a license if you only use your software with the commercial Qt6 license.
Again: This only affects the commercial version! Nothing changes if you're using the LGPL version.
See also: (German) https://www.heise.de/news/Qt-6-Abomodell-koennte-zum-Fallstr...
(Google translate/English): https://translate.google.com/translate?hl=en&sl=de&u=https:/...
https://www.qt.io/faq/tag/subscription
EDIT: You also need a license if you only use your software with the commercial Qt6 license.
I don't see a problem with a subscription model for development, but requiring a perpetual license as long as you distribute your Qt-reliant software is insane in my mind. The software is built. It's not getting any benefit from future Qt improvements or bug fixes.
It's amazing how many people in this thread are not only defending this, but talking about how great this licensing model is.
I'm guessing all these people have startups (or ideas for startups) that rely on gouging customers with never-ending subscription models.
I personally think subscription licensing models is the worst thing to happen to the software industry. I miss being able to purchase and own copies of software. I recently stopped using any Adobe apps and moved my entire workflow over to the Affinity suite. I prefer to support developers who don't rip-off their consumers
It's amazing how many people in this thread are not only defending this, but talking about how great this licensing model is.
I'm guessing all these people have startups (or ideas for startups) that rely on gouging customers with never-ending subscription models.
I personally think subscription licensing models is the worst thing to happen to the software industry. I miss being able to purchase and own copies of software. I recently stopped using any Adobe apps and moved my entire workflow over to the Affinity suite. I prefer to support developers who don't rip-off their consumers
but requiring a perpetual license as long as you distribute your Qt-reliant software is insane in my mind
I'm an embedded Qt licensee. I don't get any of this at all and now I need to spend hours I don't have with my legal team understanding what the impact is. I suppose we're staying on 5.15 for the lifetime of the product I haven't even launched yet.
I mean, it's a given every time Qt pops up on HN a good 50% of the thread is sucked up with licensing questions and information/misinformation. Getting kind of tired of it all.
I'm an embedded Qt licensee. I don't get any of this at all and now I need to spend hours I don't have with my legal team understanding what the impact is. I suppose we're staying on 5.15 for the lifetime of the product I haven't even launched yet.
I mean, it's a given every time Qt pops up on HN a good 50% of the thread is sucked up with licensing questions and information/misinformation. Getting kind of tired of it all.
I don't think this is necessarily new with Qt 6.0. The details and pricing may have changed, but as far as I know, the commercial Qt Embedded product has always required a distribution license. This means you have to pay a royalty fee for each product that you sell that uses Qt. This is on top of the license you pay per developer to develop the software. If development is "done" but you are still distributing the product, presumably you would have had to pay the distribution license but could let the development license lapse. Has this changed with Qt 6?
I don't know yet, I'm putting in a call to my account rep.
What I do recall is that if you let the development license lapse, you're locked into whatever version was latest at the time. So I can't upgrade Qt on any in-field device updates which is usually just fine, especially if you managed to get to a decent LTS version, but any Qt bugfixes after that are off limits.
What I do recall is that if you let the development license lapse, you're locked into whatever version was latest at the time. So I can't upgrade Qt on any in-field device updates which is usually just fine, especially if you managed to get to a decent LTS version, but any Qt bugfixes after that are off limits.
> as far as I know, the commercial Qt Embedded product has always required a distribution license
That is correct. These distribution licenses for shipping Qt with devices were never perpetual in the sense that you can ship as many devices with Qt as you want. But this was a separate license, which AFAIK you also could buy in bulk, which is totally OK. As far as I understand it, you now need a full subscription for distribution with the danger that prices may change any time.
That is correct. These distribution licenses for shipping Qt with devices were never perpetual in the sense that you can ship as many devices with Qt as you want. But this was a separate license, which AFAIK you also could buy in bulk, which is totally OK. As far as I understand it, you now need a full subscription for distribution with the danger that prices may change any time.
[deleted]
I agree with the first paragraph of your post, but not the last. Software requires maintenance, it's not a one and done thing unless the application is trivial, or embedded in say a microwave oven. Subscription models reality better a majority of the time. Qt seems to have taken that a bit too far, however.
This. I shake my head every time Qt shows up in HN as an upvoted thread. Its licensing model is so antithetical to smart planning I find it unusable for any project.
I gave up ongoing fees for software components I use to develop with Borland Turbo C++. I am not going back now.
I gave up ongoing fees for software components I use to develop with Borland Turbo C++. I am not going back now.
Any reason you can't use the LGPL license?
A fair question.
My interpretation is that I could switch to LGPL Qt for client software and keep my source code if I dynamically link to Qt.
I may be too strident as a commercial developer in my anti-LGPL 3 rhetoric, but my cloud-apps have been avoiding it assiduously. Client side, I should look for this kind of flexibility.
My interpretation is that I could switch to LGPL Qt for client software and keep my source code if I dynamically link to Qt.
I may be too strident as a commercial developer in my anti-LGPL 3 rhetoric, but my cloud-apps have been avoiding it assiduously. Client side, I should look for this kind of flexibility.
Even the GPL should not be a problem for you in the cloud, since you're not distributing the software, just provide a network interface to it. And the LGPL is even more forgiving. This web service use case is the reason for the AGPL, which does prescribe that even web services should open their code, should they use AGPL dependencies.
What are some good alternatives for native, cross-platform GUI applications? Qt used to be my preferred solution.
Flutter isn’t there yet (desktop support still in Alpha), but it might get there: https://flutter.dev/desktop
There is no alternative. No one other than Qt will expend the massive amount of effort to maintain such a thing. Everyone sees the writing on the wall with the new ARM Macs if it wasn't already apparent. Desktop applications are on their last leg. You will just write a mobile app and that will be backwards compatible with desktop automatically.
> You will just write a mobile app and that will be backwards compatible with desktop automatically.
A PWA? Sure. But a native app with seamless integration? No way.
Instead of Windows, macOS, and various Linux flavors, now you've got Windows, iOS, still macOS (for now), various Android versions, and various Linux flavors (including Chrome OS). Good luck!
(Depending on the type of app, you might also want or need to support various embedded devices or game consoles. I guess QT doesn't help there though.)
A PWA? Sure. But a native app with seamless integration? No way.
Instead of Windows, macOS, and various Linux flavors, now you've got Windows, iOS, still macOS (for now), various Android versions, and various Linux flavors (including Chrome OS). Good luck!
(Depending on the type of app, you might also want or need to support various embedded devices or game consoles. I guess QT doesn't help there though.)
> But a native app with seamless integration? No way.
https://developer.apple.com/documentation/apple_silicon/runn...
https://developer.apple.com/documentation/apple_silicon/runn...
>>Desktop applications are on their last leg. You will just write a mobile app and that will be backwards compatible with desktop automatically.
I don't understand your point. In your opinion what's a mobile app that's "backwards compatible with desktop", and what makes that app not a desktop app?
I don't understand your point. In your opinion what's a mobile app that's "backwards compatible with desktop", and what makes that app not a desktop app?
A mobile app written in portable code that runs without emulation on a desktop.
The desktop OS would expose the same platform SDK as the mobile OS. (Needless to say, apps depending on the accelerometer, selfie cam, etc. for major functionality would not work.)
This is already the case with the latest generation of Macs. No speculation necessary. It's possible and has been done. Also Chromebooks can run Android apps.
What remains to be seen is when (not if) Windows would mimic what Apple did, as they have been doing for the past decades. I suppose the easiest way would be to run Android (and Google Play) on WSL. Android and Google Play can run on x86–no need for emulation. How clunky this turns out is how willing MS and Google are to work together.
In the end there will just be two platforms you would have to support as a GUI applications developer: iOS and Android.
The desktop OS would expose the same platform SDK as the mobile OS. (Needless to say, apps depending on the accelerometer, selfie cam, etc. for major functionality would not work.)
This is already the case with the latest generation of Macs. No speculation necessary. It's possible and has been done. Also Chromebooks can run Android apps.
What remains to be seen is when (not if) Windows would mimic what Apple did, as they have been doing for the past decades. I suppose the easiest way would be to run Android (and Google Play) on WSL. Android and Google Play can run on x86–no need for emulation. How clunky this turns out is how willing MS and Google are to work together.
In the end there will just be two platforms you would have to support as a GUI applications developer: iOS and Android.
I think the idea is that developers will forgo tradition desktop development when then can just create an ipad app that works incidentally on the desktop and iOS. Personally not convinced when Windows still owns the desktop.
Developers have already foregone traditional desktop development since webapps and Electron took over. Webapps are as incidental of a substitute for desktop applications as mobile apps that run on desktop would be. Companies don't volunteer for expen$$$ive development work just out of a sense of purity when it doesn't bring in any more money.
Windows still owns the desktop but they mimic Apple. Also since ca. 2008 the population under 30 has been mostly on Apple. Those people will get older and replace the generation that was brought up on Windows.
Windows still owns the desktop but they mimic Apple. Also since ca. 2008 the population under 30 has been mostly on Apple. Those people will get older and replace the generation that was brought up on Windows.
Things are changing but I,d argue not as much as you might think. Also Apple has little or no presence in many countries.
[deleted]
Qt has been changing hands a lot. I assume it’s a money black hole at this point. The future is Electron. I don’t like it either but this is the nail in the coffin of Qt.
You're right, Electron app. are ok... If there is only one in RAM !
On my 8 GB computer, I used to run in the same time :
- VsCode (700 MB)
- Teams (600 MB),
- PostMan (350 MB !? WTF)
- WhatsApp (consumes almost 600 MB after 1 hour !)
I had to switch to the web version for the last 3...
In contrast, running 25 torrents with qBitTorrent: ~25 mb.
On my 8 GB computer, I used to run in the same time :
- VsCode (700 MB)
- Teams (600 MB),
- PostMan (350 MB !? WTF)
- WhatsApp (consumes almost 600 MB after 1 hour !)
I had to switch to the web version for the last 3...
In contrast, running 25 torrents with qBitTorrent: ~25 mb.
Yeah, the Silly Valley bubble doesn't realize how the rest of the world lives. In my third world country they're still selling _new_ (straight from the factory, this year's models) laptops with 4 GBs of RAM. Most models still come with 8 GBs of RAM (and most of them cost above of what I make in a month, and I pull a relatively decent paycheck). You get the idea.
> In my third world country they're still selling _new_ (straight from the factory, this year's models) laptops with 4 GBs of RAM
I live in France and there are 4GB here too: https://www.ldlc.com/informatique/ordinateur-portable/pc-por...
hell, in one of the biggest online retailers, the second biggest category is 2 gigabytes (number in parentheses is the number of laptop models available with that ram amount)
https://imgur.com/a/LL8H7aP
I live in France and there are 4GB here too: https://www.ldlc.com/informatique/ordinateur-portable/pc-por...
hell, in one of the biggest online retailers, the second biggest category is 2 gigabytes (number in parentheses is the number of laptop models available with that ram amount)
https://imgur.com/a/LL8H7aP
If I run more than two "browsers" my laptop slows to a crawl (I am in the USA, but I don't have the money for fancy stuff), so I have to decide to run Firefox (main browser), Chromium (test browser), VSCODE (IDE "browser"), or one of the other 50 "browsers" I have installed. Usually I have to run all of the above 3 when working, so I end up using OS tools to "freeze" the process of whichever "browser" I am not using at the time, but it causes problems.
I would be super happy if I could run several similar engines under one main process, I don't care as much about security concerns when I'm developing my own software, and would not mind some "intraprocess security holes" if I could reduce my memory footprint like that and then turn it off when I want the "security holes" to be closed again.
I would be super happy if I could run several similar engines under one main process, I don't care as much about security concerns when I'm developing my own software, and would not mind some "intraprocess security holes" if I could reduce my memory footprint like that and then turn it off when I want the "security holes" to be closed again.
It’s not as bad these days with SSDs
Actually it is, SSD does help a little bit with swapping for disk I/O if RAM gets full but in general keeping the app in RAM is much much faster than even SSD. Electron absolutely chews up RAM like crazy compared to just about every c++ based GUI I've ever used. I just thought I'd let you know that.
Yes, and stuff like pyside2 are pretty cool too (for people who don't like C++)
You could run WhatsApp on a browser instead of having another seperate chromium instance.
Yes, that's what I've done... (and not only it)
It is just to illustrate the fact that Electron, after all, might be a real problem for native app.
It is just to illustrate the fact that Electron, after all, might be a real problem for native app.
Whether one at a time is okay still depends on the app...
https://github.com/microsoft/vscode/issues/22900
https://github.com/microsoft/vscode/issues/22900
Hate to tell you, but 16Gb is a pretty much minimum now.
Running with 32 and looking for 64Gb laptop
Running with 32 and looking for 64Gb laptop
2GB laptop here, I can run several qt5 applications, with Electron I would bring to its knees with just three.
Ripcord instead of Discord and Slack.
Or a bitlbee gateway + IRSSI.
Yeah if all text works for you doing a bridge through IRC is the way to go. I think weechat also has some add on for discord, slack, and element
Any of these is suffice but I thought it was nice adding a mention of a lightweight Qt application.
I can do this but cannot do that at the same time.
Having 2Gb is pretty limited
Having 2Gb is pretty limited
Yes it is true, but in terms of CPU, there is an issue too...
(Lots of sub-processes by apps, means higher context switching, etc.)
And If I need 32GB and 16-CPU to run 5 or 6 apps...
Asimov was right after all :)
And If I need 32GB and 16-CPU to run 5 or 6 apps...
Asimov was right after all :)
Why is it the minimum though? Have we ever thought of that? I have 8 GB and it is increasingly becoming a problem and I will have to upgrade just because I want to have a browser and IntelliJ open.
Yes, It reminds me when Java has been released for the first time.
The mantra was : "Yes, pretty slow but don't panic, in a couple of months better hardware will fix that" !!
The mantra was : "Yes, pretty slow but don't panic, in a couple of months better hardware will fix that" !!
Hate to tell you, but 8GB is quite common across IT departments in 2020.
Then people with 8Gb laptops are limited to what they could do.
Hardware matters more than people
Do you really wants to limit your folks in such way for something like $150?
Hardware matters more than people
Do you really wants to limit your folks in such way for something like $150?
$150 is one month salary in quite a few countries actually.
My personal laptop has 8 GB, is 10 years old by now, I am not limited in anything I care about.
My personal laptop has 8 GB, is 10 years old by now, I am not limited in anything I care about.
In what world? In many parts of the world, the only machine people can afford have 4-8Gb RAM, And those machines cost a month pay.
So what? This is a business decision. You’re not likely to be a customer so why bother spending the effort?
Lol Electron? Yes the whole world wants ALL programs to be as shitty as the average webpage/webapp.
[deleted]
> you need to have a subscription for as long as you distribute your software with Qt6 under the commercial license!
Seems reasonable? As long as you're getting benefit from Qt by distributing software using it you need to keep paying for it?
Seems reasonable? As long as you're getting benefit from Qt by distributing software using it you need to keep paying for it?
If I buy a frying pan and open up a restaurant with it I don't have to keep paying the frying pan company so long as I use my pan to create meals. Subscriptions for software libraries and components weird me out much more than subscriptions for services and end-products (with recurring costs for the service providers) do.
But does that frying pan evolve new features or fixes while you have it and use it in your restaurant? Do you make requests to the manufacturer to make the handle bigger/smaller on the frying pan you own and use? Aren't there recurring costs in providing incremental updates to the software or support. Analogy sometimes seem perfect until you actually dissect them.
I feel like this is trivially resolved by selling a subscription to those additional services (e.g. for product updates or support agreements).
I'm just imagining a scenario where I build something with a subscription library and then 5 years down the line they get acquired by some private equity firm and increase the subscription cost by a factor of ten. Now I'm faced with a choice of either paying license ransom or losing the ability to use all of my own original software and creative effort.
I'm just imagining a scenario where I build something with a subscription library and then 5 years down the line they get acquired by some private equity firm and increase the subscription cost by a factor of ten. Now I'm faced with a choice of either paying license ransom or losing the ability to use all of my own original software and creative effort.
Your approach doesn't allow the vendor to reach the critical mass required to keep a product updated and evolving. I for one appreciate products that evolve and improve.
Something like Qt or Photoshop does not need to “reach critical mass” - they actually did already do that while using a simpler licensing model. Which proves the “everything is SaaS” model is not necessary, but rather another way to extract more money from customers.
This is true, but I think people have forgotten just how expensive software was a generation ago. Photoshop in the pre-Cloud days was a $600+ program depending on where you got it, with upgrade pricing in the $150–200 range. Today, you can get a "Photography" Creative Cloud subscription with Photoshop and Lightroom for $120/year.
I'm not in love with "everything is SaaS," but I recognize that a lot of software businesses really want recurring revenue rather than a rush of orders -- many of which are lower-priced upgrades -- when new releases come out, then a trickle until the next for-pay release (which a subset of your existing customers won't upgrade to). And, in an era where a lot of people have come to see upfront prices of $99+ for applications as outrageously high -- and worse, have been trained by app stores to expect free upgrades indefinitely -- the old model may just not be sustainable.
I'm not in love with "everything is SaaS," but I recognize that a lot of software businesses really want recurring revenue rather than a rush of orders -- many of which are lower-priced upgrades -- when new releases come out, then a trickle until the next for-pay release (which a subset of your existing customers won't upgrade to). And, in an era where a lot of people have come to see upfront prices of $99+ for applications as outrageously high -- and worse, have been trained by app stores to expect free upgrades indefinitely -- the old model may just not be sustainable.
> rather another way to extract more money from customers
This is just cynical!
This is just cynical!
Products grew and evolved perfectly fine under the old regime of perpetual licensing and paying for a new release
> I for one appreciate products that evolve and improve.
And I do not. Software updates are a huge pain in the ass for almost no benefit to me
> I for one appreciate products that evolve and improve.
And I do not. Software updates are a huge pain in the ass for almost no benefit to me
A problem I see as an outsider is that perpetual licenses where one pays when upgrading encourages companies to stay on the older version (which may have exploitable bugs) to avoid shelling out again. It has to be added to the budget when needed. Subscriptions don’t have that problem as the company can update without paying anything new and can keep the payments in the budget as a recurring expense.
Both sides have their benefits, so to say one is worse than the other seems not right. It’d be nice if there was an option on which model you chose (for example, $5k/seat for perpetual single version or $300/month/seat for subscription), but alas, that’s not available.
> And I do not. Software updates are a huge pain in the ass for almost no benefit to me
Ah, but there is a benefit that you just don’t see: bug and security fixes. Your boss isn’t going to be happy if your company is hacked because your IT department didn’t want to spend effort updating (assuming that’s in the budget).
This obviously ignores 0-days, but there’s not much a downstream user can do there.
Both sides have their benefits, so to say one is worse than the other seems not right. It’d be nice if there was an option on which model you chose (for example, $5k/seat for perpetual single version or $300/month/seat for subscription), but alas, that’s not available.
> And I do not. Software updates are a huge pain in the ass for almost no benefit to me
Ah, but there is a benefit that you just don’t see: bug and security fixes. Your boss isn’t going to be happy if your company is hacked because your IT department didn’t want to spend effort updating (assuming that’s in the budget).
This obviously ignores 0-days, but there’s not much a downstream user can do there.
My problem is that subscriptions have crossed over into the consumer space to become a tax on whatever it is you use the software for.
Take photoshop... I'm not a professional graphic artist, and I have need for PS maybe once a year at most. Depending on the importance of that need and my desire to own the software it might justify a onetime purchase. But with their subscription model it just isn't worth it.
One of the things I liked about the old model was it put professional tools into the hands of amateurs if they were willing to save up their money. Now, instead, you pay a yearly tax that is not insignificant for no real gain
Take photoshop... I'm not a professional graphic artist, and I have need for PS maybe once a year at most. Depending on the importance of that need and my desire to own the software it might justify a onetime purchase. But with their subscription model it just isn't worth it.
One of the things I liked about the old model was it put professional tools into the hands of amateurs if they were willing to save up their money. Now, instead, you pay a yearly tax that is not insignificant for no real gain
Oh absolutely. If one didn’t need the fancy new features of Adobe CS6, they could stay on CS5 as long as they wanted. But with CC, it’s a monthly fee regardless of if you use it at all that month.
But the flipside is that $10/month is a lot easier to stomach for most of the general public than a one time cost of $300+.
It’s why there’s monthly payment plans for everything expensive. $40/month for a (24 month) lease-to-own phone is a lot easier to budget for than a one time $900+tax purchase. But when I go to BestBuy or wherever, I have the option to choose the payment plan or upfront. Not with software.
But the flipside is that $10/month is a lot easier to stomach for most of the general public than a one time cost of $300+.
It’s why there’s monthly payment plans for everything expensive. $40/month for a (24 month) lease-to-own phone is a lot easier to budget for than a one time $900+tax purchase. But when I go to BestBuy or wherever, I have the option to choose the payment plan or upfront. Not with software.
Problem is Adobe's minimum contract length is a year. The monthly price quote is that price divided into months. After a year or two you could have afforded to outright buy it under the old regime.
They do have a monthly version which is a bit more expensive than the yearly-pay-monthly one they show. It’s hidden behind a click or two, but it’s there on the plan page. I know, because I considered it before choosing the yearly contract.
But yes, with subscriptions, it would be cheaper to buy it outright, but not everyone has that luxury. We can argue all day about whether people need Photoshop or whatever, but the best option (IMO) is to allow subscription and purchasing and let the user choose. Then those who can afford the $300+ up front can spend that while those with little disposable income can spend $10/month.
But yes, with subscriptions, it would be cheaper to buy it outright, but not everyone has that luxury. We can argue all day about whether people need Photoshop or whatever, but the best option (IMO) is to allow subscription and purchasing and let the user choose. Then those who can afford the $300+ up front can spend that while those with little disposable income can spend $10/month.
The fact that numerous software projects with different pricing or licensing models exist that have reached critical mass and evolve and improve over time proves your point is factually incorrect.
If there is no development, then the distributed software isn't using any of those new features and fixes.
They might come up with new features but I would need to reforge my pan in order to get them. If I don't need those features (wouldn't have bought the pan in the first place if I needed the features) then there's no need to do all that.
[deleted]
Judging by the FAQ, there's no commitment to 'evolve new features' or even 'receive fixes' in the licence. So the frying pan analogy is more accurate - one could end up paying again and again for no service at all.
While the FAQ says 'Maintenance is included', they phrase that as 'access to the latest version' and 'support'. That doesn't place any legal obligation on Qt to fix bugs.
Qt can leave Qt6 to rot, never update, and still get money from subscriptions. Or Qt could be busy with Qt7, and in order to receive said fixes one has to significantly invest and port the application.
Access to support means even less - they could automatically close all tickets and still techinically comply.
While the FAQ says 'Maintenance is included', they phrase that as 'access to the latest version' and 'support'. That doesn't place any legal obligation on Qt to fix bugs.
Qt can leave Qt6 to rot, never update, and still get money from subscriptions. Or Qt could be busy with Qt7, and in order to receive said fixes one has to significantly invest and port the application.
Access to support means even less - they could automatically close all tickets and still techinically comply.
> But does that frying pan evolve new features or fixes while you have it and use it in your restaurant? Do you make requests to the manufacturer to make the handle bigger/smaller on the frying pan you own and use?
No, but neither does the version of Qt in the already compiled and being distributed software, and yet even if no more development is done and no new version of Qt is used, it sounds like the licensing fee still applies.
No, but neither does the version of Qt in the already compiled and being distributed software, and yet even if no more development is done and no new version of Qt is used, it sounds like the licensing fee still applies.
[deleted]
Does the frying pan go back and time and re-cook all the food using the new-fangled super important features? I don't see why the cost of new features must be borne by existing applications that don't necessarily benefit from it. Just imagine a product that is largely in maintenance mode, that QT license is just sucking money without value.
You're welcome to argue QT saves more time than its license costs, but I didn't find that to be the case. Also cmake sucks, no bazel support, lame. I have found the QT value proposition questionable at best and have largely abandoned it. YMMV.
You're welcome to argue QT saves more time than its license costs, but I didn't find that to be the case. Also cmake sucks, no bazel support, lame. I have found the QT value proposition questionable at best and have largely abandoned it. YMMV.
Well, if the frying pan has bugs, customers are entitled to bug fixes, for free, from a legal PoV. After all, these are bugs ie. problems in the program.
New features, sure, ask money for that, fair enough.
Which is why I would be OK with Qt 6 having a new license model, as long as all bugs fixed in 6 are backported to previous stable (at least) ie. 5.x, without 5.x getting relicensed.
New features, sure, ask money for that, fair enough.
Which is why I would be OK with Qt 6 having a new license model, as long as all bugs fixed in 6 are backported to previous stable (at least) ie. 5.x, without 5.x getting relicensed.
What country are you from where bug fixes are guaranteed to be free forever? I am not aware of any country in the Americas or Europe that guarantees that unless said company enters a contractual agreement to provide you with bug fixes for free forever?
Security and reliability fixes should be free for consumers in EU. Else the product is not compliant to law (warranty lasts longer than 2 years contrary to popular belief). That law does not get enforced is unfortunate.
Then when not offer a perpetual fallback license? If you want to ship your product with version 6.1 and don't want to pay more for 6.2, so long as you paid for 6 months of 6.1 you should be able to use it (without support) for as long as you want.
Works for JetBrains.
Works for JetBrains.
They only offered that as an olive branch to all the people that disliked the perpetual licensing scheme. I don't hold a lot of hope for more widespread adoption as the beancounters most likely perceive it as leaving money on the table.
As it should. Our industry seems to have normalized rent-seeking as status quo
A frying pan is owned property.
Software is copyright literature under licence.
Software is copyright literature under licence.
Fair point. I'm personally not convinced that distinction is intrinsically meaningful rather than just legally and commercially convenient - especially in the case of libraries or programming languages. Qt is valueless as literature absent independent creative art that uses it to build a program - like screws in a piece of furniture. Charging people to use the component is fine by me, but making their own creative work contingent on third party approval that can be modified or revoked at any time seems unreasonable/immoral even if it's permitted by law.
You are conflating the IP of a company with the product people buy.
Let the authors enjoy reading their own creation. I'll pass.
Subscriptions are a perpetual source of revenue. They take your money for as long you use your product. There is nothing wrong with that.
Just because it's legal doesn't mean it's not a hug turnoff to potential customers. I'll pass and stick with other alternatives. I'd be happy to pay a large sum for the traditional "buy it, get free updates for a while, pay again for new updates after x months" but this "we own your software and you will pay forever", no thanks.
Subscriptions are much safer pricing models. You want apps, software etc. to be sold by subscription.
Why? Most businesses are not MS/etc. which have resilient multiple income streams. Many single-app companies either go under, or stop selling that app and so no longer update or support it.
A subscription model ensures that the developer always has a reliable app-specific income stream to justify investment & support.
Why? Most businesses are not MS/etc. which have resilient multiple income streams. Many single-app companies either go under, or stop selling that app and so no longer update or support it.
A subscription model ensures that the developer always has a reliable app-specific income stream to justify investment & support.
A subscription model also flips ownership. You're only ever renting and the owner can take it back at any time (often at their discretion).
Jetbrain's model is a good middle ground - you get perpetual access to versions released while your sub was active.
This was the “old” subscription model for desktop software. It’s the model most software with yearly updates was sold under (MS Office, Jira, etc, etc) and was basically a yearly subscription (to get access to new versions) except that it guaranteed the developer would be creating yearly releases to make it worth adopting newer versions, while the “current” subscription model doesn’t particularly encourage a company to continue innovating and developing to ensure their products don’t stagnate. The only problem with the old “yearly release w/ lifetime per-version” licensing is that it didn’t encourage refactoring, under-the-hood improvements, etc and encouraged needless churn with UI, etc as “progress for the sake of progress” to make it more appealing to upgrade on a yearly basis.
Yep, I’ve served my years as a dev under that model too :)
Correction: You get perpetual access to the oldest version released during your 1 year subscription period.
My JB subscriptions expire at the end of this month, if I don't re-up, I have to downgrade to 2020.1 versions and forego all the improvements and bugfixes in 2020.2 and 2020.3 (2020.3 is the latest release, which I'm currently using).
My JB subscriptions expire at the end of this month, if I don't re-up, I have to downgrade to 2020.1 versions and forego all the improvements and bugfixes in 2020.2 and 2020.3 (2020.3 is the latest release, which I'm currently using).
Thanks, I didn’t realise that. They say you get 2020.2.x releases, so you’d hope fixes for show stopping bugs would be back ported. Probably nothing smaller though, which is a shame.
It's such a weird system. The common logic for subscriptions is that you are paying for ongoing maintenance and updates (which is absolutely fair vs a one-off purchase). But if my active subscription helped fund those improvements, I think I should be entitled to continue using them after my sub expires.
It's a good thing their products are top notch.
It's a good thing their products are top notch.
I guess they do it to discourage on/off subscriptions, which I get. Would be better if they gave a bonus for unbroken subscription instead.
The ownership relationship doesn't change. Non- subscription licenses can be revoked/terminated too.
How?
Through legal means.
That seems very rare/special case and unlikely. Also it doesn't seem like it would hold water in court.
Qt is also licensed via LGPL
But for how much longer will new versions be released? Since they own all copyrights to the software, it's relatively easy to drop LGPL at any point on newer releases.
Sure, if they don’t mind Qt automatically being relicensing under BSD
“The little known KDE Free Qt Foundation makes sure that Qt stays free and open-source. It guarantees that all Qt modules currently licensed under LGPLv3 must continue to be available under LGPLv3 in the future. This covers all modules from Qt Essentials and many add-on modules. If The Qt Company discontinued the FOSS version of Qt, the Foundation would have the right to make Qt available under the BSD license. This is a very powerful protection of free and open-source Qt.“
https://www.embeddeduse.com/2019/12/21/safe-guarding-the-lgp...
https://dot.kde.org/2016/01/13/qt-guaranteed-stay-free-and-o...
“The little known KDE Free Qt Foundation makes sure that Qt stays free and open-source. It guarantees that all Qt modules currently licensed under LGPLv3 must continue to be available under LGPLv3 in the future. This covers all modules from Qt Essentials and many add-on modules. If The Qt Company discontinued the FOSS version of Qt, the Foundation would have the right to make Qt available under the BSD license. This is a very powerful protection of free and open-source Qt.“
https://www.embeddeduse.com/2019/12/21/safe-guarding-the-lgp...
https://dot.kde.org/2016/01/13/qt-guaranteed-stay-free-and-o...
> You want apps, software etc. to be sold by subscription.
I want options. Don't tell me what I want.
I want options. Don't tell me what I want.
There's a difference between "telling you what you want", and the sense here. In this case it just means, "it's in your interest"; as in, "you want to see this!".
In any case, "options" sounds good, but it is precisely this short-term economic logic I am claiming many misperceive as being in their interest.
There are many instances of apps (, libraries, etc.) simply disappearing and being frozen in old versions because of no revenue stream against them.
You may "want" something quite different 2yr after you've invested a massive amount in using Qt, only for there to be no future versions and your app becomes uncompetitive with others which are using increasingly modern libraries.
In any case, "options" sounds good, but it is precisely this short-term economic logic I am claiming many misperceive as being in their interest.
There are many instances of apps (, libraries, etc.) simply disappearing and being frozen in old versions because of no revenue stream against them.
You may "want" something quite different 2yr after you've invested a massive amount in using Qt, only for there to be no future versions and your app becomes uncompetitive with others which are using increasingly modern libraries.
It's not in my interest if it costs me more and makes future planning more difficult.
The software subscription business is essentially a huge price hike masked by paying in installments.
>simply disappearing and being frozen in old versions because of no revenue stream against them.
It means that the new features in version X were not good enough to entice new buys or upgrades.
Subscription model is great - for the software companies. It's not a good model for consumers.
The current subscription model will end up being just like Fifa or Madden games, the same thing every year with minor changes because consumers are locked-in and have no alternative.
The software subscription business is essentially a huge price hike masked by paying in installments.
>simply disappearing and being frozen in old versions because of no revenue stream against them.
It means that the new features in version X were not good enough to entice new buys or upgrades.
Subscription model is great - for the software companies. It's not a good model for consumers.
The current subscription model will end up being just like Fifa or Madden games, the same thing every year with minor changes because consumers are locked-in and have no alternative.
Yes, you really want to be at the mercy of some set of third parties, each one capable of bringing your business down. The more, the better.
None of them will ever abuse that dependency to take all of your profit. No, sir.
None of them will ever abuse that dependency to take all of your profit. No, sir.
Safer for investors that is. Which are as likely to bring the business o an end by optimizations and acquisitions as running out of money is.
That's insane. Back in the day you bought Photoshop (a tool) and could use it forever. You bought a tool you could use.
Now you need a subscription to keep using your tool? You need permanent Internet access, to keep using your tool? You need t keep paying to access you files?
This is why Affinity Photo will probably end up taking more and more market share away from Adobe's products.
Now you need a subscription to keep using your tool? You need permanent Internet access, to keep using your tool? You need t keep paying to access you files?
This is why Affinity Photo will probably end up taking more and more market share away from Adobe's products.
You never bought Photoshop. You licensed it. They're changing the way the licence works, is all.
If you don't like it, keep using your old version under the old licence.
If you don't like it, keep using your old version under the old licence.
This is false. You are a victim of a propaganda campaign that seeks to undermine the correct legal definitions.
In most jurisdictions, buying a copy of Photoshop is the purchase of a good.
In most jurisdictions, buying a copy of Photoshop is the purchase of a good.
> In most jurisdictions, buying a copy of Photoshop is the purchase of a good.
This may be how you wish things were, but not how they actually are.
Read any software licence and see what you are actually getting for your money.
This may be how you wish things were, but not how they actually are.
Read any software licence and see what you are actually getting for your money.
Old version of Photoshop (3.0, 4.0, ... CS5 up to CS6) gave you a license key you could sell. It didn't include a time limit. It was yours and you could sell it or use it forever. That's gone.
You can try to find old licenses for CS6, sure, but at some point, but it's a very different purchase and licensing system from what they have now.
You can try to find old licenses for CS6, sure, but at some point, but it's a very different purchase and licensing system from what they have now.
Exactly a licence key - which you could transfer to someone else. You didn't own the software. You owned a licence to use it.
That's false. When one purchases a copy of a (book|software|video), one then owns that good.
A typical proprietary software licence text is irrelevant when it comes to terms of ownership, transfer of ownership, use of the good etc. as the law applies and determines "how [things] actually are". A contract, let alone a unilaterally dictated licence text, is legally unable to take away certain rights the consumer enjoys.
A typical proprietary software licence text is irrelevant when it comes to terms of ownership, transfer of ownership, use of the good etc. as the law applies and determines "how [things] actually are". A contract, let alone a unilaterally dictated licence text, is legally unable to take away certain rights the consumer enjoys.
> Seems reasonable? As long as you're getting benefit from Qt by distributing software using it you need to keep paying for it?
No, the reasonable model (as someone how's shipped commercial libraries and researched the market) is that subscription gates support and future updates. So as long as the subscription is active you get updates, patches and support. Once it passes you're kept on old version. It's fair to the seller (keeps a steady revenue stream and most customers will want to keep the subscription for updates anyway) and fair to the customer (they can't be easily extorted with price hikes and their software doesn't get sabotaged by external subscription pricing).
No, the reasonable model (as someone how's shipped commercial libraries and researched the market) is that subscription gates support and future updates. So as long as the subscription is active you get updates, patches and support. Once it passes you're kept on old version. It's fair to the seller (keeps a steady revenue stream and most customers will want to keep the subscription for updates anyway) and fair to the customer (they can't be easily extorted with price hikes and their software doesn't get sabotaged by external subscription pricing).
The reasonable model is that the Qt company cannot be allowed to mess with the software their customers have developed and released, by requiring unexpectedly high fees or just terminating the license.
Why expect good faith and dependability with the precedent of their decision to screw KDE?
Why expect good faith and dependability with the precedent of their decision to screw KDE?
The problem is that you have no idea what they'll think is a reasonable license fee in 3 years (and that's not theoretical, Qt does change their mind on terms and fees regularly when there's another random sales target to meet). With the previous model, you only have that issue when you want to update, and know you can always ship what you currently have to your customers in the future at known cost.
I wonder if "cost lock-in" for 6.0 would make sense in this case? 7.0 is a new version with a new price? (or 6.1?)
This allows price increases with major changes.
"Free support for life" isn't sustainable, and striking the balance here is hard.
This allows price increases with major changes.
"Free support for life" isn't sustainable, and striking the balance here is hard.
Change for support. If I am happy with the version I have and don't need support I gain nothing in a subscription model based licensing.
If they had anything valuable with actual recurring costs then they wouldn't be this desperate to force you into their subscription model.
> "Free support for life" isn't sustainable, and striking the balance here is hard.
Image-Line (makers of FLStudio) have been pulling it off for a couple of decades now...
"Celebrating Lifetime Free Updates for over 20 years" -- right on their front page
Image-Line (makers of FLStudio) have been pulling it off for a couple of decades now...
"Celebrating Lifetime Free Updates for over 20 years" -- right on their front page
When I worked with Qt we built a product on top of Qt 4.8.4. Not 4.8.3, not 4.8.5. This was due to some very technical details, and the product was standalone and offline so updating wasn't a concern.
Why would we have to pay multiple times for the exact same piece of software, lines of code?
Also given that software is by default sold with defects (as it is "impossible" to write perfect software), it makes sense that the selling price includes, at least, future minor patches. I would consider them as the vendor covering for its own manufacturing defects (because that's what bugs are).
I agree however with charging for new features. That's fine and makes sense.
Why would we have to pay multiple times for the exact same piece of software, lines of code?
Also given that software is by default sold with defects (as it is "impossible" to write perfect software), it makes sense that the selling price includes, at least, future minor patches. I would consider them as the vendor covering for its own manufacturing defects (because that's what bugs are).
I agree however with charging for new features. That's fine and makes sense.
> Seems reasonable? As long as you're getting benefit from Qt by distributing software using it you need to keep paying for it?
Development, distribution and usage are different things. I don't have much of a problem with selling a subscription for the development environment, but for distribution and usage you should only need a (perpetual) runtime license, which you usually buy in bulk. AFAIK that's how QNX does it, for instance.
Development, distribution and usage are different things. I don't have much of a problem with selling a subscription for the development environment, but for distribution and usage you should only need a (perpetual) runtime license, which you usually buy in bulk. AFAIK that's how QNX does it, for instance.
>"Seems reasonable?"
Maybe to you. To me it reads like: do not ever touch this tool to do anything that has even remote chance to go commercial.
Maybe to you. To me it reads like: do not ever touch this tool to do anything that has even remote chance to go commercial.
Ironically, it’s easier if you don’t pay Qt and just use it as LGPL: ship it unmodified, distribuite Qt sources unmodified on request, and go your merry way.
This is theoretical for me. I am small company and have no time/desire/money for lawyers to decipher all those intricacies of LGPL (also they say that some stuff there is GPL). I prefer to pay reasonable one time fee for permanent license and upgrade when I feel it is needed.
These perpetual licenses are capitalism run amok. No one has an issue with subscriptions these days, but you should be able still compile and distribute your software without paying them into perpetuity if you're not worried about their latest and greatest. I'm just waiting for them to end LGPL in the next few years and why I don't use it any more. I use wxwidgets. Which I don't like as much but it gets the job done and I'm not doing anything fancy.
>Seems reasonable?
Yes. I dont quite understand what's the fuss here. So someone please explain to me like I am five.
QT 6 decide to charge money, in this case a commercial license for commercial usage. i.e If your software is making some money using QT6, you will have to pay. Otherwise you can happy use the LGPL License. Seems fair. You might disagree with its pricing, depending on your business model, And may be that business model would not be a good match / fit for using QT6.
But so far all the comments seems to be against the company charging anything. Why?
Yes. I dont quite understand what's the fuss here. So someone please explain to me like I am five.
QT 6 decide to charge money, in this case a commercial license for commercial usage. i.e If your software is making some money using QT6, you will have to pay. Otherwise you can happy use the LGPL License. Seems fair. You might disagree with its pricing, depending on your business model, And may be that business model would not be a good match / fit for using QT6.
But so far all the comments seems to be against the company charging anything. Why?
The root comment explicitly is about a change in the commercial (paid) licensing model, so no, the subthread is not about "charging anything".
> If your software is making some money using QT6, you will have to pay. Otherwise you can happy use the LGPL License
Nope, you can make a commercial closed-source application that links against LGPL-licensed library. Also, the source code model has nothing to do with "making money". For example, Qt is certainly "making money" with their source code, but did you know that the WebView component in Qt is actually COPIED from Apple's Safari WebKit source code? Yes! So they are STEALING Apple LGPL source code and making money with it! And what more, Apple Safari certainly runs on iPhones and Apple if someone is certainly making some big $$$!
You seem to have misunderstood what changed. No, Qt did not change the licensing terms to charge for "making money" with Qt. They just made more of their previously free support functions exclusive to paying licensees.
Nope, you can make a commercial closed-source application that links against LGPL-licensed library. Also, the source code model has nothing to do with "making money". For example, Qt is certainly "making money" with their source code, but did you know that the WebView component in Qt is actually COPIED from Apple's Safari WebKit source code? Yes! So they are STEALING Apple LGPL source code and making money with it! And what more, Apple Safari certainly runs on iPhones and Apple if someone is certainly making some big $$$!
You seem to have misunderstood what changed. No, Qt did not change the licensing terms to charge for "making money" with Qt. They just made more of their previously free support functions exclusive to paying licensees.
> Nope, you can make a commercial closed-source application that links against LGPL-licensed library.
So in this case, you'd have to package the software so it doesn't include Qt (in an RPM/deb) so it pulls in the system Qt? Or on Windows, provide them a link so they can download that component manually?
So in this case, you'd have to package the software so it doesn't include Qt (in an RPM/deb) so it pulls in the system Qt? Or on Windows, provide them a link so they can download that component manually?
Almost every comment in this thread against the subscription licensing model is addressing a legitimate issue. This comment is not—it's misinformation/FUD. That's not how the LGPL works. The cavalier attitude of people who just utterly make up bullshit, like what's in the comment above, is something that we should have a lot less tolerance for.
I always forget exactly what is permissible with the LGPL, but isn’t it the case that the whole point is that using a LGPL library doesn’t “infect” your program?
Generally it means you can't (in this case) mess with the Qt Libraries, you use them as is, and link to them dynamically. You do NOT have to release your source code, however you do have to provide Qt source (libraries) to anyone who requests them from you to whom you "have distributed" your software to (paid or unpaid), whether you provided a download link or DVD or usb drive, etc. If you someone received your software outside of your distribution channel you can tell them to go pound sand though since you didn't distribute to them directly and they got a copy through some other means.
No. It just means you have to ship Qt unmodified and provide sources to Qt on request.
oh .... well then what's the point of a commercial license? You'd only need it if you customize the original Qt source code and don't use it as-is, right? Or if you want support beyond forums/mailing lists?
Yes, but customizing and patching is not that uncommon for commercial software (Qt is used a lot in the embedded space, for example, where patching and shaving away is common).
Also, businesses do pay for support as insurance; say tomorrow Windows patches something that screws up a bit of Qt your product depends on, what are you going to do? Waiting for a reply on a random mailing list and hoping someone has time to fix it, is not going to cut it.
Also, businesses do pay for support as insurance; say tomorrow Windows patches something that screws up a bit of Qt your product depends on, what are you going to do? Waiting for a reply on a random mailing list and hoping someone has time to fix it, is not going to cut it.
As usual support and there are some libraries in the Qt Umbrella of source code that ARE NOT LGPL and you can't use those for distribution unless you pay for the commercial license.
Like 5 year old? Well, I have consulting business and sell solutions based on QT5. I can not use QT6, because it is impossible to buy a license for QT6.
Is there a plan to have native Windows 10 widgets ? The latest screenshot of the Windows widgets shows the classic widgets.
https://www.qt.io/hs-fs/hubfs/image-png-Nov-09-2020-06-37-27...
https://www.qt.io/hs-fs/hubfs/image-png-Nov-09-2020-06-37-27...
By Windows 10 widgets, do you mean UWP/Metro/Fluent widgets? In my opinion, the screenshot you linked is still common in Windows 10 apps.
If you want something closer to Metro, you can use Qt Quick and https://doc.qt.io/qt-5/qtquickcontrols2-styles.html#universa.... But Qt Widgets does not ship with a Metro-like theme.
Newer Windows 10 apps have Fluent design, including acrylic effects. I don't know if Qt Quick 2 supports that, but I'm not optimistic they've updated the appearance to match.
If you want something closer to Metro, you can use Qt Quick and https://doc.qt.io/qt-5/qtquickcontrols2-styles.html#universa.... But Qt Widgets does not ship with a Metro-like theme.
Newer Windows 10 apps have Fluent design, including acrylic effects. I don't know if Qt Quick 2 supports that, but I'm not optimistic they've updated the appearance to match.
Yes I'm thinking about fluent design widgets/theme.
I don’t know why 3rd-party widgets would bother with fluent design when the 1st-party offerings (e.g. WPF) don’t. Not even new Edge uses fluent design controls.
WinUI sort of has fluent, but it is extremely inconsistent. When should things be rounded vs squared? It’s completely inconsistent internally.
Even if Qt wanted to go fluent they’d have a hard time finding any concrete examples to work off of. I can’t think of any “fluent” apps that are consistent with themselves, consistent with the design system, and not breaking major rules.
WinUI sort of has fluent, but it is extremely inconsistent. When should things be rounded vs squared? It’s completely inconsistent internally.
Even if Qt wanted to go fluent they’d have a hard time finding any concrete examples to work off of. I can’t think of any “fluent” apps that are consistent with themselves, consistent with the design system, and not breaking major rules.
FWIW Microsoft has broken, twisted and sheared off the look and feel of Windows so severely in the releases since Windows 7 that it's less visually (and interactional-y) consistent than a Linux desktop in 2013 running a mix of Qt 4/5 and Gtk 2/3 apps, which truly is an achievement. Whatever era of Windows widget styling you're using, no one can argue it looks wrong, since nothing looks right any more. Half of the dialogs in Windows nowadays look like they were made by a confused 12 year old who just discovered BS_FLAT and uses it on everything.
The big difference between OS X/macOS and Windows is that when Apple restyle the UI, they make sure even the oldest apps get the new styles, though maybe not a full makeover. Microsoft on the other hand don't seem to want to do this? Even if they can't update third-party apps, why do they give so little attention to the built-in stuff? There's still the odd dialog straight out of Windows 3.1 in there even.
> I don’t know why 3rd-party widgets would bother with fluent design when the 1st-party offerings (e.g. WPF) don’t.
Sounds like an opportunity.
Sounds like an opportunity.
To do what? Use the fluent design widgets? Why would anyone want that?
If I'm asked at work to develop a multiplatform desktop application tomorrow, I will skip Qt because it looks too old fashioned on windows compared to what is developed nowadays.
I mean, Qt doesn’t have any native widgets for any OS (to the best of my knowledge and unless things have changed). They just have “skins” for their own widgets that mimic (sometimes successfully) the underlying platform’s native widgets. So all you’re really asking for is a new theme, unless you really meant “native” in which case the answer is no.
They started using native widgets a long while ago, but they can still be skinned.
Qt Widgets does not use native widgets on Win32 (I heard they're called "windows" there). It only spawns a single native window, and performs all input handling itself. Qt 5 has a mode (https://doc.qt.io/qt-5/qwidget.html#native-widgets-vs-alien-...) which uses native Win32 widgets, but they're more like blank canvases drawn by Qt, than actual Win32 push buttons, and still look slightly off. And it reduces performance.
Native widgets cannot be "skinned" on Windows and macOS, at least not to any appreciable extent.
They definitely can on Windows, and this is how many skinned programs were developed in the past. It's called owner draw.
Looks like they have abstracted the rendering to a Rendering Hardware Interface, this is what UE4 has I wonder if the name and API are inspired?
The nasty pretend exchanges between coworkers on this page is a really depressing way to highlight this tool: https://www.qt.io/design
I don't think any of those messages are nasty. It looks like a team of people who feel comfortable enough to vent to each other, while not taking themselves too seriously.
> Seriously, how many times are we going to tweak these?
Sounds super agressive to me, highly unprofessional.
Sounds super agressive to me, highly unprofessional.
[deleted]
And that's how we end up with stock images and press-release speak everywhere...
Doomed if you do, doomed if you don't.
Doomed if you do, doomed if you don't.
I know this is now an old thread, but just seeing it I feel it's worth responding. It is absolutely possible to be earnest and sincere in communicating real feelings and conflict without resorting to this ridiculously aggressive communication style. The alternative does not have to be fake or polished over.
This is not a dichotomous choice.
One person's funny is another person's cringy, when dealing with large groups of people.
So yes, at a certain scale it is a dichotomous choice. Ergo stock images and press-release speak.
* * *
I'll give you an example, right now:
Why "dichotomous"? You could have used "binary" and sounded much less pompous, without any special effort on your part.
See how "funny/interesting" vs "cringy" works on the internet? :-))
So yes, at a certain scale it is a dichotomous choice. Ergo stock images and press-release speak.
* * *
I'll give you an example, right now:
Why "dichotomous"? You could have used "binary" and sounded much less pompous, without any special effort on your part.
See how "funny/interesting" vs "cringy" works on the internet? :-))
Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.
Dichotomous was chosen because it was the correct word, not for any other reason.
Dichotomous was chosen because it was the correct word, not for any other reason.
Binary is also correct for that context ;-)
Regarding the last part, it was just a meant to be a funny jab, don't take it too seriously. I was just trying to prove, using your own words, that on the internet it's really easy for anything to turn into a binary choice.
You chose a less known word, a "fancy" word, and I pretended to be offended by it.
Just like Qt tried to add what they considered some funny lines to their examples, and several people here considered those lines "cringy".
Unless everything you say or present is bland, you can't really escape criticism. That's why many companies don't bother for these situations where being funny/interesting doesn't matter and they just "lorem ipsum" their way to the bank. There's nothing to gain, only to lose.
Regarding the last part, it was just a meant to be a funny jab, don't take it too seriously. I was just trying to prove, using your own words, that on the internet it's really easy for anything to turn into a binary choice.
You chose a less known word, a "fancy" word, and I pretended to be offended by it.
Just like Qt tried to add what they considered some funny lines to their examples, and several people here considered those lines "cringy".
Unless everything you say or present is bland, you can't really escape criticism. That's why many companies don't bother for these situations where being funny/interesting doesn't matter and they just "lorem ipsum" their way to the bank. There's nothing to gain, only to lose.
Didn't even notice those until you pointed them out. Truly cringe-worthy.
Qt is great and I get disappointed that the discussions surrounding it often devolve into nitpicking the pricing and licensing terms. Seems people are less willing to pay for high quality tools these days.
On the technical side, the qt quick desktop styling is intriguing. My main use case for Qt is for desktop applications and while qt quick is often recommended I usually go for qwidgets instead. 9/10 times I need a traditional interface with menu bars, forms and tables. While qt quick lets me make nice looking UI, I often need something that just works similarly to how a traditional desktop application works, looks be damned. Im curious if they'll manage to close that gap in qt6 but I'm skeptical which means I'll probably stay on widgets for the foreseeable future.
On the technical side, the qt quick desktop styling is intriguing. My main use case for Qt is for desktop applications and while qt quick is often recommended I usually go for qwidgets instead. 9/10 times I need a traditional interface with menu bars, forms and tables. While qt quick lets me make nice looking UI, I often need something that just works similarly to how a traditional desktop application works, looks be damned. Im curious if they'll manage to close that gap in qt6 but I'm skeptical which means I'll probably stay on widgets for the foreseeable future.
> Seems people are less willing to pay for high quality tools these days.
On the contrary, I think companies are more willing than ever to pay for quality 3rd-party tools and software. The reality is that the Qt licensing costs are a bargain relative to time saved for enterprise customers. It's not even a question at this point.
The complaints usually come from people thinking of lean startups or selling hobby projects, where the licensing overhead is another non-trivial number on your cost of goods sold. Many of the complaints here would only realistically be a problem for someone selling a very small number (<100) of their product per year with very low margin, which is far more rare than people think.
Regardless, Qt still has a separate small business license with a different pricing structure: https://www.qt.io/qt-for-small-business
On the contrary, I think companies are more willing than ever to pay for quality 3rd-party tools and software. The reality is that the Qt licensing costs are a bargain relative to time saved for enterprise customers. It's not even a question at this point.
The complaints usually come from people thinking of lean startups or selling hobby projects, where the licensing overhead is another non-trivial number on your cost of goods sold. Many of the complaints here would only realistically be a problem for someone selling a very small number (<100) of their product per year with very low margin, which is far more rare than people think.
Regardless, Qt still has a separate small business license with a different pricing structure: https://www.qt.io/qt-for-small-business
Another concern for lean startups and hobby projects are that you cannot develop them without first paying for a Qt license. Their licensing clearly states that you cannot transition from the open source license to a commercial license.
I've spent some time working on a desktop application I hope to sell, but I wont consider Qt, because I'm not even sure I will follow through and finish the product. When it's just a hobby class side-hustle, my first step isn't giving Qt $200 this month, and $200 next month, while I work on my side project for 2 hours a week after the kids go to sleep.
I've spent some time working on a desktop application I hope to sell, but I wont consider Qt, because I'm not even sure I will follow through and finish the product. When it's just a hobby class side-hustle, my first step isn't giving Qt $200 this month, and $200 next month, while I work on my side project for 2 hours a week after the kids go to sleep.
This.
There is the "small business plan" which reduces it down to $500/year, which isn't outrageous, but it's still $500 for something I probably won't get that value out of because of the likelihood of the project ever finishing.
Instead, I'll find other ways to do it. If Qt was free under $X, $500 under $Y, and $$$ over $Y it's a much more persuasive argument. Unreal manage it :)
There is the "small business plan" which reduces it down to $500/year, which isn't outrageous, but it's still $500 for something I probably won't get that value out of because of the likelihood of the project ever finishing.
Instead, I'll find other ways to do it. If Qt was free under $X, $500 under $Y, and $$$ over $Y it's a much more persuasive argument. Unreal manage it :)
As I understand it, Qt is released under a mix of GPL and LGPL, so as long as you release the source code of your application you should be fine.
I'm not sure how they can prevent you from transitioning from an open source license to a commercial license? You can develop your app for a year either as open source or privately without releasing anything, and then decide to purchase a license? Not sure if I'm missing something, but how does could they prevent this (legally or practically)?
I'm not sure how they can prevent you from transitioning from an open source license to a commercial license? You can develop your app for a year either as open source or privately without releasing anything, and then decide to purchase a license? Not sure if I'm missing something, but how does could they prevent this (legally or practically)?
The license explicitly specifies that you cannot start developing using the free license and then purchase a commercial license when going commercial.
Can you please cite and link the relevant part?
> If I have started development of a project using the open source version (LGPL), can I later purchase a commercial version of Qt and move my code under that license?
This is not permitted without written consent from The Qt Company. If you have already started the development with an open-source version of Qt, please contact The Qt Company to resolve the issue. If you are unsure of which license or version to use when you start development, we recommend you contact The Qt Company to advise you on the best choice based on your development needs.
https://www.qt.io/faq/tag/qt-commercial-licensing?hsLang=en
https://www.qt.io/faq/tag/qt-commercial-licensing?hsLang=en
You should be fine with the LGPL license of Qt.
I would like my application to be easy to distribute. I was hoping to distribute it as a single executable file. I don't think this is possible with the LGPL?
You would distribute it anyway as one file, because you're going to pack it into something which does the install. i.e. dmg/pkg file, installer, Linux package, etc.
I don't think I've ever seen a Mac app which consisted of only one file. The whole idea behind .app apps is that they consist of several files.
I don't think I've ever seen a Mac app which consisted of only one file. The whole idea behind .app apps is that they consist of several files.
> I was hoping to distribute it as a single executable file
I don't know of any applications whose scope would require to use Qt to come as a single file.
The installer (be it dmg, exe, pkg, whatever) will, but then it's not a problem with the LGPL.
I don't know of any applications whose scope would require to use Qt to come as a single file.
The installer (be it dmg, exe, pkg, whatever) will, but then it's not a problem with the LGPL.
People bring up this misconception every time Qt is mentioned. It is free as in beer (LGPL) at least on desktop. You can sell a proprietary commercial application using Qt without paying a dime as long as you dynamically link Qt (which can be included in the installation bundle).
(But you shouldn't. There is little need to distribute closed source software anymore. If you are shipping a binary with valuable trade secrets, then it won't be secret for very long. You can do server-side rendering of all the UI like all the large cap tech companies do then it won't matter if the client application at the edge is open source.)
(But you shouldn't. There is little need to distribute closed source software anymore. If you are shipping a binary with valuable trade secrets, then it won't be secret for very long. You can do server-side rendering of all the UI like all the large cap tech companies do then it won't matter if the client application at the edge is open source.)
I similarly stick to QtWidgets, but have to say they don’t seem to scale well in Windows. That’s likely a function of the underlining Windows components, but it’s undeniable, sadly. QtQuick / QML deals better with that scenario, but one ends up having to reinvent a bunch of things (ironically, considering the “quick”) that QtWidgets have had for years already.
Qt posts to HN never include a single technical comment. It is unfortunate, but I suppose that's mostly due to the particular subset of programmers that visits HN.
I use Qt professionally. What exactly do you want me to say here?
Salivate over bullet points on a release announcement when we treat every update as maintenance to a core featureset that's been sufficient since Qt 4.8? Jump into a tangent about the meta object compiler on a release announcement? Talk about the translation system apropos of nothing?
The only things that matter here to me now are if the license details change, if they made breaking design changes or deprecated features.
Salivate over bullet points on a release announcement when we treat every update as maintenance to a core featureset that's been sufficient since Qt 4.8? Jump into a tangent about the meta object compiler on a release announcement? Talk about the translation system apropos of nothing?
The only things that matter here to me now are if the license details change, if they made breaking design changes or deprecated features.
> Salivate over bullet points on a release announcement
For instance.
> when we treat every update as maintenance to a core featureset that's been sufficient since Qt 4.8?
Or discuss why this is true for 'we'.
> Talk about the translation system apropos of nothing?
How is that more nothing than license details?
For instance.
> when we treat every update as maintenance to a core featureset that's been sufficient since Qt 4.8?
Or discuss why this is true for 'we'.
> Talk about the translation system apropos of nothing?
How is that more nothing than license details?
It is the culture of free beer. On my circle most developers don't even care that sites like HN and Reddit exist.
They do whatever is needed, mostly with commercial software, and then leave to home, where their hobbies are completely unrelated to coding.
In what concerns Qt 6, I care about the multiple 3D backend, C++17 and the upcoming QML to C++ compiler.
They do whatever is needed, mostly with commercial software, and then leave to home, where their hobbies are completely unrelated to coding.
In what concerns Qt 6, I care about the multiple 3D backend, C++17 and the upcoming QML to C++ compiler.
Mind that nice things also come from the crowd which you call hipster, whereas your 9-5 crowd is writing some dotnet accounting app. I couldn't care less about what enterprise java developers do, not because I disrespect them, but it's not discussed because it's not interesting.
It seems like you somehow think paid shitty software was / is better than free shitty software. Mind that free shitty software has its upsides too.
And counterpoint: People don't hate intellij like they hate oracle or Qt. People hate takeover by suits.
It seems like you somehow think paid shitty software was / is better than free shitty software. Mind that free shitty software has its upsides too.
And counterpoint: People don't hate intellij like they hate oracle or Qt. People hate takeover by suits.
I bet the majority those non hater people using InteliJ don't pay for it, and the enterprise customers are the majority of their paying customers, and most likely they also get some money from godfather Google thanks to Android Studio and Kotlin.
Speaking of which, if eventually Google ends up buying them, lets see how much love is left.
Speaking of which, if eventually Google ends up buying them, lets see how much love is left.
Yep, that doesn't counter my main point though.
We all know there's a dark matter of enterprise programmers, out of which a good portion is perfectly capable, but just doing it as work 9-5. But that's not what we expect to see on HN/Reddit/open source projects.
You seem to not like that dev tools are not a sustainable business today. That was kind of inevitable. Using paid dev tools alienates contributors in open source development, and students/3rd world can't afford them, and lot of paid tools are specialized to some domains (think SAP). Doesn't help that proprietary vendors try to lock down stuff and lot of rent seeking behavior (Oracle, qt company)..
Atlassian made some steps in lowering this barrier of entry, and built a pretty good business IMO, though not much developer specific.
If there's anything to learn, unless there's an app store like low barrier to entry platform for dev tools with student discounts, free trials etc.. people may learn paying for high quality developer tools.
We all know there's a dark matter of enterprise programmers, out of which a good portion is perfectly capable, but just doing it as work 9-5. But that's not what we expect to see on HN/Reddit/open source projects.
You seem to not like that dev tools are not a sustainable business today. That was kind of inevitable. Using paid dev tools alienates contributors in open source development, and students/3rd world can't afford them, and lot of paid tools are specialized to some domains (think SAP). Doesn't help that proprietary vendors try to lock down stuff and lot of rent seeking behavior (Oracle, qt company)..
Atlassian made some steps in lowering this barrier of entry, and built a pretty good business IMO, though not much developer specific.
If there's anything to learn, unless there's an app store like low barrier to entry platform for dev tools with student discounts, free trials etc.. people may learn paying for high quality developer tools.
Naturally I don't like, something like C++ Builder is impossible to achieve if one relies on the people that want to get paid, while unwilling to pay for their tools, just like in every other profession.
Somehow a culture of people that feels entitled not to pay for their tools has sprung off, killing a whole industry that naturally only focus on enterprise customers.
Wth everyone trying to kill GPL and its derived licenses, this will eventually be a thing of the past, then everyone will just suck it up with the demo version, BSD/MIT license, or shell out for the commercial version.
Somehow a culture of people that feels entitled not to pay for their tools has sprung off, killing a whole industry that naturally only focus on enterprise customers.
Wth everyone trying to kill GPL and its derived licenses, this will eventually be a thing of the past, then everyone will just suck it up with the demo version, BSD/MIT license, or shell out for the commercial version.
Weird, last time I noticed Qt being discussed on HN, I got a really useful and technical comment which is still something I'm basing my future plans on.
You can't say that and then not link the comment!
Can you provide an example of a comment sufficiently technical to be worthy?
I'm saying there isn't one (well, a hundred messages in and there are a handful at last :) ). Nobody is discussing what's new for instance. I'd be interested in the status of moc (isn't mentioned on the page).
The MOC is still present in Qt 6.0, if that is what you are asking.
Even with CMake?
Question should be "even with C++17?". Cmake has had moc and uic support for years now. The question is why they don't leverage the c++17 features to get rid of moc, ffs.
There is some features used by moc expected in c++23 like reflection. I think that in qt 7 they will drop moc an some stl replcements in qtcore
> Even with CMake?
Why would Cmake eliminate the need for Qt's moc? Cmake is a build system/makefile generator. You don't generate c++ from form files or Qt-annotated C++ files out of magic.
Why would Cmake eliminate the need for Qt's moc? Cmake is a build system/makefile generator. You don't generate c++ from form files or Qt-annotated C++ files out of magic.
Yes.
That's orthogonal. And people have been using CMake with Qt (and moc) for almost as long as cmake exists
I've never switched from Qt widgets to QML. It is more important to me that the controls look platform standard. Also I am a programmer, not a designer.
I would recommend waiting for Qt 6.1 before considering using QtQuick/QML. They are apparently fixing a load of the issues with QML in that release. As it stands QML is kind of a mess.
I've always had that impression. I've been using Qt for 10+ years (professionally for half that) and I've always used QtWidgets. QML always seemed flimsy to me, and all those futuristic UIs... Not sure how they work with the c++ qt libs.
The core idea is kind of ok. But they screwed it up in a few ways:
1. Using Javascript. It's not a good language, especially without Typescript. And it's type system doesn't match C++'s well at all. For example you can't really pass uint64s to QML very easily. Apparently Javascript will be optional in 6.1.
2. The scene graph. A good idea but I'm pretty sure there's still no way to make custom QML widgets that contain text because there's still no public QSGTextNode (at least last time I looked into it). Here's people trying to do it in 2013: https://forum.qt.io/topic/24179/how-to-draw-text-in-qquickit...
I think they've pretty much given up on letting users make custom QML widgets - instead you have to use QPainter and it copies the resulting image across, which seems like a step backwards.
3. The encapsulation is really bad. I honestly never figured out the rules around widget ID scope because it seems like they are all in a global scope so all widgets can refer to any other widget (e.g. children can depend on their parents) which encourages spaghetti. Not sure if they're fixing this.
4. It's really hard to do transient widgets like dialogs. This is kind of the same as in React but it still seems like a step backwards from QtWidgets.
5. Lots of the QtQuick widgets are really lacking features compared to QtWidgets. It's like they got to the MVP and then gave up.
I haven't tried it for a number of years so some of those thing may have improved but I haven't heard about it. I get the impression that 90% of their income comes from car manufacturers using Qt for their software, which is why there is such a focus on fancy 3D UIs.
1. Using Javascript. It's not a good language, especially without Typescript. And it's type system doesn't match C++'s well at all. For example you can't really pass uint64s to QML very easily. Apparently Javascript will be optional in 6.1.
2. The scene graph. A good idea but I'm pretty sure there's still no way to make custom QML widgets that contain text because there's still no public QSGTextNode (at least last time I looked into it). Here's people trying to do it in 2013: https://forum.qt.io/topic/24179/how-to-draw-text-in-qquickit...
I think they've pretty much given up on letting users make custom QML widgets - instead you have to use QPainter and it copies the resulting image across, which seems like a step backwards.
3. The encapsulation is really bad. I honestly never figured out the rules around widget ID scope because it seems like they are all in a global scope so all widgets can refer to any other widget (e.g. children can depend on their parents) which encourages spaghetti. Not sure if they're fixing this.
4. It's really hard to do transient widgets like dialogs. This is kind of the same as in React but it still seems like a step backwards from QtWidgets.
5. Lots of the QtQuick widgets are really lacking features compared to QtWidgets. It's like they got to the MVP and then gave up.
I haven't tried it for a number of years so some of those thing may have improved but I haven't heard about it. I get the impression that 90% of their income comes from car manufacturers using Qt for their software, which is why there is such a focus on fancy 3D UIs.
I just don't understand the free/commercial differentiation. I was trying to get some projects working from uni, and I wasn't sure what I was allowed to do nowadays. I thought it all had to be commercially licensed so gave up.
Most people (especially small indie devs) will be fine with the free LPGL version, regardless of whether you charge for your software or whether it is open source or not. Just make sure that you dynamically link the Qt libraries (so the end-user can theoretically replace them if they want to) and don't use any of the GPL-only add-ons (unless you are OK licensing your whole product as GPLv3).
You can statically link as well:
https://www.gnu.org/licenses/gpl-faq.en.html#LGPLStaticVsDyn...
https://www.gnu.org/licenses/gpl-faq.en.html#LGPLStaticVsDyn...
I knew someone would bring that up! Yes you can statically link but its harder to go that route and probably not worth it for most people (although for some platforms like iOS you might have to, not sure about that).
I've used Qt for over 15 years and I've never once wanted/needed to statically link it since dynamic linking has always worked just fine for the type of apps I've worked on.
I've used Qt for over 15 years and I've never once wanted/needed to statically link it since dynamic linking has always worked just fine for the type of apps I've worked on.
At least as of Qt 5, the main drivers were static linking, liability, and not having to say you’re using Qt, iirc.
We migrated away from Qt in large part because of the licensing uncertainty. The discussion always devolves into nitpicking about the license and pricing, because it's such a major handicap for Qt.
It feels like every six months they completely revamp the licensing program, and the LGPL version always seems to suffer from a corporate sword of Damocles
It feels like every six months they completely revamp the licensing program, and the LGPL version always seems to suffer from a corporate sword of Damocles
Unlike most other dual licensed software, Qt Company has legally binding agreement with KDE related to LGPL licensed version.
What they have done in last year is to retreat to the minimum they need to do to comply. They can't stop distributing the LGPL version or alter the deal anymore.
Unlike what you hear you can make commercial closed source software and link LGPL binaries dynamically or statically, makes no difference. You just need to have to provide linkable object files to comply. Just stuff them into some /gpl_comply/ directory and be done with it.
What they have done in last year is to retreat to the minimum they need to do to comply. They can't stop distributing the LGPL version or alter the deal anymore.
Unlike what you hear you can make commercial closed source software and link LGPL binaries dynamically or statically, makes no difference. You just need to have to provide linkable object files to comply. Just stuff them into some /gpl_comply/ directory and be done with it.
Any idea where one could learn more about the legally binding agreement? Especially wondering (i don't expect you to answer these, just wondering if you happen to know or know where one could read about it):
1. When was this entered into
2. What there "good and valuable consideration" exchanged and what was it?
3. Are there any other projects in an agreement like this?
Edit: Great resource, still reading through it and the many links: https://kde.org/community/whatiskde/kdefreeqtfoundation/
1. When was this entered into
2. What there "good and valuable consideration" exchanged and what was it?
3. Are there any other projects in an agreement like this?
Edit: Great resource, still reading through it and the many links: https://kde.org/community/whatiskde/kdefreeqtfoundation/
Dealing with static linkage is a giant pita because you have to provide all the object files for your code basically. I don’t think anyone really bothers with statically linking LGPL Qt into a non-OSS executable.
> a giant pita
It's not hard at all. You can add them to some directory with your app, or they can be behind some url, or you can mail them physically in a USB stick to anyone who requests them by mail or phone.
You just have to be able to provide them if somebody wants them. In reality nobody ever wants them. It's just some directory with gpl-stuff/ you add to your software.
How hard it is to have some binaries lying around?
It's not hard at all. You can add them to some directory with your app, or they can be behind some url, or you can mail them physically in a USB stick to anyone who requests them by mail or phone.
You just have to be able to provide them if somebody wants them. In reality nobody ever wants them. It's just some directory with gpl-stuff/ you add to your software.
How hard it is to have some binaries lying around?
The complexity comes into getting that machinery going in your build system and hosting. Additional complexities arise very quickly once you start optimizing your build (cmake object targets, LTO). I’m not saying it’s infeasible. Just saying that usually it’s easier to ship the Qt DLL and be done with it. From my observation of the space I’ve not seen anyone really ship the “here’s the object file” approach (it had happened before I’m sure but it’s not the norm for a reason).
Just do your linking in a final build step that 1: Only reads in object files and resources (ie rejects source code); 2: Bundles up all the object files into an archive; 3: Outputs the final executable alongside the archive.
You mentioned LTO. Don't the LLVM and GCC LTO implementations currently involve outputting compiler IR to object files, then running the optimization passes against the full collection of object files prior to linking? So they inherently collect all the object files together in a linkable form.
(Of course, it's probably more efficient to just dynamically link Qt and pay for a license if you want to publish for iOS.)
You mentioned LTO. Don't the LLVM and GCC LTO implementations currently involve outputting compiler IR to object files, then running the optimization passes against the full collection of object files prior to linking? So they inherently collect all the object files together in a linkable form.
(Of course, it's probably more efficient to just dynamically link Qt and pay for a license if you want to publish for iOS.)
It's actually quite simple: https://news.ycombinator.com/item?id=23321785
Yeah. I'm giving up on it for these reasons:
- For CLI apps, Rust has a better event loop, better language, more libraries, and is easier to deploy
- QWidgets seems like it's not "cool" anymore, and I don't feel like learning QML. I liked QWidgets because it was mostly the same from Qt 4.0 through Qt 5.0.
- The commercial side has no financial interest in adding cool new features to the LGPL code
- So how long will volunteers keep fixing the LGPL side, when their work is funding a business that does not help them?
- I'm waiting to see how Copperspice (A Qt fork that cuts off support for older C++ versions and uses STL and UTF-8 aggressively) turns out
About 10 years ago, Qt was my _jam_. I did everything in Qt. Games, CLI, GUI, IRC bots. I think I tried to build a Qt web server a couple times. For a kid who hated Windows and web stuff, it was my gateway to event loops and modern programming concepts. I just quit loving it. It's still in use at work, but I'm making plans to back out of it. Oh well.
- For CLI apps, Rust has a better event loop, better language, more libraries, and is easier to deploy
- QWidgets seems like it's not "cool" anymore, and I don't feel like learning QML. I liked QWidgets because it was mostly the same from Qt 4.0 through Qt 5.0.
- The commercial side has no financial interest in adding cool new features to the LGPL code
- So how long will volunteers keep fixing the LGPL side, when their work is funding a business that does not help them?
- I'm waiting to see how Copperspice (A Qt fork that cuts off support for older C++ versions and uses STL and UTF-8 aggressively) turns out
About 10 years ago, Qt was my _jam_. I did everything in Qt. Games, CLI, GUI, IRC bots. I think I tried to build a Qt web server a couple times. For a kid who hated Windows and web stuff, it was my gateway to event loops and modern programming concepts. I just quit loving it. It's still in use at work, but I'm making plans to back out of it. Oh well.
> - I'm waiting to see how Copperspice (A Qt fork that cuts off support for older C++ versions and uses STL and UTF-8 aggressively) turns out
Copperspice forked at the time of Qt 4.8 and has had since then a couple thousands commits from a dozen contributors - in the meantime Qt itself had literally tens of thousands of commits, bugfixes, new features, etc from hundreds of contributors
Copperspice forked at the time of Qt 4.8 and has had since then a couple thousands commits from a dozen contributors - in the meantime Qt itself had literally tens of thousands of commits, bugfixes, new features, etc from hundreds of contributors
A lot of those commits are related to features some people might not care about. For example, I imagine a lot of work has been done on the JavaScript compiler for QML - but if only use QWidgets, that's irrelevant to me.
Actually I'm only talking about the qtbase repo (core, gui, widgets, network...) in the Qt case, while for copperspice since they forked before 5.0 it's still a monorepo and the commits encompass everything (eg same that for Qt, plus script, WebKit and a few others they kept).
> I'm waiting to see how Copperspice (A Qt fork that cuts off support for older C++ versions and uses STL and UTF-8 aggressively) turns out
It's been around for 7 years and is maintained by two people as opposed to a publicly traded corporation (Qt) with hundreds of employees. It has already turned out.
There is no alternative to Qt. It is the best in its class.
But you don't need it. You don't need Electron either. Just build a .NET application for Windows, a SwiftUI one for Mac, and a ncurses one for Linux. They can all share the same business logic code (if it has any), either via C ABI, IPC, or RPC. Your application will always be at the bleeding edge with the latest security patches and accessibility this way, as opposed to waiting for the next Qt/Electron release which is guaranteed to be later than the OS bugfix. Imagine if desktop OSes release, in addition to dark mode, a pink mode. Do you want your application to stand out as the ugly duckling?
It's been around for 7 years and is maintained by two people as opposed to a publicly traded corporation (Qt) with hundreds of employees. It has already turned out.
There is no alternative to Qt. It is the best in its class.
But you don't need it. You don't need Electron either. Just build a .NET application for Windows, a SwiftUI one for Mac, and a ncurses one for Linux. They can all share the same business logic code (if it has any), either via C ABI, IPC, or RPC. Your application will always be at the bleeding edge with the latest security patches and accessibility this way, as opposed to waiting for the next Qt/Electron release which is guaranteed to be later than the OS bugfix. Imagine if desktop OSes release, in addition to dark mode, a pink mode. Do you want your application to stand out as the ugly duckling?
> (..). and a ncurses one for Linux.
Nurses as an alternative to a QtWidgets GUI app? I'm not sure you're serious.
Nurses as an alternative to a QtWidgets GUI app? I'm not sure you're serious.
Most Linux users would prefer a well-designed curses application over a GUI. You don't have to ask me, just look at what Linux users actually run and share screenshots of. I'm talking about real Linux distro users not Chromebook users.
> Most Linux users would prefer a well-designed curses application over a GUI.
I've been using linux both professionally and for personal use for over a decade and, with the exception of working over ssh, the thought of using ncurses apps over good old GUI apps is so outlandish that it doesn't even register in the realm of possibility.
Your comment sounds like a meme of how linux users are detached from the real world with regards to usability.
I've been using linux both professionally and for personal use for over a decade and, with the exception of working over ssh, the thought of using ncurses apps over good old GUI apps is so outlandish that it doesn't even register in the realm of possibility.
Your comment sounds like a meme of how linux users are detached from the real world with regards to usability.
The applications I write are mostly GUI code, so that would mean nearly 3 times the work.
"So how long will volunteers keep fixing the LGPL side, "
As far as I know, it's not 'indy devs' supporting the LPGL, rather the LPGL is merely a term of release of the regular, mainline branch. It's the 'same code'. Am I missing something?
As far as I know, it's not 'indy devs' supporting the LPGL, rather the LPGL is merely a term of release of the regular, mainline branch. It's the 'same code'. Am I missing something?
For the core and majority of the library, yes, but some specific features (eg Charts) have been released as commercial-only.
Charts and several other modules are released both under GPLv3 licensing and commercial licensing. For Qt6 some of these modules have not been released yet, but should be available by 6.2, the first LTS.
How else do you fund such a horrendously difficult thing? There is a reason there are no other cross platform UIs that are QT’s equal. Creating a good looking cross platform UI that supports things like accessibility and provides a close to native app experience (or can) is a real slog of a programming project. It must also be constantly maintained as native APIs change out from under it, hardware advances (e.g. higher DPI displays, HDR), and UI trends change.
Pay for Qt or pay for developer time to maintain multiple versions of your UI. Your pick. Qt is probably cheaper in most cases.
Pay for Qt or pay for developer time to maintain multiple versions of your UI. Your pick. Qt is probably cheaper in most cases.
That's why we end up with many Electron applications. I mean even big companies like Slack or Spotify use Electron.
Spotify is CEF (Chromium Embedded Framework) as is the Adobe CC desktop application.
CEF is geared toward native C++ and is probably more of a Qt alternative than Electron in that regard.
CEF is geared toward native C++ and is probably more of a Qt alternative than Electron in that regard.
I can confirm Spotify GNU/Linux client appears to use libcef. I was surprised! I had read some old Internet posts that claimed Spotify GNU/Linux client was using Qt. (I have no idea about old versions of the GNU/Linux client.)
When I run command "ldd" on my Spotify GNU/Linux client binary, I see "libcef.so". And, I can see:
$ ls -l /usr/share/spotify/libcef.so
-rw-rw-r-- 1 root root 147980856 Sep 15 06:13 /usr/share/spotify/libcef.so
That's a big library!
When I run command "ldd" on my Spotify GNU/Linux client binary, I see "libcef.so". And, I can see:
$ ls -l /usr/share/spotify/libcef.so
-rw-rw-r-- 1 root root 147980856 Sep 15 06:13 /usr/share/spotify/libcef.so
That's a big library!
I wish this comment could be moved all the way to the top of the thread, to preempt all licensing discussion.
I agree completely. If I made a commercial app I would pay.
My concern is that I don't trust Qt Company now to not change the rules on me later, or hike the price, etc. I would choose Qt for commercial solely because I already know it from building FLOSS apps. If I need to learn something else for FLOSS, I'm not going to stick with Qt. There's limited space in my brain for expertise and I want something that will meet all needs.
Qt is amazing and I love it, but an amazing thing I love but can't use/rely on isn't worth much.
My concern is that I don't trust Qt Company now to not change the rules on me later, or hike the price, etc. I would choose Qt for commercial solely because I already know it from building FLOSS apps. If I need to learn something else for FLOSS, I'm not going to stick with Qt. There's limited space in my brain for expertise and I want something that will meet all needs.
Qt is amazing and I love it, but an amazing thing I love but can't use/rely on isn't worth much.
The thing is, of course, that you don't need to trust the Qt Company. That's why we have the KDE-Free Qt foundation, and that alone makes Qt the best choice for anyone who developers software that can use LGPL libraries, commercial or open source.
I'd guess they really want to get rid of the LGPL option (which was introduced when Qt was owned by Nokia and presumably they were more interested in Qt as a platform to develop their own products on than as a revenue stream), but the KDE Free Qt agreement means they can't just get rid of it.
Qt is GPL and LGPLv3[0]; gtk is LGPLv2[1]. Is there that much difference?
0: https://www.qt.io/licensing/
1: https://gitlab.gnome.org/GNOME/gtk/-/blob/master/COPYING
0: https://www.qt.io/licensing/
1: https://gitlab.gnome.org/GNOME/gtk/-/blob/master/COPYING
And Gtk isn't a good option for non-Linux use. wxWidgets is LGPL (sort-of, modified) as well. wxWidgets is much more reasonable than Gtk for cross-plattform use, though can't compete with Qt Widgets in terms of features, API design, ease of use, stability etc.
It seems really weird to me how "but teh licenz" is brought up every time with Qt, when Qt itself is available under the same licenses as all the other toolkits like Gtk, wxWidgets etc.
This doesn't quite apply for embedded development (as LGPL's Tivoization clause might start to bite), but 1.) neither Gtk nor wxWidgets are viable in that space anyway 2.) considering that other people here found that Tesla manages to ship their car firmware with LGPL Qt - well. Can't be that hard to comply with it. Also, 3.) while we're used to free tools and libraries for desktop development, it's much more common to pay for tools in embedded development.
It seems really weird to me how "but teh licenz" is brought up every time with Qt, when Qt itself is available under the same licenses as all the other toolkits like Gtk, wxWidgets etc.
This doesn't quite apply for embedded development (as LGPL's Tivoization clause might start to bite), but 1.) neither Gtk nor wxWidgets are viable in that space anyway 2.) considering that other people here found that Tesla manages to ship their car firmware with LGPL Qt - well. Can't be that hard to comply with it. Also, 3.) while we're used to free tools and libraries for desktop development, it's much more common to pay for tools in embedded development.
Gtk isn't even a good option for Linux use. Outside of GNOME, it just does not even try to fit in and behave.
It there a good option nowadays?
FOX is really fast and looks OK, but I don't think it's very actively developed, and binding to C++ seems like a pain. And I'm not sure it supports CJK input methods.
I looked at EFL out of desperation, but that's pure style over substance and the complete opposite of what I'd want.
FOX is really fast and looks OK, but I don't think it's very actively developed, and binding to C++ seems like a pain. And I'm not sure it supports CJK input methods.
I looked at EFL out of desperation, but that's pure style over substance and the complete opposite of what I'd want.
FOX is actively developed, but only by 1 person. Unfortunately it does not support CJK input methods.
I tried to use wxWidgets awhile back and gave up. It was a mess. Macros everywhere.
I've only ever used its Python bindings, and wxWidgets was pleasant to use for my use case.
The design of wxWidgets is very familiar to someone who started on MFC. There were reasons (perf, mostly) to write code that way back when MFC was a thing, but we certainly have better ways now.
I've used Qt for several projects in the past, but with this latest news I'm looking at GTK seriously now.
Why would you say GTK isn't a good option for non-Linux use? And would you say that it is a good option for Linux?
Why would you say GTK isn't a good option for non-Linux use? And would you say that it is a good option for Linux?
> Why would you say GTK isn't a good option for non-Linux use? And would you say that it is a good option for Linux?
You need something like MSYS2 to even use GTK on Windows, and I've looked at what it takes to package and distribute GTK applications to Windows users without MSYS2, and it's headache inducing.
When it comes to Linux, it's pretty good. Getting its GObject Introspection dependencies compiled is another story, though. I've always had to rely on my distribution's package manager to install them.
You need something like MSYS2 to even use GTK on Windows, and I've looked at what it takes to package and distribute GTK applications to Windows users without MSYS2, and it's headache inducing.
When it comes to Linux, it's pretty good. Getting its GObject Introspection dependencies compiled is another story, though. I've always had to rely on my distribution's package manager to install them.
I think LGPLv3 has anti-tivoization provisions. That said, I don't see how Gtk's license has anything to do with The Qt Company's recent antics. I'm in no way advocating people choose Gtk over Qt.
Can you elaborate on exactly the lawyers are on about the 'sword'?
Theoretically, the LPGL should enable commercial use, right?
Are there specific barbs in the wire that Qt has placed, or is it merely a situation of lawyers afraid of grey areas?
Theoretically, the LPGL should enable commercial use, right?
Are there specific barbs in the wire that Qt has placed, or is it merely a situation of lawyers afraid of grey areas?
>"Qt is great"
Absolutely when one looks at pure technical side. Their licensing however progressed to the point that feels like extortion to me.
Absolutely when one looks at pure technical side. Their licensing however progressed to the point that feels like extortion to me.
Re: "I often need something that just works similarly to how a traditional desktop application works, looks be damned."
It's annoying how many dump efficient UI design to chase the latest fads. We Vulcans cry.
It's annoying how many dump efficient UI design to chase the latest fads. We Vulcans cry.
Seems that Qt WebEngine and WebView aren't available until Qt 6.2 (end of September 2021). Bummer!
https://www.qt.io/blog/add-on-support-in-qt-6.0-and-beyond
https://www.qt.io/blog/add-on-support-in-qt-6.0-and-beyond
I miss the Qt Webkit module, it give so much more control over WebEngine. WebEngine is great but anyone one who want to use will be much better served using Electron
No Windows 7 support?
Microsoft itself doesn't even support Windows 7 anymore. Why should Qt 6?
https://docs.microsoft.com/en-us/lifecycle/products/windows-...
https://docs.microsoft.com/en-us/lifecycle/products/windows-...
That's 2 very different things.
Microsoft not-supporting Windows 7 doesn't mean you can't use it. That means it keeps working, you can use it as you always did, but they won't make (and push down your throat) any more patches.
A library/app not-supporting a particular OS/version usually means you actually can't use it. And there often is no serious technical reason.
Microsoft not-supporting Windows 7 doesn't mean you can't use it. That means it keeps working, you can use it as you always did, but they won't make (and push down your throat) any more patches.
A library/app not-supporting a particular OS/version usually means you actually can't use it. And there often is no serious technical reason.
Microsoft does support Windows 7 through the Extended Security Updates (ESU) program which last utill 2023 and 2024 for the Windows Embedded POSReady 7
https://docs.microsoft.com/en-us/lifecycle/faq/extended-secu...
Moreover Microsoft just released .NET 5 with Windows 7 support.
https://github.com/dotnet/core/blob/master/release-notes/5.0...
https://docs.microsoft.com/en-us/lifecycle/faq/extended-secu...
Moreover Microsoft just released .NET 5 with Windows 7 support.
https://github.com/dotnet/core/blob/master/release-notes/5.0...
I feel like that answers it's own question.
> The Extended Security Update (ESU) program is a last resort option for customers who need to run certain legacy Microsoft products past the end of support.
Windows 7 is EOL. ESU is meant to run legacy applications for some time after OS EOL. By definition, legacy applications will not use Qt 6.0.
> The Extended Security Update (ESU) program is a last resort option for customers who need to run certain legacy Microsoft products past the end of support.
Windows 7 is EOL. ESU is meant to run legacy applications for some time after OS EOL. By definition, legacy applications will not use Qt 6.0.
I really like the language Microsoft is using regarding the EOL and ESU things.
I mean when you think about it Microsoft is doing pretty much the same thing during the two periods. It's just that past a certain point they are sure you would have moved on if you could and now they can price gouge you. It's a clever way to do pricing differenciation.
I mean when you think about it Microsoft is doing pretty much the same thing during the two periods. It's just that past a certain point they are sure you would have moved on if you could and now they can price gouge you. It's a clever way to do pricing differenciation.
Microsoft would frame it as "after a certain point almost everyone has moved on and they feel safe to EOL it. But for a lot of money you can convince them to still make some updates for another few years".
It's pretty clever no matter how you frame it. Deciders get a clear deadline, but once they inevitably run into the deadline completely unprepared they still have a way to get another three years transition period. Everyone is happy, and MS is a bit richer.
It's pretty clever no matter how you frame it. Deciders get a clear deadline, but once they inevitably run into the deadline completely unprepared they still have a way to get another three years transition period. Everyone is happy, and MS is a bit richer.
> ESU is meant to run legacy applications for some time after OS EOL
That's not correct, unless you count google chrome (and many other programs) as a legacy application.
https://9to5google.com/2020/11/20/google-chrome-windows-7/
That's not correct, unless you count google chrome (and many other programs) as a legacy application.
https://9to5google.com/2020/11/20/google-chrome-windows-7/
Chrome isn't a legacy app which requires Windows 7 ESU to run.
Microsoft still supports Windows 8.1.
True, a good point!
Still, I think it makes sense that Qt 6 requires Windows 10. New development and legacy support are always at odds.
If customers want new software, then they must accept that it has modern requirements. Same situation for continued development and evolution of existing software.
In situations where support for legacy systems is more important than new development, then existing applications can just continue to use Qt 5. I don't see how it would make sense to migrate to Qt 6 in this situation.
Still, I think it makes sense that Qt 6 requires Windows 10. New development and legacy support are always at odds.
If customers want new software, then they must accept that it has modern requirements. Same situation for continued development and evolution of existing software.
In situations where support for legacy systems is more important than new development, then existing applications can just continue to use Qt 5. I don't see how it would make sense to migrate to Qt 6 in this situation.
Just in case, here is the same Sciter that happily runs on Windows 10 but on Windows 2000 in new application: https://sciter.com/necromancing-sciter-on-windows-2000/
Maybe someday I'll see Qt and not think "Huh, Quicktime?"
Oh wow, Qt has moved to CMake as a build system? I remember fighting with qmake back in 2008 and trying to integrate it into our build system (and trying to get it to play nice with bjam for some reason). This is welcome news.
What's specifically is new that Qt itself is built using cmake. You could use cmake to build apps using Qt for quite a while already.
Did you even need qmake if you understood the MOC subsystem well enough to say write a cmake or gnu make file for it? I didn't think qmake was ever a requirement?
Do they still use Moc?
yes.
There was some effort to make it possible to use Qt without moc [0] and instead rely on some more modern C++ features. No clue where the effort is these days
0: https://woboq.com/blog/verdigris-qt-without-moc.html
0: https://woboq.com/blog/verdigris-qt-without-moc.html
Now that I'm thinking of it, the Boost C++ libraries have a signals/slot implementation:
https://www.boost.org/doc/libs/1_63_0/doc/html/signals.html
(probably already superseded by more modern C++ constructs)
https://www.boost.org/doc/libs/1_63_0/doc/html/signals.html
(probably already superseded by more modern C++ constructs)
There isn't anything in boost, and even less in c++20 that gets anywhere close to the codegen & runtime reflection that Qt provides. We need reflection & metaclasses/constexpr code generation but the way it looks it won't be in before c++26.
Takeaway for GTK+ crowd: Qt thrives, and GTK certainly doesn't.
KDE, and Gnome are both toolkits flagship projects.
Look at how much developer share KDE gained, and Gnome lost in the time since Gnome 3.0.
The reason is they had few very toxic "thought leaders" who alienated countless developers, and they did not have courage to give them a well deserved kick to the butt, not even an idea that doing so would be right.
Now, if they want to recover, even if they will give a kick to Lennart & Co., how would they do so if they have no normal devs left to deliver that kick, and carry on the project after?
KDE, and Gnome are both toolkits flagship projects.
Look at how much developer share KDE gained, and Gnome lost in the time since Gnome 3.0.
The reason is they had few very toxic "thought leaders" who alienated countless developers, and they did not have courage to give them a well deserved kick to the butt, not even an idea that doing so would be right.
Now, if they want to recover, even if they will give a kick to Lennart & Co., how would they do so if they have no normal devs left to deliver that kick, and carry on the project after?
My impression is that while Qt has quite widespread adoption, KDE is still pretty niche. The majority of that I'd guess is that Qt makes a point to be cross-platform. Gtk since 3.0 is pretty well Linux-only and content to stay that way.
It's an irony given that GTK 3.0 made a move for modularised rendering in hopes of getting more cross-platformable.
Gnome is still the default in most of the big distributions -- but arguably its most popular incarnation, Ubuntu's, deviates significantly from upstream's vision for the default Gnome desktop.
Some of these things are pretty hilarious to watch from the outside. For design/UX considerations, Gnome 3 hasn't supported desktop icons in a while now -- so a bunch of distributions ship it with one of the (several) desktop icon extensions, none of which are very functional, along with a bunch of other extensions, like Dash-to-Dock. So every time an unsuspecting user gets a work-issued Ubuntu laptop, you get to watch them trying to figure out how to drag a folder to the desktop, or pin a folder to the dock or whatever.
FWIW, though, KDE has a pretty wide install base in some popular distros, e.g. Arch: https://pkgstats.archlinux.de/fun .
Some of these things are pretty hilarious to watch from the outside. For design/UX considerations, Gnome 3 hasn't supported desktop icons in a while now -- so a bunch of distributions ship it with one of the (several) desktop icon extensions, none of which are very functional, along with a bunch of other extensions, like Dash-to-Dock. So every time an unsuspecting user gets a work-issued Ubuntu laptop, you get to watch them trying to figure out how to drag a folder to the desktop, or pin a folder to the dock or whatever.
FWIW, though, KDE has a pretty wide install base in some popular distros, e.g. Arch: https://pkgstats.archlinux.de/fun .
What does the Tk family lack to make "thrivable"? It doesn't have built-in resizable editable data grids, but that gap alone is not a show-stopper.
Tk is a nice little GUI toolkit, but feature-wise it isn't even comparable to Qt in any way. Personally I started with Tk but it turned out to be too limited, so I switched to Qt.
Qt is an application framework – it's much more than just a "GUI toolkit".
Tk is nice, but also small and very limited in scope, which is great for some use cases, but less so for others. It's like the difference between a desktop environment like GNOME or KDE, which do much more than just "manage windows", and a more basic window manager like i3 or the countless others that are out there.
Tk is nice, but also small and very limited in scope, which is great for some use cases, but less so for others. It's like the difference between a desktop environment like GNOME or KDE, which do much more than just "manage windows", and a more basic window manager like i3 or the countless others that are out there.
GTK is actually used quite a bit more on mobile these days thanks to all the distros and software targeting Pine Phone and Librem.
GTK is thriving by all accounts. Could there be more devs on GTK itself? Yes. Are more and more applications being written in GTK? Yes. Look at Flathub and all the developers putting applications out there.
Which distros are shipping with KDE by default?
SuSE.
SUSE Linux Enterprise Desktop currently ships GNOME (and IceWM) and doesn't even mention KDE:
https://www.suse.com/releasenotes/x86_64/SUSE-SLED/15/ https://documentation.suse.com/sled/15-SP2/
You may be thinking of openSUSE.
https://www.suse.com/releasenotes/x86_64/SUSE-SLED/15/ https://documentation.suse.com/sled/15-SP2/
You may be thinking of openSUSE.
I know it's rhetorical, but... openSUSE
Kubuntu, KDE Neon
Slackware: Plasma 5 was just moved from testing this week in Current (for the upcoming Slackware 15).
Xfce, Cinnamon, and MATE all have a significant user base and they use GTK.
For me personally, the takeway is that both GTK and QT are getting old.
React (and Svelte, etc.) have completely changed the way we build apps, and typical QT & GTK apps are still being written in a retained mode approach with signals & callbacks like 20 years ago.
QML is quite interesting but it doesn't feel immediate mode enough like React & Svelte.
Flutter, JetPack Compose, Crochet, Fidget, Revery, MakePad, Svelte, etc. all those bring so many new ideas. GTK or QT feel so complicated and hard maintain in comparaison
React (and Svelte, etc.) have completely changed the way we build apps, and typical QT & GTK apps are still being written in a retained mode approach with signals & callbacks like 20 years ago.
QML is quite interesting but it doesn't feel immediate mode enough like React & Svelte.
Flutter, JetPack Compose, Crochet, Fidget, Revery, MakePad, Svelte, etc. all those bring so many new ideas. GTK or QT feel so complicated and hard maintain in comparaison
I don't know if that's true or not, but I just like Gnome so much more as a DE that it's a shame to read that.
We have used Qt in our video meeting products for a few years now and are pretty happy with it. For us it was especially important to have the same UI on plain embedded Linux, Android and Windows.
We were always going to use the commercial version so licensing wasn't a major problem, no worse than any other commercial library.
We were always going to use the commercial version so licensing wasn't a major problem, no worse than any other commercial library.
Your windows app is not using QT as far as I can tell unless it is linked statically. Where do you use QT?
This is for our "bring your own device" meeting room system: https://support.starleaf.com/installing/starleaf-room-for-wi...
Nice to see someone on HN trying out StarLeaf by the way.
Nice to see someone on HN trying out StarLeaf by the way.
Only viable Qt competitor in embedded is Rightware Kanzi. Has anyone here experience with them?
(ps. Most people lamenting the price of Qt have no need for Qt, should not buy Qt. If you have never heard about Kanzi or Telerik, you are not in the market)
(ps. Most people lamenting the price of Qt have no need for Qt, should not buy Qt. If you have never heard about Kanzi or Telerik, you are not in the market)
> Only viable Qt competitor in embedded is Rightware Kanzi. Has anyone here experience with them?
Kanzi is a cosmic horror in comparison to Qt in terms of low level bugs, which you cannot do anything about.
Kanzi tries to differentiate as a purpose built built HMI environment where you get UI+hardware IO+readymade apps, but sucks greatly at being it. Hardware support is where you don't even try using anything, but reference hardware.
Kanzi is a cosmic horror in comparison to Qt in terms of low level bugs, which you cannot do anything about.
Kanzi tries to differentiate as a purpose built built HMI environment where you get UI+hardware IO+readymade apps, but sucks greatly at being it. Hardware support is where you don't even try using anything, but reference hardware.
Thanks.
I know nothing of the product but investment analysts say it's the only competitor in embedded.
I know nothing of the product but investment analysts say it's the only competitor in embedded.
What is Flutter missing, in your opinion, for it to be a viable competitor?
> What is Flutter missing, in your opinion, for it to be a viable competitor?
Maturity and the breadth of the surrounding ecosystem, for one. Flutter is looking very promising long-term, but it's going to take some time to evolve past a mobile app framework.
Qt is most widely known for the UI framework, but it actually has far more functionality under the hood. Qt's core target audience values those features. Most of the people who see Qt as a simple UI framework don't.
Like the parent comment said, most of the people who are complaining about the licensing costs are on the wrong side of the Qt value proposition. They should use simpler, freely available tools like Flutter or Electron.
Maturity and the breadth of the surrounding ecosystem, for one. Flutter is looking very promising long-term, but it's going to take some time to evolve past a mobile app framework.
Qt is most widely known for the UI framework, but it actually has far more functionality under the hood. Qt's core target audience values those features. Most of the people who see Qt as a simple UI framework don't.
Like the parent comment said, most of the people who are complaining about the licensing costs are on the wrong side of the Qt value proposition. They should use simpler, freely available tools like Flutter or Electron.
Do Flutter apps run on Windows or is it just development that can be done on Windows?
Never heard. I willing to bet that it's some framework for mobile, web and desktop.
I said __embedded__
I said __embedded__
The Flutter engine API has no platform specific dependencies, has a stable ABI and is available in its entirety in a single C header file [1]. It's ideal for embedding.
[1] https://github.com/flutter/engine/blob/080fbcb1759e5916f0d6c...
[1] https://github.com/flutter/engine/blob/080fbcb1759e5916f0d6c...
I just can't imagine scenario where it's cheaper to use something like Flutter and port, test, debug and maintain it in operating systems and devices myself or find consults to do it to me.
I'm an entrepreneur with 6 guys working for me. 4 of them write embedded software, 1 uses Qt. I pay for Qt because cost/value is right. I don't develop any more software than I have to. I get a product, I can buy consulting with reasonable price.
I'm an entrepreneur with 6 guys working for me. 4 of them write embedded software, 1 uses Qt. I pay for Qt because cost/value is right. I don't develop any more software than I have to. I get a product, I can buy consulting with reasonable price.
> I pay for Qt because cost/value is right.
Aren't this paid for by the customer which might be priced into the product or for your consulting services?
Aren't this paid for by the customer which might be priced into the product or for your consulting services?
> I just can't imagine scenario where it's cheaper to use something like Flutter and port, test, debug and maintain it in operating systems and devices myself or find consults to do it to me.
Currently, you're exactly right. Google is using Flutter for some of their embedded products, but it's going to be a long time before it's anywhere near as plug-and-play as Qt for the average developer.
The future of Flutter is looking quite promising, though. It's worth keeping an eye on.
Currently, you're exactly right. Google is using Flutter for some of their embedded products, but it's going to be a long time before it's anywhere near as plug-and-play as Qt for the average developer.
The future of Flutter is looking quite promising, though. It's worth keeping an eye on.
Isn’t flutter based on skia? Or is that integration abstracted away?
So, cards on the table I've been a Qt apologist, but the subscription thing for distribution seems nuts. But I'm genuinely curious: if I wanted to build a {thing}, how should I license it so that I can get credit and make money for my work, while also supporting FOSS? I think traditionally the model here is "GPL or you can pay for a perpetual commercial license". I think that's reasonable (and I think clearly not what Qt is doing anymore) strategy; are there things I should consider?
Qt is for-profit business forced to provide open source library. Isn't that better than paying peanuts for struggling dual-licensing open source company?
Qt company is publicly listed for-profit company with zero interest in open source. Their business is growing fast and their stock is up 700% in last 3 years.
Qt is contractually obligated to to provide LGPL version for the core library forever. Recently they just retreated to minimum requirement their legal agreement with KDE foundation requires. Yes, Qt the company does not want to serve those who use LGPL license, but that's just small number of extra hoops for free product you don't have to pay for.
Qt company is publicly listed for-profit company with zero interest in open source. Their business is growing fast and their stock is up 700% in last 3 years.
Qt is contractually obligated to to provide LGPL version for the core library forever. Recently they just retreated to minimum requirement their legal agreement with KDE foundation requires. Yes, Qt the company does not want to serve those who use LGPL license, but that's just small number of extra hoops for free product you don't have to pay for.
TIL The Qt Company's stock ticker is 2QT.
That's under the Frankfurt Stock Exchange (FRA).
Under Helsinki Stock Exchange (HEL), it is QTCOM. Company was founded in Finland.
It's not the answer you wanted, but to cure you of all the legal headaches, consider Electron, with its MIT License :)
Electron uses Blink as a renderer which is LGPL. Everyone who ships an Electron app has to apply to the LGPL terms in the exact same way than for Qt. It's just the Electron API itself which is MIT.
If I'm not mistaken, Electron also ships with FFMPEG which is also LGPL.
Source: the copyright headers here: https://chromium.googlesource.com/chromium/blink/+/refs/head...
Source: the copyright headers here: https://chromium.googlesource.com/chromium/blink/+/refs/head...
Bye bye cute QT
I see a lot of people that in this thread saying things along the lines of "just use it under LGPL". As somebody who uses Qt in a commercial setting, it is not that simple. The Qt Company will start twisting arms if they catch wind that you're not letting them squeeze you, and if your company has an antsy legal department, they're not even going to consider fucking around when The Qt Company starts snooping around to see if you're compliant; your lawyers will tell you to cough up and deal with the perpetual rent seeking they introduced with their subscription model. I've seen it happen first hand, and it can only be worse now that they force you to have an account with them to download the pre-built binaries they host.
I love Qt. For all of its warts, it is wildly powerful and doesn't get anywhere near the appreciation it deserves. With that out of the way, don't consider it for new commercial projects unless you're cool with being bled dry every step of the way by The Qt Company. As wonderful as it is, The Qt Company (either by design or ignorance) keeps expanding its expensive and confusing licensing model, and it doesn't look like that is ever going to get any better.
I love Qt. For all of its warts, it is wildly powerful and doesn't get anywhere near the appreciation it deserves. With that out of the way, don't consider it for new commercial projects unless you're cool with being bled dry every step of the way by The Qt Company. As wonderful as it is, The Qt Company (either by design or ignorance) keeps expanding its expensive and confusing licensing model, and it doesn't look like that is ever going to get any better.
It seems they dropped ball on mobile devices (iOS/android). In last few years they where mostly focusing on embedded, automotive and desktop. I wish they provided more indie friendly alternative license for mobile market something similar like Unreal Engine had e.g. taking ~5% of your revenue.
I know they recently provide 'small company license' and ~500usd/year is justified as long it's just hobby project if only your as a dev. The moment you reach $250k as a startup and have to hire few devs and pay $5k/year per each developer is making this less affordable. On top of that if you focusing on mobile devices (android/ios) probably you would need to have Felgo license (to cover some Qt limitations) which is crazily even more expensive.
At this point in few years Flutter, ReactNative, Unity, Unreal Engine and Electron will be slowly stealing more of Qt market.
I know they recently provide 'small company license' and ~500usd/year is justified as long it's just hobby project if only your as a dev. The moment you reach $250k as a startup and have to hire few devs and pay $5k/year per each developer is making this less affordable. On top of that if you focusing on mobile devices (android/ios) probably you would need to have Felgo license (to cover some Qt limitations) which is crazily even more expensive.
At this point in few years Flutter, ReactNative, Unity, Unreal Engine and Electron will be slowly stealing more of Qt market.
I like developing in Qt. It is well designed, well documented and comprehensive. I like the power of slots and signals.
My experience developing Qt applications for ~20 years (mostly for Windows and Mac) is that it is very well supported on Windows, but less well supported on Mac. I really wish they would concentrate a bit more on making it look more native and be less buggy on the lastest version of macOS, rather than adding new features.
I list a few current issues with Qt 5.15 on macOS 11.0 here: https://successfulsoftware.net/2020/12/07/issues-with-qt-app...
And dialog widget layouts never look quite right on macOS.
I am not aware that Qt 6 fixes any of these issues. I hope they get fixed soon.
My experience developing Qt applications for ~20 years (mostly for Windows and Mac) is that it is very well supported on Windows, but less well supported on Mac. I really wish they would concentrate a bit more on making it look more native and be less buggy on the lastest version of macOS, rather than adding new features.
I list a few current issues with Qt 5.15 on macOS 11.0 here: https://successfulsoftware.net/2020/12/07/issues-with-qt-app...
And dialog widget layouts never look quite right on macOS.
I am not aware that Qt 6 fixes any of these issues. I hope they get fixed soon.
IMO the worst part about this is not the pricing change but the fact that they advertise using CMake as a selling point.
I note that Qt 6 will not be in Debian any time soon:
https://perezmeyer.blogspot.com/2020/08/stepping-down-as-qt-... https://lists.qt-project.org/pipermail/development/2020-Augu...
https://perezmeyer.blogspot.com/2020/08/stepping-down-as-qt-... https://lists.qt-project.org/pipermail/development/2020-Augu...