Qt 6.4(qt.io)
qt.io
Qt 6.4
https://www.qt.io/blog/qt-6.4-released
147 comments
Tried to use QT for a new product based on a STM32F769 MCU some time ago. I got laughed at and waved off when asking for the budget needed to buy/licence QT stuff. To be fair, they need a business model, but the target audience seems just to be automotive or anyone who's planning to roll out something with at least a million pieces in mind.
> I got laughed at and waved off when asking for the budget needed to buy/licence QT stuff.
This.
Regardless of Qt's technical merit, it's licensing automatically takes it out of the table of most of all potential projects.
https://www.qt.io/pricing
This.
Regardless of Qt's technical merit, it's licensing automatically takes it out of the table of most of all potential projects.
https://www.qt.io/pricing
They work really hard to hide this, but they do have a LGPL license that applies to most of the framework, and only some parts (charts, etc.) are GPL/commercial only. For those old enough to remember, this license issue was at the heart of the Gnome/KDE schism.
From their site <https://www.qt.io/download-open-source>: LGPL – Any modification to a Qt component covered by the GNU Lesser General Public License must be contributed back to the community. This is the primary open source Qt license, which covers the majority of Qt modules.
If you're not familiar, in practice, the difference between GPL and LGPL is that LGPL does allow dynamically linking a library with a closed source program, without requiring that the program also becomes GPL/LGPL. This is compatible with most development as long as you either don't modify Qt, or are ok with those modifications becoming open source.
From their site <https://www.qt.io/download-open-source>: LGPL – Any modification to a Qt component covered by the GNU Lesser General Public License must be contributed back to the community. This is the primary open source Qt license, which covers the majority of Qt modules.
If you're not familiar, in practice, the difference between GPL and LGPL is that LGPL does allow dynamically linking a library with a closed source program, without requiring that the program also becomes GPL/LGPL. This is compatible with most development as long as you either don't modify Qt, or are ok with those modifications becoming open source.
LGPL3 is a no-go for a lot of embedded projects, as OP is probably finding.
The anti-tivoization clauses mean you need to provide a way to install user-built Qt libraries on the target device. You might think that's not a big deal until you go to work for an automotive or medical company and meet up with the massive wall of lawyers that tell you no fucking way.
The anti-tivoization clauses mean you need to provide a way to install user-built Qt libraries on the target device. You might think that's not a big deal until you go to work for an automotive or medical company and meet up with the massive wall of lawyers that tell you no fucking way.
But those projects should have the budget for a real license, so that's not a real issue.
The problem is typically people not bothering to understand the L in LGPL.
The problem is typically people not bothering to understand the L in LGPL.
> But those projects should have the budget for a real license, so that's not a real issue.
You're missing the whole point.
It's irrelevant whether projects should have a budget or not.
The whole point is that there are plenty of alternatives that do not require thousands of dollars per year*developer, nor do require lawyers to audit releases.
You're missing the whole point.
It's irrelevant whether projects should have a budget or not.
The whole point is that there are plenty of alternatives that do not require thousands of dollars per year*developer, nor do require lawyers to audit releases.
As others said, there aren't that many alternatives that work as well as Qt in a crossplatform way or in the embedded space.
On the desktop you can go Electron, but you then pay penalties in performance that not everyone is willing to endure.
In the embedded space there is little or no alternative.
On the desktop you can go Electron, but you then pay penalties in performance that not everyone is willing to endure.
In the embedded space there is little or no alternative.
There isn't so many alternatives that works so well in the embedded space. (in the kind of device where a web browser is not an option)
Now I'm curious what you think are the "plenty of alternatives" for embedded that are obviously a better choice.
[deleted]
Not if you also want decent performances
The anti-tivoization clause only applies to consumer devices. There is no issues with using the LGPL in a medical device since the customer is usually commercial.
If you have more documentation to back that up I'd love to see it. From my discussions with the walls of lawyers, the interpretation varies by jurisdiction.
The actual LGPLv3 text has zero instances of the word "commercial" or the word "consumer" so interpretation is all we can go by.
The actual LGPLv3 text has zero instances of the word "commercial" or the word "consumer" so interpretation is all we can go by.
Search again. The LGPLv3 is just referencing the GPL.
The GPLv3 paragraph 6 define in which conditions you need to provide the installation information, and explicitly say it is only for user product:
> A “User Product” is either (1) a “consumer product”, which means any tangible personal property which is normally used for personal, family, or household purposes, or (2) anything designed or sold for incorporation into a dwelling.
> A “User Product” is either (1) a “consumer product”, which means any tangible personal property which is normally used for personal, family, or household purposes, or (2) anything designed or sold for incorporation into a dwelling.
http://radar.oreilly.com/2007/03/gplv3-user-products-clause....
The FSF felt that consumers needed protected from tivoization but commercial users did not since they had the financial resources to fight for themselves with contract law.
The FSF felt that consumers needed protected from tivoization but commercial users did not since they had the financial resources to fight for themselves with contract law.
A commercial customer has the same right as everyone else using LGPL software.
They do not. http://radar.oreilly.com/2007/03/gplv3-user-products-clause....
The FSF felt that consumers needed protected from tivoization but commercial users did not since they had the financial resources to fight for themselves with contract law.
The FSF felt that consumers needed protected from tivoization but commercial users did not since they had the financial resources to fight for themselves with contract law.
[deleted]
> They work really hard to hide this, but they do have a LGPL license that applies to most of the framework (...)
No, LGPL also excludes projects from most commercial software.
Also, keep in mind that this is not a choice between Qt with a paid license or Qt with LGPL. It's a choice between Qt and any other framework, and licensing alone makes Qt a very poor choice.
No, LGPL also excludes projects from most commercial software.
Also, keep in mind that this is not a choice between Qt with a paid license or Qt with LGPL. It's a choice between Qt and any other framework, and licensing alone makes Qt a very poor choice.
Which frameworks though ? WxWidgets, GTK and Electron need compliance with LGPL, and I don't know any other that would be comparable in terms of features with Qt
Feature-wise, wxwidgets and gtk+ are a joke compared to Qt.
Electron is not just a joke but a fat pig.
Truth is there's nothing comparable to Qt in the cross plataform world today, unless you are willing to take the risk of Flutter, JUCE, some web technology (which would be regarded as obsolete by the time you ship your product), etc.
Electron is not just a joke but a fat pig.
Truth is there's nothing comparable to Qt in the cross plataform world today, unless you are willing to take the risk of Flutter, JUCE, some web technology (which would be regarded as obsolete by the time you ship your product), etc.
Sure, I agree haha. They are the closest but they aren't comparable (although likely for GTK+ one would mention the entire glib stack which is I think comparable to Qt in scope)
The whole glib would be just a subset of QtCore. Not comparable.
OP is talking embedded, so things like TouchGFX.
https://www.st.com/content/st_com/en/campaigns/touchgfx-adva...
https://www.st.com/content/st_com/en/campaigns/touchgfx-adva...
That's perhaps an advantage that Flutter has over Qt.
See: https://github.com/flutter/flutter/blob/master/LICENSE
See: https://github.com/flutter/flutter/blob/master/LICENSE
The API span of flutter is ridiculously small compared to Qt. Does it even have a proper tree view? I only see stuff comparable to Qt Quick there: https://gallery.flutter.dev/ ; nothing to make a complete desktop UI.
e.g. if I look at what I can find for docking widgets (and I have hardly ever seen an actual useful software for content creation without a whole set of dozens of docks): https://caduandrade.github.io/docking_flutter_demo/#/ like, is this a joke?
e.g. if I look at what I can find for docking widgets (and I have hardly ever seen an actual useful software for content creation without a whole set of dozens of docks): https://caduandrade.github.io/docking_flutter_demo/#/ like, is this a joke?
Yes, Qt is the best for certain types of desktop UIs and it has a proven-track of years. However, if you're a small business, what options do you have --realistically-- that come with friendly licensing and without having to shell out big bucks?
.. using the LGPL version ? it's used by small and large businesses alike and don't need you to shell out a cent nor to open-source your proprietary code.
Like, it was certainly a very shitty move given how much they make but if fucking Tesla managed to use the LGPL Qt in their car dashboard, surely your app can do it too
Like, it was certainly a very shitty move given how much they make but if fucking Tesla managed to use the LGPL Qt in their car dashboard, surely your app can do it too
Well, that's a good point.
I see it diferently, when I want to enjoy the work of Qt devs as free beer, my work is also free beer.
When I want to get paid for stuff I develop with the work of Qt devs, then like in other profession, I pay the creators of tools I get money to put bread on the table.
They also need to buy bread, so it is only fair we share the same conditions.
When I want to get paid for stuff I develop with the work of Qt devs, then like in other profession, I pay the creators of tools I get money to put bread on the table.
They also need to buy bread, so it is only fair we share the same conditions.
Yes, but sharing the cost with lots of other developers would them enable to bring the price down.
For me, it seems like Jetbrains vs. Borland/Inprise/Codegear/Embarcadero. Jetbrains always had reasonable prices, but a huge amount of customers. Embarcadero tries to milk the few customers that remain.
Qt is like Embarcadero.
For me, it seems like Jetbrains vs. Borland/Inprise/Codegear/Embarcadero. Jetbrains always had reasonable prices, but a huge amount of customers. Embarcadero tries to milk the few customers that remain.
Qt is like Embarcadero.
Embarcadero Delphi and C++ Builder are used for legacy stuff, it's maintenance mode and Idera (owners of Embarcadero) are following the same model as Broadcom, Microfocus and others: milk enterprise customers because they are too invested and they are not going to rewrite those applications. I don't think anyone has started any meaningful project in Delphi or C++ for at least 10-15 years.
Qt on the other hand is used a lot and new projects are started with Qt everyday. Qt is not Embarcadero.
Qt on the other hand is used a lot and new projects are started with Qt everyday. Qt is not Embarcadero.
They are still quite strong on the German, market and Microsoft is still clueless in making anything that can beat C++ Builder, the best they could do was C++/CX and internal politics killed without any regards for the customers using it.
C++/WinRT is a joy to use for anyone whose maximum of productivity was using Visual C++ 6.0 for COM development, exactly the same Visual Studio tooling. /s
So plenty of enterprises do new projects in C++ Builder, and Delphi comes for the ride.
https://entwickler-konferenz.de/
I know of a company in Belgium that does laboratory automation software in Delphi, because they don't want to use languages like C and C++, and .NET lacked the low level coding and native compilation that they want.
For them it isn't legacy, rather from their point of view the alternatives suck, and they will keep at it as long as they can.
C++/WinRT is a joy to use for anyone whose maximum of productivity was using Visual C++ 6.0 for COM development, exactly the same Visual Studio tooling. /s
So plenty of enterprises do new projects in C++ Builder, and Delphi comes for the ride.
https://entwickler-konferenz.de/
I know of a company in Belgium that does laboratory automation software in Delphi, because they don't want to use languages like C and C++, and .NET lacked the low level coding and native compilation that they want.
For them it isn't legacy, rather from their point of view the alternatives suck, and they will keep at it as long as they can.
*C++Builder, not C++ in general
That is the usual speech, yet when they offered cheaper packages about 10 years ago, everyone wanted free beer, hence why they turned into those that actually pay.
When everyone wants free beer, in the end they get Electron.
When everyone wants free beer, in the end they get Electron.
> When everyone wants free beer, in the end they get Electron.
Which uses webkit, which is LGPL :D
It seems all the people here who complain about QT's license never bothered to read the license of anything else.
Which uses webkit, which is LGPL :D
It seems all the people here who complain about QT's license never bothered to read the license of anything else.
Well, it's their business, so fair enough.
But that means that lots of projects can't and won't even look into using Qt.
> it's licensing automatically takes it out of the table of most of all potential projects.
maybe consider licensing that "potential project" under a license that allows you to use the OpenSource Qt version?
maybe consider licensing that "potential project" under a license that allows you to use the OpenSource Qt version?
Seriously! That licensing is a feature for the public, not a bug. Make your project open source.
> Seriously! That licensing is a feature for the public, not a bug. Make your project open source.
It's ok for activists to feel that free software is the solution to every problem in the world, but back in the real world there are projects for which open source is not an option and parroting activist mantras is not helpful.
It's ok for activists to feel that free software is the solution to every problem in the world, but back in the real world there are projects for which open source is not an option and parroting activist mantras is not helpful.
So in the real world, you don't get to have that nice gui library for free if you aren't willing to reciprocate and offer your own source for free as well. How terrible.
What you're describing is obligations under GPL'd code, not LGPL'd code. Qt is mostly LGPL'd code.
So why expect the library for free then? Saying open source is not an option but not being willing to pay for the licencing cost of the "commercial" Version is quite hypocritical no?
Not at all hypocritical. The people who authored the code release most of it under LGPL, the intention of which is to allow closed-source dynamic linking against the LGPL'd library. I didn't decide this. The users didn't decide this. The people who actually wrote the code decided this.
But people still complain that using it for free is too restrictive and want static linking and freedom to modify the sources and not share the changes, all for free.
Or... comply with the LGPL with regard to dynamic linking and the other LGPL requirements and don't use any GPL'd components.
You can use almost all of QT even in close source, provided you only link dynamically.
I'm pretty sure you could even link statically, as long as you provide the necessary .a / .o files to rebuild against a different version of the LGPL library. But of course dynamic linking is the safer approach.
I believe you are correct.
You'd have to provide a way to relink.
I seriously can't see a judge ever being able or willing to understand what's at stake here in case this ever gets to court.
You'd have to provide a way to relink.
I seriously can't see a judge ever being able or willing to understand what's at stake here in case this ever gets to court.
Woof, those prices are so enterprise.
It is also very in your face.
Went to go install the SDK on windows - have to create an account, click a ton of stuff in the installer to convince it that it's okay to give me the free version, etc
It then proceeds to install 20+ gigabytes (yes) of stuff, including their ide that you can't actually uncheck.
No thanks, i'm out.
It then proceeds to install 20+ gigabytes (yes) of stuff, including their ide that you can't actually uncheck.
No thanks, i'm out.
The ide is actually decent. Or was in the Qt 4 days. The rest... as the OP in this thread says, the only thing we're using Qt for is something something automotive (and paid).
We don't bother going near the LGPL version for small things. Too many threats.
We don't bother going near the LGPL version for small things. Too many threats.
QTCreator is one of the best C++ IDEs for Linux. I'd imagine Visual Studio is better but I haven't developed on Windows in years.
I mean, i understand it, and i'm sure it's great for their ecosystem.
I'm sure it integrates well with UI designers, etc.
But i'm also really not that interested in using a library specific IDE at that level.
Because QT is not all i do, etc.
For folks who do, i'm sure it's great.
For C++ IDEs on linux, CLion works great. VSCode is reasonable too.
But i'm also really not that interested in using a library specific IDE at that level.
Because QT is not all i do, etc.
For folks who do, i'm sure it's great.
For C++ IDEs on linux, CLion works great. VSCode is reasonable too.
QtCreator works with non-Qt, CMake based projects, has a feature set which is very competitive with CLion's and it's about a billion times faster.
I get that, but that's also clearly not the market they are targeting or customers they want, etc :)
Otherwise, Clion would be dead by now in favor of it!
Otherwise, Clion would be dead by now in favor of it!
Nobody is forcing you to use their IDE. Just use VSCode.
Also, for your complaint about the size of the SDK: most people download the Python bindings (often through conda) and don't do compilation at all (I write interactive applications using QtPy, python slowness isn't an issue). But also: you're not the target audience.
Also, for your complaint about the size of the SDK: most people download the Python bindings (often through conda) and don't do compilation at all (I write interactive applications using QtPy, python slowness isn't an issue). But also: you're not the target audience.
I use Qt Creator for all my C++ projects and I am not doing any Qt work.
I use it to build non-QT code with cmake.
That is besides the point parent poster is making though. are they also making it so that you cannot use the GPL software w/o the IDE? if so that would be a violation of GPL.
He's just complaining about the installer of the pre built binaries that asks for an account.
You can download sources and build them yourself. Which is what linux distributions do.
You can download sources and build them yourself. Which is what linux distributions do.
I'm complaining that they make it hard for people to want to try it by making it huge and unwieldy :)
(QT is more than linux-only. In fact, that's the whole point. They could simplify it greatly if it was linux-only.)
(QT is more than linux-only. In fact, that's the whole point. They could simplify it greatly if it was linux-only.)
CLion is way better for C++ on Linux, IMO.
I think you can get by with 5gb or so if you're only building for one platform. But if you select Android, iOS, sources, etc it can get big
you can install it from vcpkg or conan (or https://github.com/miurahr/aqtinstall if you really want the official Qt binaries) and it'll be much less
You give up too easily. Do you know you can download the sources via git? You can even pick and choose which Qt modules you want. No account needed.
I don't give up easily at all most of the time, but i also am careful how i spend my time.
So yes, i know you can download sources, and many years ago, i even built them once!
Does it occur to you this is maybe not what i want out of a developer experience? That if this is the experience the company wants to provide me, that that is a good sign i am not who they want or target? (Or that they suck at business, which is possible)
First impressions matter a lot.
I can surely make it all work, but why would I? There are plenty of great alternatives where i don't have to any time trying to make it work, and where the company is not making it annoying for me.
So i just go use those.
So yes, i know you can download sources, and many years ago, i even built them once!
Does it occur to you this is maybe not what i want out of a developer experience? That if this is the experience the company wants to provide me, that that is a good sign i am not who they want or target? (Or that they suck at business, which is possible)
First impressions matter a lot.
I can surely make it all work, but why would I? There are plenty of great alternatives where i don't have to any time trying to make it work, and where the company is not making it annoying for me.
So i just go use those.
The inconvenience of software licensing and license management and the potential legal issues that incorporating third party licensed software can create for a project are a much bigger impediment to the use of commercial developer tools and libraries than the cost.
If the cost is reasonable for what you're getting, most companies wouldn't think twice about paying for a library or a dev tool if it'll help them ship faster or better products... and if they didn't have to think about it much anymore after that decision. You can see this by the willingness of companies to shell out for SaaS tools like GitHub paid accounts and commercial CI/CD services. There isn't really much lock-in there. If you need to abandon GitHub you can move to GitLab or stand up your own instance of something like Gitea. Might lose some meta-data but your main code (product) is intact.
Instead the nature of licensing means that the license of the library you're incorporating contaminates your project and you have to get legal involved. Even having to contact legal is generally the kiss of death.
It also raises questions about whether the vendor can rug pull you in the future and kill your product. To be fair this can sort of happen in open source if you rely on a complex project that gets abandoned and don't have the resources to adopt it, but at least there you have some recourse and you can keep using what already exists until you have a long term solution.
This complexity is really why we can't have nice things, since things as powerful as Qt really do require funding in one form or another.
If the cost is reasonable for what you're getting, most companies wouldn't think twice about paying for a library or a dev tool if it'll help them ship faster or better products... and if they didn't have to think about it much anymore after that decision. You can see this by the willingness of companies to shell out for SaaS tools like GitHub paid accounts and commercial CI/CD services. There isn't really much lock-in there. If you need to abandon GitHub you can move to GitLab or stand up your own instance of something like Gitea. Might lose some meta-data but your main code (product) is intact.
Instead the nature of licensing means that the license of the library you're incorporating contaminates your project and you have to get legal involved. Even having to contact legal is generally the kiss of death.
It also raises questions about whether the vendor can rug pull you in the future and kill your product. To be fair this can sort of happen in open source if you rely on a complex project that gets abandoned and don't have the resources to adopt it, but at least there you have some recourse and you can keep using what already exists until you have a long term solution.
This complexity is really why we can't have nice things, since things as powerful as Qt really do require funding in one form or another.
Maybe Slint could be an option? From former Qt developers.
https://slint-ui.com/
https://slint-ui.com/
There's no pricing indication other than "contact our sales", which is a common wording for "just as expensive (or even more) as the competition". Also their licence and subscription (yuck) model seems awful. Pay a monthly fee per device as long as I sell my product? No thanks. I got laughed at for presenting QT as a possible solution. This will just make me look like a tryhard clown.
>There's no pricing indication other than "contact our sales", which is a common wording for "just as expensive (or even more) as the competition"
Or the one-two punch of "Contact our sales", followed immedietely by "What is your budget?" ... which is a common wording for "How much money do you have? That is what this will cost!"
Or the one-two punch of "Contact our sales", followed immedietely by "What is your budget?" ... which is a common wording for "How much money do you have? That is what this will cost!"
They are almost certainly not as rigid about pricing and conditions as the Qt Company. Source: I know these guys.
Perhaps they could provide some reasonable (production!) public pricing plans and allow custom quotes for folks who want to negotiate the price further then.
Doesn't yet have a table or tree control - would only work for very basic UIs in this limited state. Also, GPL and all that entails (with rare exception that you can petition for a free license if a very small entity or open source).
Has anyone tried slint? How does it compare to Qt v5 or v6?
When I was a developer and engineering manager, we used Qt for many desktop and embedded (not microcontroller) applications for many years. It was a bit cheaper than today (~3K EUR/seat) but it paid by itself due to the increased productivity. It was a no brainer.
With mobile platforms, I can imagine the same is true: you can save a ton of development time money.
With mobile platforms, I can imagine the same is true: you can save a ton of development time money.
Perhaps you could choose this license? https://www.qt.io/pricing/qt-for-small-business
Yes, the Qt licensing model is the reason we have not touched it. Not interested in the ramifications it creates. For example, imaging you are selling your company and, during due diligence, the buyer discovers you have to release your source code. Yeah. Talk about having a bad day.
In addition to this, I have exactly zero interest in any licensing model that requires a per-device fee. First of all, the fee, at least last time I looked, is completely opaque. My guess is they try to squeeze you for all they can. Second, and often more important, I have zero interest in Qt having an internal view of our business --which is what they get when you have to account for how many devices you made, sold and when.
I don't mind the per-developer or site licenses. Per-device licenses are intrusive. They also get to tap into your profit margin. No, thanks.
We have subscriptions with JetBrains for their excellent tools. If JetBrains turned around and said "You have to pay a fee for every unit sold", we would drop them like a hot potato. Everyone understands that example, yet somehow people don't recoil at this idea of per-device licensing. Hardware is hard enough as it is; adding a blood-sucking vampire to the equation doesn't make it easier.
Think about it. Is the work Qt does more complex than what JetBrains do? Not at all. I can actually see JB's work being massively more difficult, particularly when you consider the array of tools they have to evolve and maintain. Why is it that Qt think they are entitled to poke a needle into your arm and suck blood out of every device you make?
Even better, the open source license demands contribution of any enhancements back to Qt. They, in turn, take those advances and sell them through their commercial licensing program. Do the contributors get a piece of the action? Why not?
Also, I believe that, until recently, if you stopped paying your developer licenses you were prohibited from selling your product. In other words, if I created a product using Qt five years ago and never touched it again, I'd have to pay them a developer's license for the life of the product. Once again, blood-sucking vampire behavior. That said, I believe I read something about this policy changing. Since I have not found a way to care about Qt, I didn't bother to read that article in detail.
Another analogy: It's like what's going on with modern "smart" TV's. You go buy a TV and the manufacturers somehow feel entitled to harass you with advertising and all sorts of data gathering. Intrusive and wrong.
How could Qt change my mind?
I don't have a problem paying a reasonable per-developer annual license fee. What's reasonable? A few hundred dollars, say, $300 or so. After that, no per-device fees, get your microscope out of my ass and the license isn't tied to released products in any imaginable manner.
I very much doubt this will happen.
In addition to this, I have exactly zero interest in any licensing model that requires a per-device fee. First of all, the fee, at least last time I looked, is completely opaque. My guess is they try to squeeze you for all they can. Second, and often more important, I have zero interest in Qt having an internal view of our business --which is what they get when you have to account for how many devices you made, sold and when.
I don't mind the per-developer or site licenses. Per-device licenses are intrusive. They also get to tap into your profit margin. No, thanks.
We have subscriptions with JetBrains for their excellent tools. If JetBrains turned around and said "You have to pay a fee for every unit sold", we would drop them like a hot potato. Everyone understands that example, yet somehow people don't recoil at this idea of per-device licensing. Hardware is hard enough as it is; adding a blood-sucking vampire to the equation doesn't make it easier.
Think about it. Is the work Qt does more complex than what JetBrains do? Not at all. I can actually see JB's work being massively more difficult, particularly when you consider the array of tools they have to evolve and maintain. Why is it that Qt think they are entitled to poke a needle into your arm and suck blood out of every device you make?
Even better, the open source license demands contribution of any enhancements back to Qt. They, in turn, take those advances and sell them through their commercial licensing program. Do the contributors get a piece of the action? Why not?
Also, I believe that, until recently, if you stopped paying your developer licenses you were prohibited from selling your product. In other words, if I created a product using Qt five years ago and never touched it again, I'd have to pay them a developer's license for the life of the product. Once again, blood-sucking vampire behavior. That said, I believe I read something about this policy changing. Since I have not found a way to care about Qt, I didn't bother to read that article in detail.
Another analogy: It's like what's going on with modern "smart" TV's. You go buy a TV and the manufacturers somehow feel entitled to harass you with advertising and all sorts of data gathering. Intrusive and wrong.
How could Qt change my mind?
I don't have a problem paying a reasonable per-developer annual license fee. What's reasonable? A few hundred dollars, say, $300 or so. After that, no per-device fees, get your microscope out of my ass and the license isn't tied to released products in any imaginable manner.
I very much doubt this will happen.
It seems like Qt is trying to walk that 'license tightrope' that many tool makers do...how do you make your product affordable for small developers without making it possible for big businesses to pay you a pittance for helping them reap $millions or even $billions in product sales.
I would love to pay Qt a reasonable license fee once my product that uses it starts generating some decent revenues. I want them to succeed and keep building better versions. But I also don't want to have to shell out outrageous license fees when I am just getting started. This goes for any tool or library I choose to use.
I would love to pay Qt a reasonable license fee once my product that uses it starts generating some decent revenues. I want them to succeed and keep building better versions. But I also don't want to have to shell out outrageous license fees when I am just getting started. This goes for any tool or library I choose to use.
Do you know about Qt for Small Business? https://www.qt.io/pricing/qt-for-small-business
> Do you know about Qt for Small Business?
From the page:
"Your business has a combined revenue and funding equal to or less than two-hundred and fifty thousand ($250000) USD"
(revenue + funding) < 250000 ?
That's not a business, that's a hobby.
From the page:
"Your business has a combined revenue and funding equal to or less than two-hundred and fifty thousand ($250000) USD"
(revenue + funding) < 250000 ?
That's not a business, that's a hobby.
If going by the wages Qt pays its own developers, which is competitive in Germany, that "hobby" as you call it would be able to finance 2-3 fulltime devs. That's a small business.
> For example, imaging you are selling your company and, during due diligence, the buyer discovers you have to release your source code.
You have to do that process if you use electron… except that there you have 30000 libraries and each one of them has to be vetted and approved.
Your legal costs estimations is way off.
You have to do that process if you use electron… except that there you have 30000 libraries and each one of them has to be vetted and approved.
Your legal costs estimations is way off.
Qmetaobject-rs crate makes it very easy to write qt with rust.
I've said it before and i will say it again. A good gyi toolkit and that too cross platform is an incredible amount of work. Rust would be better off funding qt support than trying 20 different things because somehow anything less than "pure" rust is filthy.
I've said it before and i will say it again. A good gyi toolkit and that too cross platform is an incredible amount of work. Rust would be better off funding qt support than trying 20 different things because somehow anything less than "pure" rust is filthy.
“Rust” isn’t trying 20 different things. Various independent teams and developers are working on their own projects for various reasons.
I love Qt, technology-wise.
But the business model... Distribution Licenses? Come on!
Is there a tutorial of how to make a desktop GUI app using only QML/Quick/whatever, without C++ or Python? I want to build a desktop app and will gladly offload the work logic to a separate app to be invoked in background via CLI.
https://news.ycombinator.com/item?id=33021550
Rust works fine but with qml technically there is very little programming code except the in app js-logic
Rust works fine but with qml technically there is very little programming code except the in app js-logic
Why do you want to build a desktop app with the mobile framework rather than the desktop one?
I’m not saying it’s necessarily a bad idea, Apple enables the same nowadays with Catalyst (iOS APIs on macOS). But it doesn’t seem very popular. Just curious why you want to go this way.
I’m not saying it’s necessarily a bad idea, Apple enables the same nowadays with Catalyst (iOS APIs on macOS). But it doesn’t seem very popular. Just curious why you want to go this way.
1. I consider Qt (incl. the "modern" part) a desktop framework (arguably the best one) with mobile support (perhaps very good support), not a mobile framework. Or would you say KDE is "for some reason made with a mobile framework rather than a desktop one"?
2. I am a solo developer and want one framework to write once, run everywhere (still looking for which will do the best job for me).
2. I am a solo developer and want one framework to write once, run everywhere (still looking for which will do the best job for me).
> I am a solo developer and want one framework to write once, run everywhere
So... Qt's C++ framework then?
Late edit: as an afterthought there are other languages that provide similar functionality. Xojo comes to mind as having capability to write once and run everywhere. It doesn't have the performance of C++ though and comes with a bunch of its own baggage.
So... Qt's C++ framework then?
Late edit: as an afterthought there are other languages that provide similar functionality. Xojo comes to mind as having capability to write once and run everywhere. It doesn't have the performance of C++ though and comes with a bunch of its own baggage.
I just heard you don't really have to use any language other than the Qt's internal ones any more.
Although performance is nice to have, it obviously is not the most important thing for me. Low verbosity (as little code necessary to write a functional and reliable UI as possible) and fast learning curve are the most important things.
Although performance is nice to have, it obviously is not the most important thing for me. Low verbosity (as little code necessary to write a functional and reliable UI as possible) and fast learning curve are the most important things.
> Low verbosity (as little code necessary to write a functional and reliable UI as possible) and fast learning curve are the most important things.
Qt and Xojo are both real contenders on these points. I would argue that Xojo has a faster learning curve if you already know BASIC but is perhaps much less expressive if you need any sort of complex computer science algorithms or data structures which is where C++ really shines.
Qt's learning curve is "pretty quick" but it of course comes with having to know a decent amount of C++, and possibly javascript, to utilize effectively.
> I just heard you don't really have to use any language other than the Qt's internal ones any more.
Yup absolutely. If it were me and I were building a UI, I would seriously consider Qt's framework. I don't particularly like Qt's framekwork (it still holds a lot of baggage from pre-C++11 days) but I must admit that it's fairly extensive, certainly cross-platform across desktop and mobile operating systems, and has a fairly quick learning curve to use.
Qt and Xojo are both real contenders on these points. I would argue that Xojo has a faster learning curve if you already know BASIC but is perhaps much less expressive if you need any sort of complex computer science algorithms or data structures which is where C++ really shines.
Qt's learning curve is "pretty quick" but it of course comes with having to know a decent amount of C++, and possibly javascript, to utilize effectively.
> I just heard you don't really have to use any language other than the Qt's internal ones any more.
Yup absolutely. If it were me and I were building a UI, I would seriously consider Qt's framework. I don't particularly like Qt's framekwork (it still holds a lot of baggage from pre-C++11 days) but I must admit that it's fairly extensive, certainly cross-platform across desktop and mobile operating systems, and has a fairly quick learning curve to use.
AFAIK, QML is now their full strategy for desktop and mobile. QtWidgets is still supported but is considered somewhat legacy I believe. New projects are typically encouraged to use QML I think.
[deleted]
Can you provide a source for this?
Pretty much all the material they've pushed for, uhm, almost 15 years...?
Widgets are still supported (because they work, and they are used by lots of faithful Qt customers), but QML is where they've put pretty much all their development focus since the late 2000s.
Widgets are still supported (because they work, and they are used by lots of faithful Qt customers), but QML is where they've put pretty much all their development focus since the late 2000s.
I apologize for the confusion. I was addressing the remark,
New projects are typically encouraged to use QML I think
I wasn't wondering where they were putting their development time.
New projects are typically encouraged to use QML I think
I wasn't wondering where they were putting their development time.
I think the point is "by whom" ? Does Qt say that somewhere? I haven't seen it. They certainly push QML, but they certainly are still activatly maintaining and improving their "old fashioned" widgets as well.
You are wrong about development focus. qtbase/qtwidgets are still very much being developed.
Not sure there is anything official, but I just uncovered this sentiment in my research after scouring tons of chat forums, etc. while researching GUI toolkits. There seems to be an understanding that QtWidgets is in "maintenance mode" and I'm told hasn't seen any new features in a while. I've also noticed many existing projects discussing migrating to QML (many don't, however, due to the amount of work).
Did you even read the article? They literally just announced new features for Widgets, in the section titled "Useful new features in Qt Widgets".
Qt in the browser sounds cool.. but feels reminiscent of shockwave..
While some people were too busy cheering the death of plugins, they were being bought back to life thanks to the rejuvenating powers of WebAssembly and WebGL.
All of them already have some kind of support in WebAssembly.
All of them already have some kind of support in WebAssembly.
Still, overall better than the situation of having to install a plugin that may or may not be available or working fully on your system. Plus security concerns of running sometimes obscure binaries on your system to access web content.
You can compile heartbleed to WebAssembly, and there are ways to exploit memory corruption to change observable behaviour.
I'm aware it's not impossible to exploit the current plug-in free browsers we have now. It's still objectively better than before.
Not that I'm satisfied with the current state of browsers mind you. I just think not being forced to install someone's binary blob to look at web content is a net benefit.
Not that I'm satisfied with the current state of browsers mind you. I just think not being forced to install someone's binary blob to look at web content is a net benefit.
Except you can't disable WebAssembly, and you can't control how a SPA is implemented, see Figma for example.
Now you can enjoy Flash like ads using WebAssembly + WebGL, making it all a Phyrric victory.
Now you can enjoy Flash like ads using WebAssembly + WebGL, making it all a Phyrric victory.
WebAssembly can absolutely be disabled:
Chromium-based: --js-flags=--noexpose_wasm
Firefox-based: about:config javascript.options.wasm = false
Chromium-based: --js-flags=--noexpose_wasm
Firefox-based: about:config javascript.options.wasm = false
Great now explain that to granny on her phone.
Seems like you're moving the goalposts...
Webassembly is clearly an improvement over the old plugins. For one thing it's a full virtual machine and was designed with sandboxing in mind.
Webassembly is clearly an improvement over the old plugins. For one thing it's a full virtual machine and was designed with sandboxing in mind.
Not at all, I say it can be disabled and stand by it.
Those browser flags aren't something Joe and Jane users are capable to be aware of, can disappear at any time anyway, and are not a thing on mobile devices.
A sandboxing that isn't bullet proof and can still be exploited by triggering memory corruption on the linear memory segment, thus changing decisions based on the data contents.
Those browser flags aren't something Joe and Jane users are capable to be aware of, can disappear at any time anyway, and are not a thing on mobile devices.
A sandboxing that isn't bullet proof and can still be exploited by triggering memory corruption on the linear memory segment, thus changing decisions based on the data contents.
Joe and Jane also don't know or care what WebAssembly is.
It's inevitable.
The only way for Qt to compete with Electron is to become Electron.
The only way for Qt to compete with Electron is to become Electron.
That feels like to opposite, though. Electron brought the browser to offline/"native" apps. It literally packaged webkit in a way for web tech to be used as a desktop app, whilst Qt in the browser (and Shockwave, Java Applets, ActiveX et al) were bringing the desktop to the browser.
Electron brings non-native content to the desktop. Qt in the browser brings non-native content to the web.
Now we can have broken accessibility, usability, broken theming, and bad integration on both platforms, yay!
Now we can have broken accessibility, usability, broken theming, and bad integration on both platforms, yay!
Yeah I don't think anyone would really choose to write a new web app with Qt. I assume the target market is people that want to port their existing Qt code to the web. It could also be useful for demoing Qt apps.
Yep, I do it with https://ossia.io (https://ossia.io/score-web) to make the occasional demo ; it's pretty alpha and drag'n'drop still seems to kill it but every Qt release has made it better without me having to do anything.. looking forward to updating!
How do you do it? I didn't know qt web was a thing? I remember I heard about one project but that was gpl i think
At one point Nokia pushed the idea that you would write Qt apps to run on their cloud; they had a few actual customers doing it too. I don't know if the current owners kept going with the concept.
It makes sense, from the perspective of shops who invested heavily in upskilling on Qt, to reuse the knowledge to build web apps.
It makes sense, from the perspective of shops who invested heavily in upskilling on Qt, to reuse the knowledge to build web apps.
ossia score is GPLv3 itself
regarding the how.. Qt provides a CMake wrapper which sets up the relevant flags automatically so with CMake/Qt projects it pretty much just works. Here's my build scripts:
- https://github.com/ossia/score/blob/master/ci/wasm.deps.sh
- https://github.com/ossia/score/blob/master/ci/wasm.build.sh
regarding the how.. Qt provides a CMake wrapper which sets up the relevant flags automatically so with CMake/Qt projects it pretty much just works. Here's my build scripts:
- https://github.com/ossia/score/blob/master/ci/wasm.deps.sh
- https://github.com/ossia/score/blob/master/ci/wasm.build.sh
drag and drop requires configuring your app with asyncify option. https://doc-snapshots.qt.io/qt6-6.4/wasm.html#asyncify
I think this is how I do it (https://github.com/ossia/score/blob/master/ci/wasm.build.sh) but it still stops working after some time
Don't underestimate people's reluctance to learn new stacks.
I think the better use case for having Qt in the browser is if a web app could benefit from sharing code with a mobile or desktop Qt project. Other than that, yeah, I'm not sure why anyone would use Qt for web apps besides preference.
Easier testing and deployment. Develop and test one platform. Deployment is a url.
How viable is LGPL'd Qt, in its current situation, for closed-source desktop applications?
Super viable. I'm aware of several companies using the LGPL license for their closed source desktop applications, including my own. Don't let the other replies scare you. No one will call and threaten you and you don't need a lawyer. For cross platform native desktop applications, Qt is far and away the best option. QtCreator is pretty awesome too.
You will be missing a few modules/plugins/tools which are commercial-only (I cannot seem to find the actual list right now though) but other than that, the LGPL was made exactly for that reason to allow linking an open-source library (Qt) into a closed-source program.
As long as you don't modify the Qt source (or you modify and re-distribute it per LGPL) you should be safe (IANAL obviously)
As long as you don't modify the Qt source (or you modify and re-distribute it per LGPL) you should be safe (IANAL obviously)
As long as you dynamically link and don't use the non-free components (charts, etc.), I think it would be just fine for a C++ or Python app. However, personally, I am leaning towards Flutter atm. They have decent emulated native looking controls for Windows/Mac, seems to have a strong cross platform focus, strong Rust integration via a bridge library, and has a better license with good free charting options.
See https://doc.qt.io/qt-6/qtmodules.html#gpl-licensed-addons for the few GPL/commercial only modules
Very. That's almost the point of LGPL.
I have a project I built using Qt version 5. It seems to work pretty well. I didn't upgrade to version 6 because it was initially missing some modules I was using, but it sounds like they have now ported those to their version 6 code. When I get some cycles, I will have to look into upgrading.
Check out qt5compat module :)
The LGPL license allows you to make closed applications without problems if you comply with the rules. But the Qt guys will call you and make threats (very nicely). Real case.
Can you afford a lawyer on retainer?
What? It's doesn't take a genius to understand it. They clearly label what is and what is not LGPL. It doesn't hurt to double check the source files of course and have redundant confirmation. You don't need a lawyer for everything in life.
I don't need a lawyer to use a LGPL lib. Considering how many threats you have to go through to get the LGPL version, I need one because Digia is likely to disagree with my interpretation.
Please refer us to court cases where they went after people and made false claims. Until then I think I'll keep Qt in my belt of tools.
Just so you know, webkit is LGPL, because it got forked from KDE (KHTML).
I tried some Qt WASM demos here: https://www.qt.io/qt-examples-for-webassembly
Nice idea but the problem is that these literally run as a foreign app in the browser. You can't cut and paste or highlight text. They are not web pages.
There is a niche for this, probably in business and industrial uses or for making legacy apps available over the web, but it's not something I'd consider for a new system that had to in any way be "web-like" or that was primarily used over the web.
Nice idea but the problem is that these literally run as a foreign app in the browser. You can't cut and paste or highlight text. They are not web pages.
There is a niche for this, probably in business and industrial uses or for making legacy apps available over the web, but it's not something I'd consider for a new system that had to in any way be "web-like" or that was primarily used over the web.
And still no accessibility as far as I can tell. It's kind of amusing and kind of sad that one of the demos on that page is "Pizza Shop", given that there was a recent infamous accessibility lawsuit against Dominos Pizza.
Actually you should be able to cut/paste. Highlighting text also works.
https://lpotter.github.io/textedit/textedit.html
Hmmm maybe it has to be enabled programmatically.