[0]https://en.wikipedia.org/wiki/The_Qt_Company
It doesn't look like they are in the take over the world then monetise business, more like make a niche product and charge for it business. Then kind of makes sense to charge enterprise level license fees and operate with enterprisey licences and not bother too much with making the world a better place?
How would you propose funding such a thing?
Or would you like to volunteer to spend every waking moment of your life fixing bugs like "your layout manager misaligns buttons by 1-2 pixels but only on my system when the moon is full or on 64-bit CPUs in the Northern hemisphere while using Arabic languages."
That's what working with UI/UX is like, especially if you support... well... really anything other than native macOS on systems sold by Apple in the last 4 years only. It's why FOSS has never crossed over into the mainstream in any meaningful way. Making software is fun. Making it polished, pretty, and usable is a house of pain. Doing that across platforms is a journey into the lower circles of hell.
Electron is heavily subsidized by Google (and others) via Chromium. It's also a much more bloated user-unfriendly resource hog than Qt. But we use it because paying for quality software is unthinkable. Now off to Starbucks to buy another $12 coffee drink.
Where can we learn about this? As far as it seems, qt is still, as always, distributed under the LGPL; which is as "open source" as it gets. The main site of qt even lists explicitly the Four Freedoms of the FSF : https://www.qt.io/licensing/open-source-lgpl-obligations
But the Qt Company has tried to make using the open source releases more and more inconvenient: licensing terms for the commercial version that are not at all forthcoming to OSS-to-commercial converts (implying that you need to pay for commercial licenses from the start), more limited access to precompiled binaries and registration obligations when you want to use the official Qt installer. That behavior seems to say that the company is bound by an agreement that they honor only reluctantly.
And the KDE foundation is the only thing putting QT on the map. They wouldn't dare break the agreement, unless they want to burn their company to the ground.
A Qt app is so much lighter, faster and more enjoyable to use than any electron app. GTK still doesn't click for me as a programmer. Alternatives don't feel as functional as those three options.
On the other hand, I really doubt the open source community is responsible for a large chunk of the Qt company's income.
Sure, breaking the agreement would further hurt their image in the open source community, but I doubt it would have a large impact on the company's future.
The whole thing felt so fragile.
We purchased a small business license for QT 5 and I’ve never hated a framework more. It was clunky, resource consuming, surprisingly challenging to build in the way we needed, difficult to work with, etc. No engineer wanted to touch the gui codebase until we moved off of it.
Most of the use cases where I see people sing it’s praises are the python framework rather than the C++ one, but are we really the only people who had this negative of an experience?
Writing GUIs is not a ton of fun for me (whether with Qt on desktop, native development on iOS and Android, or Flutter for mobile/desktop), but I wouldn't say Qt Widgets are worse than other stuff. I'd say it's definitely better that Android and iOS were a few years ago, before reactive programming became widespread.
I didn't have a good experience with QML; I'd call it at most not great, not terrible.
I've been using Flutter lately for a desktop app and the GUI part is more pleasant to write, for me (mainly because of the general "immediate mode/react" feel); if the app had a reasonably complex business logic I wouldn't want to write it in Dart though.
"... if the app had a reasonably complex business logic I wouldn't want to write it in Dart though."
My experience with QML/Quick is that while you get a little JavaScript runtime and a slightly less obtuse way of defining "widgets" and application layouts than the original Qt "forms", there are some clear drawbacks that make it a near non-starter for anything I've thought about using it for.
Right out of the box, you have to use QML, which is a weird hybrid of language/markup paradigms, and it's a proprietary language. What designer knows QML? Probably f$#%& zero. Electron wins right out of the gate because what designers don't know at least something about HTML and CSS? Sure, if QML was that groundbreaking then maybe people would learn it, but it's owned by a company and it brings nothing new to the table that HTML and CSS can't do better.
The solution to most things in Quick is to write JavaScript. I've been a JavaScript engineer for most of my career, but when you're writing a Qt application then the obvious place to do anything useful or complex is in the host language of C++ or Python. So what if you want to tie behavior between your Quick widget and a C++ library you either wrote yourself or have imported from a vendor? Well, you can kinda sorta do that, but it's hard to explain here; let's just say that tying a widget to C++ code is extremely clumsy, and good luck calling a function on a Quick widget class because you just can't simply do that.
For instance, Qt provides a WebView widget, which was exactly what I needed recently. Uh oh, the decided to make it a Quick widget only, rather that do the obvious thing of exposing it as a C++ class and providing a Quick widget that wraps around it. Why did they do this? I guess it's because in the long term they think that they'll move away from classic widgets entirely. In any case, I wanted to call the `runJavaScript` method on the widget class without having to jump through hoops in QML. The only way to make that happen was to hack the build process to expose private methods.
But I realized that, at that point, there was no longer any point in using Quick if I was going to have to use some neat tricks in C++.
So in just a day, I wrote a classic widget that implements the same WebView used in the Quick version, just without any of the QML crap.
https://github.com/Ravenstine/qt-web-view-widget
And yeah, Qt does provide some form of a WebView in as a classic widget but, guess what, it involves bundling a browser runtime rather than using the browser engine of the host OS. Makes sense if you need more of the browser APIs exposed, but if all you want to do is show some simple things on a webpage and call JS from C++, then going through the effort of compiling Qt with support for that browser engine is overkill.
Overall, I don't mind most things about Qt. Despite how overcomplicated some of it is, it does what I want, which is to allow me to write native desktop apps without needing to invest much of my knowledge in OS-specifics. I like that I can use their Bluetooth library and, besides some quirks with how macOS handles device identifiers, I can compile it on other platforms and it will work for the most part.
I wish they'd abandon QML/Quick and just focus on making the experience of writing completely native apps better. I also see no reason why the solution to mobile development can't simply be different sets of classic widgets that are mobile-specific.
As for mobile: if you can afford to develop completely independent apps for mobile, then do it. Many organizations cannot, and saying "we'll do the backend in C or C++, then call that code from a Java/.NET/Swift/HTML5 UI" looks fine on paper but then reality hits. Is the deliverable big? Yes it is, especially if you don't compile statically. But there's no good and cheap solution (and yes, Qt is cheap for the kind of savings it provides).
That said, I still hate trying to do basic stuff with Qt, for example using slots. Example: im calling an external script or process that could take 30 seconds to run. I'm doing this 50 times and using thread pooling to manage those workers. Try issuing an update to a widget to let the user know that its progressing. The slot setup barely makes sense, is a pain in the arse to understand, and I've not managed to do it successfully yet. The issue here is, its the main way of doing things and its a nebulous, poorly articulated concept in almost every bit of doc or guide, and very difficult to implement between the Designer and code of an existing application.
I would say I prefer QML over that other Qt GUI Framework, mostly because you can leverage JavaScript for fast development, but not that fond of the the GUI part of QML, but it is still better than the Qt GUI Framework because of better customization.
I found it difficult to adapt and style many of the standard widgets in the Qt GUI framework, like item lists and similar things.
It is sort of easy to expose "dumb" C++ functions from Qt to be used from QML's JavaScript and then you put all the GUI logic in JavaScript instead.
Qt makes the C++ easier with their own copy-on-write containers for the most common things you need, however the extra qmake build step is somewhat horrible and when you need to ship your application you run some command line tool that copies a bunch of dlls that you still need to sort out manually. And when all is done you have big zip file anyway.
But would I use Qt again? No, even if we ignore the licensing issues.
I'm not interested in writing GUI desktop applications in C++, it just too clunky (still with C++20) and does not fit a fast iterative approach (at least not for me) even with all Qt containers. And of course compiling C++ is not fun especially when you add an extra qmake step. (And now I see that Qt 6 has switched to CMake, oh lord, I truly dislike CMake, the main reason why I stopped using CLion)
If I remember correctly there was some complaints of lack of documentation for the Qt Python bindings, that you basically need to read the C++ code and then figure it out, but that can have changed.
If I want native widgets I write that in PureBasic, PureBasic is way faster to develop in than C++ or even C. I have instant compilation of my project on press of button out of the box. No asinine build step that I spend hours to configure.
And for QML I think there are better options. One that I'm in the beginning of building is with Sciter(HTML/CSS/JS) with a custom backend in PureBasic.
Nice thing with Sciter is that you can easily bind it to any language you prefer as long as you can load a dynamic library(dll/so/dylib) (I think if you have a license you can compile it against C headers). It exist many different bindings, C/C++ of course, Pascal, golang, rust, python, .NET, D.
Or you can just go with app bundle that Sciter ships and don't have custom backend at all (all depending on what you are trying to build of course). Sciter is not a browser either like electron, so it doesn't have the same resource impact.
Would you elaborate how do you program GUIs in PureBasic? I noticed there are multiple ways to do that: positioning each gadget manually, coding XML, using visual GUI designer, more?
Also, how are things on macOS? They mention full Cocoa coverage in the documentation.
The Gtk devs have at least given the impression that they want to support other platforms (for example, this talk: youtube.com/watch?v=FB2Y2Wk6FKE or this post: https://discourse.gnome.org/t/is-gtk-4-cross-platform/6144/2). And getting it up and running on Windows with MSYS was pretty easy. It also uses GPU-accelerated rendering if available.
Dream solution is having a nix flake setup with correct compiler selection and switches for Windows/Linux/Mac and Android.
Accessibility is the hill virtually every FOSS UI cross-platform toolkit dies on.
Not doing anything new in recent years but Qt is definitely a joy to work with.
From MVC on data management in the widgets, networking, UI handling and tons of customization.
The Qt Creator IDE was the fastest IDE I've worked with and very helpful with Qt Designer integrated.
Dealing with system icons in Linux or i18n, tooling, compilation and building and so many other really complex stuff is pretty damn easy with Qt.
Although I've used Qt/C++ and never the Python binding.
Thanks for all the hard work and amazing people behind it.
Can you develop a normal (non open source) apps using Qt/Python? For line of business apps users are not supposed to have access to source code etc. Also, do you have to use QML, did you use QML. At first glance that wasn't so appealing.
connect(model, &ModelObject::somethingChanged, [=] {
// knead the data structures used for the UI-side data model into something much simpler
// used for the audio engine
audioQueue.push([... data ...] { update the engine with the new data });
});
I found that the primitives for threading and message passing between threads didn't work that well for me (both in terms of what they provide and in terms of performance) so I ended up "bypassing" them a bit with my own threading code (that is, still using QThread and QMutex etc. but not using the signals and slots model).
Once I've done that and moved everything off of the main thread, things worked well, so that program is still in QtWidgets with C++ and still in use, but I felt that Qt didn't do a good job of making multithreading easy for me.
That said, I still like continue to use Qt so you can consider this a sort of mild endorsement from me, I guess.
Not that long ago there was an announcement by GitHub where they talked about adding a feature for developers to monetize their projects. I don't remember what it was exactly but I think it was that you could make the releases only available to people who paid and some people were outraged. This isn't even a new thing, people were selling copies of OSS for decades.
And it's not only about money. There's too much shitting on OSS devs for minor problems. Some project doesn't get updated every day and people just start blasting the dev even though they got the software for free with no strings attached.
I'm not saying you can't criticize but personally I'm a lot more lenient on something I got completely for free, no limits, no contracts.
I would hope any business that acquired such a project would respect the foundation laid by the open source community through their contributions over the last two decades. After all, the reason Qt is hailed as such a fantastic framework is because it has been collaborated on for years by the same community that used it to create their own applications. The heavy use of the framework is what makes it valuable. KDE is an expample of an entire open source distribution that uses Qt much like gnome uses the GTK.
https://www.qt.io/blog/top-contributors-to-qt-project-in-202...
I like Qt. It has some fucked up bits, but for the most part, it's one of the least frustrating UI experiences I've had. That being said, I can't discourage anybody from using it in a commercial context enough. Please don't give them any money. If you're curious on specifics, just ask; I don't think a wall of text of me just listing my gripes would be terribly helpful.
Myself I have zero problems paying for software if it is good. My problem with Qt is that it isn't worth my money.
These two are not mutually exclusive, one can want a good FLOSS library and at the same time dislike the tactics of company that is currently developing said FLOSS library.
The slicer is Cura and it works great and feels good to use. It's a little slow to load, but once it's loaded it's a joy to use.
The CAD software is Fusion 360. Functionally, it does lots of great stuff, but it too is slow to load and, unlike Cura, it feels terrible to use. Of all the software I use, Fusion 360 is the worst. How has Autodesk managed to write a Qt app that feels this bad?
It does feel like a shitty Electron app though. It's really too bad because functionally it's great, it's just a terrible UX. I think it makes Qt look bad too.
BTW, I use Fusion 360 for power modelling (hundreds of thousands of triangles) and while it's slow, it deals with nearly every problem I have well. It looks like most of the underlying compute is single-threaded and often blocks the UI.
[1]: https://code.qt.io/cgit/qt/qtreleasenotes.git/about/qt/6.3.0...
Yes, sometimes it can be awkward to use, and yes, there are longstanding bugs in Qt itself that remain unfixed. In my opinion, it is still the best C++ GUI library out there. For basic to intermediate GUI apps, it just works, and for advanced use cases, with some effort you can make it do whatever you need.
I write Qt software now and I’d be happy to keep doing so.
How does the development experience compare to React/Redux? Is there more or less or about same amount of work involved? Learning curve?
What is the general timeline of QT -> PyQT downstream of features like? ex) quick compiler in QT 6.3
Have you built a major application with PyQT? What about QML?
How do you deal with application state like Redux in PyQT?
Are there noticeable performance gains and efficient resource uses vs Electron?
What advice do you have for someone like me venturing into PyQT? I've used Python in backend only so far.
Have you shipped with the fman build tool from mherrmann? How has the process been like?
Is there a browser or "WebView" component in PyQT6?
Much thanks!
Some people are wary of the license, but if your project is fully open source you'll have no problem
There is still some confusion how best open source developers make a living, some are successful, and some get frustrated. Farming users data(Chrome), donations, dual license, paid addons...
Congrats to Qt for doing their best in delivering a sustained high quality open source product
https://news.ycombinator.com/item?id=31006097
Qt is great for its cross platform support. This is a demo of this capability, not exactly pure qt. Qml. Ecl etc.