17 ms·

Current issues with the Qt project from the outside looking in

113 points by Kelteseth 3y ago

detaro 3y ago
Strongly disagree with the "Qt 'tools' should use QML more". QML and Widgets are strong at different things, the tools are relatively clear cases of the things that Widgets are better at. There is no point in shoehorning QML into them just so they use QML, which is optimized for different things.
- rat9988 3y ago
  What are QML and QWdiget better at then?
  - account42 3y ago
    QML is a good fit for fullscreen touch interfaces or video displays. Also simple game - complex ones are probably better off not using Qt at all. QWidget is the "old" desktop UI toolkit that is good for desktop UIs.
    - rubymamis 3y ago
      Qt Quick is catching up with QWidgets. While still some way to go, I agree with the OP that it will align incentives for them to improve edge cases of features that exist in QWidgets but lacking in Qt Quick.
  - bluGill 3y ago
    QWidgets look and act like a desktop application. QML looks and acts like a touch screen application. The two use cases are very different. A touch screen application doesn't work well on a keyboard/mouse environment. A keyboard/mouse application doesn't work well on a touch screen.
  - EntrePrescott 3y ago
    The Widgets are easier to work with for pure desktop apps… but they are limited to that purpose. Qt Quick and QML are better for pretty much any application use case that isn't the classic desktop. Especially any form of app for mobile or embedded devices.
    - Kelteseth 3y ago
      Author here. Please show me an example for your claim.
samsquire 3y ago
Creating a multiplatform native framework for creating native looking GUIs is extremely difficult and a challenging piece of work. Add the complexity of C++ and I'm not surprised that things are as complicated as they are. I once looked at what needs to be implemented to implement a text control interface in Mac OS and it was an API with hundreds of methods. GUI frontend development IS complicated. There's so many edge cases with text rendering, editing logic, layout, state, native compatibility. I started writing the beginnings of a flowing rendering engine using WxWidgets in Python using an algorithm from the ORC Solver whitepaper. IntelliJ Idea, Netbeans are intricate advanced frontends and they are both written in Java. How would a user interface written in a functional language look? I used to use Xmonad as a window manager which was very powerful and easy to use but it is written in Haskell. I think any frontend technology that wins needs to be simple and easy to comprehend. I have yet to use Flutter. I did have a frontend in Electron but my code was awful. I would rather create user interfaces with a simple language and use a fast language for the data crunching. I think Python and Java count.
- brabel 3y ago
  > How would a user interface written in a functional language look? Maybe you're not aware of Elm? https://elm-lang.org https://elm-lang.org Elm is really functional, unlike the likes of React that are just partially, kind of functional. There's an attempt at bringing Elm to the desktop, the Roc language... here's an UI example written in Roc: https://github.com/roc-lang/roc/blob/main/examples/gui/hello.roc https://github.com/roc-lang/roc/blob/main/examples/gui/hello...
  - GiorgioG 3y ago
    Maybe most people aren’t aware of Elm. Despite its good ideas it’s a niche language that should be avoided for real work because it has a bus factor of 1.
  - DarkNova6 3y ago
    Unfortunately, it seems the developers behind elm do everything in their power so elm can never become mainstream
raverbashing 3y ago
> I have already said it many times online. The way Qt wants to make money is too much focused in big B2B style. There is a general sentiment in the community that the current pricing is bad for small businesses. It feels like giving into a trap when using Qt for small business. This. And might I say, a lot of IT companies in Europe are awful at pricing. They're aiming for the B2B market and forget all the others Well guess what, people are just embedding browsers now and except for niche apps, few people care about Qt
- korijn 3y ago
  > Well guess what, people are just embedding browsers now Which is incredibly selfish and hypocritical, it drives up resource consumption across the world at a massive scale. Not just in terms of energy use, but it also forces people to buy more powerful machines, intensifying electronic waste problems. Great job guys!
  - raverbashing 3y ago
    This was a problem 15 yrs ago. Today it isn't. The cheapest stuff that can run Qt is the same one that runs a basic Android install
    - account42 3y ago
      It's still a problem today even if you have trained yourself to not notice it.
    - rychco 3y ago
      Modern software embedding an entire web browser is absolutely & undeniably a problem.
      - qtzfz 3y ago
        I hear this argument often, but I haven't heard a convincing argument. Why? Lack of storage? No. Lack of computing power or RAM? No. Then?
zerr 3y ago
They have allienated C++ devs by imposing on them the abomination that is QML. The first thing they should do is to provide a public API for using QtQuick solely in C++.
- bombolo 3y ago
  I think their plan was to attract js developers, letting the C++ code to be hidden behind a curtain and the UI stuff to be written in js. But since to run it still needs a main() to call the QML part, probably js developers stay as far away from it as possible.
- rleigh 3y ago
  This is exactly the reason I've avoided QML. Give me a 100% C++ API and I will reconsider.
  - rubymamis 3y ago
    Give it a shot, I learned all the basics in a day. The next day I had a working prototype for a new feature. See: https://github.com/nuttyartist/notes/pull/574 https://github.com/nuttyartist/notes/pull/574
- jeroenhd 3y ago
  As an outsider, I have to ask: what's wrong with QML? Was there a better, earlier layout language before QML that I don't know about?
  - toyg 3y ago
    The problem with QML is that it's not C++. Most Qt developers are C/C++/Python folks, being forced to use JS is not their idea of fun. Also, for some time the prebuilt QML widgets didn't have feature parity with the old QtWidgets. I think they're now there, but it's still a different philosophy: QtWidgets tried hard to fit in the desktop paradigm (with tray icons, desktop services, etc), whereas QML simply doesn't care - QML more or less expect to simply take over the screen and do everything on their own, web-style. Again it's a culture clash with traditional QT that QML creators seem to have fundamentally underestimated.
gumballindie 3y ago
QML is by far the most horrible thing about qt.
- jenadine 3y ago
  What's wrong with QML?
st_goliath 3y ago
I have seen several threads on Qt on HN in the past and was always quite surprised on the takes in the comments section here, especially on Qml, but never bothered to write up a reply so far. I myself am mainly a C programmer, doing low level stuff, with occasional detours into C++ projects. In 2019/2020, I worked on a larger project replacing a web based UI on an embedded device with something Qt based, not having touched Qt since version 4. Due to some of my older spare time projects, I have somehow become the go-to graphics guy in our company, but usually those issues revolve around questions like "why does the display bridge do those bizarre things?". This projects was IMO a quite interesting excursion outside of fiddling with graphics drivers. Yes, I was a bit put of by Qml at first too, but eventually found it a breeze to work with. Qml is a language for designing both the UI layout and UI level interactions. Writing code and trying it out was a very refreshing change from having to fiddle with some IDEs Visual UI designer. I managed to cobble together complete mock-up clone of some of the existing UI screens in only an afternoon, rather than e.g. 3 or 4 days as originally budgeted in some cases, spending the rest of the time on "fine tuning" and starting with the back-end integration. Combined with Qts emphasis on Model-View-Delegate design this allowed us to very cleanly separate the UI from the actual logic, to the point were the UI would work like a LEGO brick stuck on top of the application logic. Even as a die hard C programmer, I would say I liked working with Qml and it is definitely something they did right.
- Dessesaf 3y ago
  QML is nice, and IMO a much better version of the HTML/CSS/JS web stack. There are also decent debugging tools and it seems to perform well-enough (though you can certainly shoot yourself in the foot). But a lot of the QtQuick components and the language itself have weird edgecases that are never documented and probably just simply bugs. Building reusable components in QML isn't easy. A lot of available properties depend on how you instantiate the component, and it's not always possible to specify exactly what properties you expect to be bound (this is where a lot of the edge-cases that I noticed come in). Components seem to be a somewhat leaky abstraction, especially when used as delegates in views. And the actual IDE integration of QML into QtCreator is just bad. It's frustratingly slow, loses type information of components very easily, doesn't even highlight properly a lot of the times and has no other advanced integration. It's weird. You'd think such a tightly integrated language could have amazing IDE support, but it just doesn't.
deutschepost 3y ago
I have said it once and I will say it again: You really should think twice about buying Qt embedded licenses. Unless you really need an embedded version of Qt the LGPL variant is probably fine for you. Everyone who is saying that Qt is too expensive -> It's free. Just Use LGPL. All the tools are GPL but that doesn't matter if you don't want to link against those. The Libraries itself are LGPL so you can dynamically link against them with attribution. Everyone who is saying that they need the Qt Support -> You probably don't. If you live on the bleeding edge you sometimes get cut. Qt for all its flaws really is fine. And if you get stuck the community will help out just as good. Everyone who is saying that they already bought into it -> Bad news for you. The license terms of the commercial license are very restrictive. If you are building an application which communicates over a network or building a system which consists of multiple programs you have to make sure you don't integrate or communicate with a program which uses the LGPL variant[0]. Yes that's right, if you pay them money you better make sure that you never run your program on KDE because it would inadvertently communicate with software that you are not allowed to communicate with. Of course you are allowed to communicate with everyone while using the LGPL. ALWAYS use the LGPL variant! Unless you are not able to work within the boundaries of it. If you have to spend money you are better off donating to the KDE Free Qt Foundation. [0]https://embeddeduse.com/2023/01/06/using-qt-5-15-and-qt-6-under-lgplv3/ https://embeddeduse.com/2023/01/06/using-qt-5-15-and-qt-6-un...
- jraph 3y ago
  > programs you have to make sure you don't integrate or communicate with a program which uses the LGPL variant[0]. Yes that's right, if you pay them money you better make sure that you never run your program on KDE because it would inadvertently communicate with software that you are not allowed to communicate with Wow, you seem right. That's incredibly dumb. It almost seems auto-destructive.
  - deutschepost 3y ago
    The commercial variant of Qt is designed to appeal to big players like car manufacturers. Not your small startup which is building a desktop app. If car manufacturers would decide to support upgrading the Qt version by uploading shared objects directly to the car there would be no need for them to buy Qt Licenses. Because technically they could support all points of the LGPL. But that will never happen for two reasons: 1) It is very hard to get out of the contract if you already bought a license. You would have to prove that you aren't using any commercial tools anymore (of course they are the same tools as GPL but installed a different way). 2) They are car manufacturers and known to lock down their systems as much as possible. The Qt Company probably didn't think about the average C++ Developer or Desktop programs at all while writing these Terms and Conditions...
Nokinside 3y ago
As long as the company revenue keeps growing 30-40% annually criticizing Qt pricing is not relevant. Annualized total return for past 5 years is 63%. QT is pivoting towards embedded industries away from pure Mobile/PC markets.
boris 3y ago
> Qt should create a vanilla c++ package and tooling manager like Rusts cargo for dependencies and tools (and make semantic versioning mandatory). [...] Make the tool open source with vanilla c++ (aka non Qt projects), only so it can become the de facto standard. Or just use one that is already working: https://build2.org https://build2.org (bonus point: also gets rid of CMake). There are even "Qt classic" packages for both Qt5 and Qt6: https://queue.stage.build2.org/?packages=Qt5 https://queue.stage.build2.org/?packages=Qt5 https://queue.stage.build2.org/?packages=Qt6 https://queue.stage.build2.org/?packages=Qt6
captainmuon 3y ago
I think a lot of the problems come from the incentives the Qt Company has. They get a lot of their revenue from big companies like car manufacturers with very specific requirements. That's why their QML examples always contain a car dashboard. Another part of their revenue is from people who are locked in to their license agreement. They are not putting enough resources into desktop development, widgets, or to make it a competitor to Electron, Flutter, and simliar tools. What Qt would need on the desktop is that they put Qt widgets on a new, modern, compositing based foundation (like Gtk did) in order to support transparency, animations etc. Then implement up to date themes for macOS and Windows (using foreign drawing if possible). The macOS theme is clearly outdated and still has blue buttons. Modern WinUI is not included at all. Yeah folk wisdom is that you cannot make a convincing native app this way, but you can get 95% there, and it will be much more native looking than any electron app. I don't see any of this happening, though.
- baybal2 3y ago
  [dead]
- toyg 3y ago
  The problem is that the desktop market is fundamentally dead from a commercial perspective. Without the embedding/automotive sector, Qt would have died more than 10 years ago; so it makes sense that they care for their actual source of revenue. You can have the best desktop tech in the world, if nobody wants to pay to do desktop development you're SOL. The real target should be phones. QT should have been what Electron became. To be fair, they tried with QT, but it was a day late and a dollar short - as web-like as it is, it's not real web. If you want one codebase for web and mobile, at the moment you'd never pick QML. What they could do is competing with Electron: provide a better, more featureful way to package advanced webapps. But it means stepping back a lot, and competing with free is hard. Or they could go back to QtWidgets, but it feels like that ship has sailed - apps these days don't even try to fit in with the phone's own native style.
  - pjmlp 3y ago
    Except that the folks using Electron don't care about C++, VSCode being the exception, being how much it has of it to work around performance issues.
iamleppert 3y ago
I cringe when I have to install a Qt app, because at least half of the time, even as a user, I know I'll be fighting with Qt system dependencies. Even if the app is distributed in binary form. The situation gets worse when you have to actually build the source. It seems like the API is never stable, even with minor versions they seem to like changing methods name and breaking backwards compatibility. When I look at what was changed, it looks like change for change sake and I can't tell a difference in how its better. It happens so often that I'll avoid a Qt app because the dependency management is so bad. Then once you finally get it to work, be prepared to spend time on Stack Overflow researching arcane QT_ environment variables to fix things like display scaling and added additional library paths at runtime. It's been this way as long as I can remember, and the problem has persisted across versions and different OS and systems I've had over the years. I can always get something working, but it just feels like nothing ever just works out of the box. Also QT applications seem like they are more unstable to me, more prone to crash and just not work well. I'd rather have a runtime error in some javascript frontend than the entire app crash, and have to pour through enormous stack traces through crazy overly abstracted code that shows a list or runs some tab component. Then there is the style, at least the one that comes out of the box. Very inconsistent and relying too heavily on platform features that make the app look and behave differently on different OS's. It must be hard for developers to customize because you rarely see a polished Qt app, they all look the same and have the same quirks and lack of padding, spacing and consistent typography. The last thing is kind of personal, but I tire of seeing the word Qt everywhere. We already know we are working with Qt, you don't need to prefix every single class and package with it. I get this may have to do with namespacing, but in practice it just makes source harder to read and debug.
- toyg 3y ago
  These are just packaging issues, typically (but not only) on Linux. Dedicated developers know what to do to avoid all of that. As for the style - again, depending on developer choices, they can actually be the most consistent with the platform they run on. Unfortunately that was a selling point for the original QtWidgets more than QML - QML does things "the web way" and just doesn't give a crap about desktop styles. Things like "lack of padding" sound funny to me, because on that side Qt is definitely superior to the overpadded monstrosities of GTK or web-like frameworks, who waste screen real estate for fun. Qt simply uses desktop conventions, which are "just right" in QtWidgets with minimal attention to layouts. > I tire of seeing the word Qt everywhere Now you're just being silly. Everyone does it - Apple with NS etc.
annoyingnoob 3y ago
I passed on Qt over pricing alone. My product does not need to be strapped to another that costs so much.
ogoffart 3y ago
Shameless plug for an alternative to Qt I've been working on: Slint https://slint-ui.com https://slint-ui.com
- tempodox 3y ago
  That page literally hurts my eyes. You may want to rethink the visual design.
- r0l1 3y ago
  That looks really great! Thanks for sharing. Ever thought of adding go support?
hermitcrab 3y ago
For those complaining about the price, please see: https://www.qt.io/pricing/qt-for-small-business https://www.qt.io/pricing/qt-for-small-business This is the plan I am on as an Indie developer.
ndr_ 3y ago
In multiple entities I have worked for over the past 15-20 years, there was a sentiment that we wanted to support the fine folks behind Qt, thus licensed each and every developer seat, to the tune of 4000€. At some point, they started biting the hand that was feeding them: demanded an enterprise-wide usage audit (so we had to involve our Legal team to fend them off), changing the EULA in such a fast pace we couldn‘t keep up, created this forever-keep-paying rule…. Today, at my new employer, I use the LGPL version, like we always could have. No good deed goes unpunished, and I have taken enough battering.
- deleted 3y ago
  [deleted]

113 points by Kelteseth 3y ago

Strongly disagree with the "Qt 'tools' should use QML more". QML and Widgets are strong at different things, the tools are relatively clear cases of the things that Widgets are better at. There is no point in shoehorning QML into them just so they use QML, which is optimized for different things.

rat9988 3y ago
What are QML and QWdiget better at then?
- account42 3y ago
  QML is a good fit for fullscreen touch interfaces or video displays. Also simple game - complex ones are probably better off not using Qt at all. QWidget is the "old" desktop UI toolkit that is good for desktop UIs.
  - rubymamis 3y ago
    Qt Quick is catching up with QWidgets. While still some way to go, I agree with the OP that it will align incentives for them to improve edge cases of features that exist in QWidgets but lacking in Qt Quick.
- bluGill 3y ago
  QWidgets look and act like a desktop application. QML looks and acts like a touch screen application. The two use cases are very different. A touch screen application doesn't work well on a keyboard/mouse environment. A keyboard/mouse application doesn't work well on a touch screen.
- EntrePrescott 3y ago
  The Widgets are easier to work with for pure desktop apps… but they are limited to that purpose. Qt Quick and QML are better for pretty much any application use case that isn't the classic desktop. Especially any form of app for mobile or embedded devices.
  - Kelteseth 3y ago
    Author here. Please show me an example for your claim.

samsquire 3y ago

Creating a multiplatform native framework for creating native looking GUIs is extremely difficult and a challenging piece of work. Add the complexity of C++ and I'm not surprised that things are as complicated as they are. I once looked at what needs to be implemented to implement a text control interface in Mac OS and it was an API with hundreds of methods. GUI frontend development IS complicated. There's so many edge cases with text rendering, editing logic, layout, state, native compatibility. I started writing the beginnings of a flowing rendering engine using WxWidgets in Python using an algorithm from the ORC Solver whitepaper. IntelliJ Idea, Netbeans are intricate advanced frontends and they are both written in Java. How would a user interface written in a functional language look? I used to use Xmonad as a window manager which was very powerful and easy to use but it is written in Haskell. I think any frontend technology that wins needs to be simple and easy to comprehend. I have yet to use Flutter. I did have a frontend in Electron but my code was awful. I would rather create user interfaces with a simple language and use a fast language for the data crunching. I think Python and Java count.

brabel 3y ago
> How would a user interface written in a functional language look? Maybe you're not aware of Elm? https://elm-lang.org https://elm-lang.org Elm is really functional, unlike the likes of React that are just partially, kind of functional. There's an attempt at bringing Elm to the desktop, the Roc language... here's an UI example written in Roc: https://github.com/roc-lang/roc/blob/main/examples/gui/hello.roc https://github.com/roc-lang/roc/blob/main/examples/gui/hello...
- GiorgioG 3y ago
  Maybe most people aren’t aware of Elm. Despite its good ideas it’s a niche language that should be avoided for real work because it has a bus factor of 1.
- DarkNova6 3y ago
  Unfortunately, it seems the developers behind elm do everything in their power so elm can never become mainstream

raverbashing 3y ago

> I have already said it many times online. The way Qt wants to make money is too much focused in big B2B style. There is a general sentiment in the community that the current pricing is bad for small businesses. It feels like giving into a trap when using Qt for small business. This. And might I say, a lot of IT companies in Europe are awful at pricing. They're aiming for the B2B market and forget all the others Well guess what, people are just embedding browsers now and except for niche apps, few people care about Qt

korijn 3y ago
> Well guess what, people are just embedding browsers now Which is incredibly selfish and hypocritical, it drives up resource consumption across the world at a massive scale. Not just in terms of energy use, but it also forces people to buy more powerful machines, intensifying electronic waste problems. Great job guys!
- raverbashing 3y ago
  This was a problem 15 yrs ago. Today it isn't. The cheapest stuff that can run Qt is the same one that runs a basic Android install
  - account42 3y ago
    It's still a problem today even if you have trained yourself to not notice it.
  - rychco 3y ago
    Modern software embedding an entire web browser is absolutely & undeniably a problem.
    - qtzfz 3y ago
      I hear this argument often, but I haven't heard a convincing argument. Why? Lack of storage? No. Lack of computing power or RAM? No. Then?

zerr 3y ago

They have allienated C++ devs by imposing on them the abomination that is QML. The first thing they should do is to provide a public API for using QtQuick solely in C++.

bombolo 3y ago
I think their plan was to attract js developers, letting the C++ code to be hidden behind a curtain and the UI stuff to be written in js. But since to run it still needs a main() to call the QML part, probably js developers stay as far away from it as possible.
rleigh 3y ago
This is exactly the reason I've avoided QML. Give me a 100% C++ API and I will reconsider.
- rubymamis 3y ago
  Give it a shot, I learned all the basics in a day. The next day I had a working prototype for a new feature. See: https://github.com/nuttyartist/notes/pull/574 https://github.com/nuttyartist/notes/pull/574
jeroenhd 3y ago
As an outsider, I have to ask: what's wrong with QML? Was there a better, earlier layout language before QML that I don't know about?
- toyg 3y ago
  The problem with QML is that it's not C++. Most Qt developers are C/C++/Python folks, being forced to use JS is not their idea of fun. Also, for some time the prebuilt QML widgets didn't have feature parity with the old QtWidgets. I think they're now there, but it's still a different philosophy: QtWidgets tried hard to fit in the desktop paradigm (with tray icons, desktop services, etc), whereas QML simply doesn't care - QML more or less expect to simply take over the screen and do everything on their own, web-style. Again it's a culture clash with traditional QT that QML creators seem to have fundamentally underestimated.

gumballindie 3y ago

QML is by far the most horrible thing about qt.

jenadine 3y ago
What's wrong with QML?

st_goliath 3y ago

I have seen several threads on Qt on HN in the past and was always quite surprised on the takes in the comments section here, especially on Qml, but never bothered to write up a reply so far. I myself am mainly a C programmer, doing low level stuff, with occasional detours into C++ projects. In 2019/2020, I worked on a larger project replacing a web based UI on an embedded device with something Qt based, not having touched Qt since version 4. Due to some of my older spare time projects, I have somehow become the go-to graphics guy in our company, but usually those issues revolve around questions like "why does the display bridge do those bizarre things?". This projects was IMO a quite interesting excursion outside of fiddling with graphics drivers. Yes, I was a bit put of by Qml at first too, but eventually found it a breeze to work with. Qml is a language for designing both the UI layout and UI level interactions. Writing code and trying it out was a very refreshing change from having to fiddle with some IDEs Visual UI designer. I managed to cobble together complete mock-up clone of some of the existing UI screens in only an afternoon, rather than e.g. 3 or 4 days as originally budgeted in some cases, spending the rest of the time on "fine tuning" and starting with the back-end integration. Combined with Qts emphasis on Model-View-Delegate design this allowed us to very cleanly separate the UI from the actual logic, to the point were the UI would work like a LEGO brick stuck on top of the application logic. Even as a die hard C programmer, I would say I liked working with Qml and it is definitely something they did right.

Dessesaf 3y ago
QML is nice, and IMO a much better version of the HTML/CSS/JS web stack. There are also decent debugging tools and it seems to perform well-enough (though you can certainly shoot yourself in the foot). But a lot of the QtQuick components and the language itself have weird edgecases that are never documented and probably just simply bugs. Building reusable components in QML isn't easy. A lot of available properties depend on how you instantiate the component, and it's not always possible to specify exactly what properties you expect to be bound (this is where a lot of the edge-cases that I noticed come in). Components seem to be a somewhat leaky abstraction, especially when used as delegates in views. And the actual IDE integration of QML into QtCreator is just bad. It's frustratingly slow, loses type information of components very easily, doesn't even highlight properly a lot of the times and has no other advanced integration. It's weird. You'd think such a tightly integrated language could have amazing IDE support, but it just doesn't.

deutschepost 3y ago

I have said it once and I will say it again: You really should think twice about buying Qt embedded licenses. Unless you really need an embedded version of Qt the LGPL variant is probably fine for you. Everyone who is saying that Qt is too expensive -> It's free. Just Use LGPL. All the tools are GPL but that doesn't matter if you don't want to link against those. The Libraries itself are LGPL so you can dynamically link against them with attribution. Everyone who is saying that they need the Qt Support -> You probably don't. If you live on the bleeding edge you sometimes get cut. Qt for all its flaws really is fine. And if you get stuck the community will help out just as good. Everyone who is saying that they already bought into it -> Bad news for you. The license terms of the commercial license are very restrictive. If you are building an application which communicates over a network or building a system which consists of multiple programs you have to make sure you don't integrate or communicate with a program which uses the LGPL variant[0]. Yes that's right, if you pay them money you better make sure that you never run your program on KDE because it would inadvertently communicate with software that you are not allowed to communicate with. Of course you are allowed to communicate with everyone while using the LGPL. ALWAYS use the LGPL variant! Unless you are not able to work within the boundaries of it. If you have to spend money you are better off donating to the KDE Free Qt Foundation. [0]https://embeddeduse.com/2023/01/06/using-qt-5-15-and-qt-6-under-lgplv3/ https://embeddeduse.com/2023/01/06/using-qt-5-15-and-qt-6-un...

jraph 3y ago
> programs you have to make sure you don't integrate or communicate with a program which uses the LGPL variant[0]. Yes that's right, if you pay them money you better make sure that you never run your program on KDE because it would inadvertently communicate with software that you are not allowed to communicate with Wow, you seem right. That's incredibly dumb. It almost seems auto-destructive.
- deutschepost 3y ago
  The commercial variant of Qt is designed to appeal to big players like car manufacturers. Not your small startup which is building a desktop app. If car manufacturers would decide to support upgrading the Qt version by uploading shared objects directly to the car there would be no need for them to buy Qt Licenses. Because technically they could support all points of the LGPL. But that will never happen for two reasons: 1) It is very hard to get out of the contract if you already bought a license. You would have to prove that you aren't using any commercial tools anymore (of course they are the same tools as GPL but installed a different way). 2) They are car manufacturers and known to lock down their systems as much as possible. The Qt Company probably didn't think about the average C++ Developer or Desktop programs at all while writing these Terms and Conditions...

Nokinside 3y ago

As long as the company revenue keeps growing 30-40% annually criticizing Qt pricing is not relevant. Annualized total return for past 5 years is 63%. QT is pivoting towards embedded industries away from pure Mobile/PC markets.

boris 3y ago

> Qt should create a vanilla c++ package and tooling manager like Rusts cargo for dependencies and tools (and make semantic versioning mandatory). [...] Make the tool open source with vanilla c++ (aka non Qt projects), only so it can become the de facto standard. Or just use one that is already working: https://build2.org https://build2.org (bonus point: also gets rid of CMake). There are even "Qt classic" packages for both Qt5 and Qt6: https://queue.stage.build2.org/?packages=Qt5 https://queue.stage.build2.org/?packages=Qt5 https://queue.stage.build2.org/?packages=Qt6 https://queue.stage.build2.org/?packages=Qt6

captainmuon 3y ago

I think a lot of the problems come from the incentives the Qt Company has. They get a lot of their revenue from big companies like car manufacturers with very specific requirements. That's why their QML examples always contain a car dashboard. Another part of their revenue is from people who are locked in to their license agreement. They are not putting enough resources into desktop development, widgets, or to make it a competitor to Electron, Flutter, and simliar tools. What Qt would need on the desktop is that they put Qt widgets on a new, modern, compositing based foundation (like Gtk did) in order to support transparency, animations etc. Then implement up to date themes for macOS and Windows (using foreign drawing if possible). The macOS theme is clearly outdated and still has blue buttons. Modern WinUI is not included at all. Yeah folk wisdom is that you cannot make a convincing native app this way, but you can get 95% there, and it will be much more native looking than any electron app. I don't see any of this happening, though.

baybal2 3y ago
[dead]
toyg 3y ago
The problem is that the desktop market is fundamentally dead from a commercial perspective. Without the embedding/automotive sector, Qt would have died more than 10 years ago; so it makes sense that they care for their actual source of revenue. You can have the best desktop tech in the world, if nobody wants to pay to do desktop development you're SOL. The real target should be phones. QT should have been what Electron became. To be fair, they tried with QT, but it was a day late and a dollar short - as web-like as it is, it's not real web. If you want one codebase for web and mobile, at the moment you'd never pick QML. What they could do is competing with Electron: provide a better, more featureful way to package advanced webapps. But it means stepping back a lot, and competing with free is hard. Or they could go back to QtWidgets, but it feels like that ship has sailed - apps these days don't even try to fit in with the phone's own native style.
- pjmlp 3y ago
  Except that the folks using Electron don't care about C++, VSCode being the exception, being how much it has of it to work around performance issues.

iamleppert 3y ago

I cringe when I have to install a Qt app, because at least half of the time, even as a user, I know I'll be fighting with Qt system dependencies. Even if the app is distributed in binary form. The situation gets worse when you have to actually build the source. It seems like the API is never stable, even with minor versions they seem to like changing methods name and breaking backwards compatibility. When I look at what was changed, it looks like change for change sake and I can't tell a difference in how its better. It happens so often that I'll avoid a Qt app because the dependency management is so bad. Then once you finally get it to work, be prepared to spend time on Stack Overflow researching arcane QT_ environment variables to fix things like display scaling and added additional library paths at runtime. It's been this way as long as I can remember, and the problem has persisted across versions and different OS and systems I've had over the years. I can always get something working, but it just feels like nothing ever just works out of the box. Also QT applications seem like they are more unstable to me, more prone to crash and just not work well. I'd rather have a runtime error in some javascript frontend than the entire app crash, and have to pour through enormous stack traces through crazy overly abstracted code that shows a list or runs some tab component. Then there is the style, at least the one that comes out of the box. Very inconsistent and relying too heavily on platform features that make the app look and behave differently on different OS's. It must be hard for developers to customize because you rarely see a polished Qt app, they all look the same and have the same quirks and lack of padding, spacing and consistent typography. The last thing is kind of personal, but I tire of seeing the word Qt everywhere. We already know we are working with Qt, you don't need to prefix every single class and package with it. I get this may have to do with namespacing, but in practice it just makes source harder to read and debug.

toyg 3y ago
These are just packaging issues, typically (but not only) on Linux. Dedicated developers know what to do to avoid all of that. As for the style - again, depending on developer choices, they can actually be the most consistent with the platform they run on. Unfortunately that was a selling point for the original QtWidgets more than QML - QML does things "the web way" and just doesn't give a crap about desktop styles. Things like "lack of padding" sound funny to me, because on that side Qt is definitely superior to the overpadded monstrosities of GTK or web-like frameworks, who waste screen real estate for fun. Qt simply uses desktop conventions, which are "just right" in QtWidgets with minimal attention to layouts. > I tire of seeing the word Qt everywhere Now you're just being silly. Everyone does it - Apple with NS etc.

annoyingnoob 3y ago

I passed on Qt over pricing alone. My product does not need to be strapped to another that costs so much.

ogoffart 3y ago

Shameless plug for an alternative to Qt I've been working on: Slint https://slint-ui.com https://slint-ui.com

tempodox 3y ago
That page literally hurts my eyes. You may want to rethink the visual design.
r0l1 3y ago
That looks really great! Thanks for sharing. Ever thought of adding go support?

hermitcrab 3y ago

For those complaining about the price, please see: https://www.qt.io/pricing/qt-for-small-business https://www.qt.io/pricing/qt-for-small-business This is the plan I am on as an Indie developer.

ndr_ 3y ago

In multiple entities I have worked for over the past 15-20 years, there was a sentiment that we wanted to support the fine folks behind Qt, thus licensed each and every developer seat, to the tune of 4000€. At some point, they started biting the hand that was feeding them: demanded an enterprise-wide usage audit (so we had to involve our Legal team to fend them off), changing the EULA in such a fast pace we couldn‘t keep up, created this forever-keep-paying rule…. Today, at my new employer, I use the LGPL version, like we always could have. No good deed goes unpunished, and I have taken enough battering.

deleted 3y ago
[deleted]