Remember kids, every week Qt changes their licensing model, every time less in favor of open source and more in favor of a second Yacht for the shareholders. I hate to recommend electron, but with the current closed direction they are going I to, better to stay away from Qt. The KDE foundation agreement is the only reason they still release Qt as open source, sadly. Qt for MCUs is completely closed for example.
> The KDE foundation agreement is the only reason they still release Qt as open source
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.
I'd say KDE and this agreement are why I would still consider using an open source version of Qt for a new project today. The whole KDE ecosystem will probably always need more stuff from Qt than me and I don't see KDE disappear overnight so I feel covered.
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.
I like GTK, but the falloff in developer experience since 4.0 is really pathetic. Then there's a lot of petty changes I hate too, but that's a discussuon for another time. Word on the street is that KDE's maintainers plan to fork an older version of Qt for their desktop, but I guess only time will tell...
Edit: The KDE bit is wrong, I still stand by the first portion though.
There are at least some car manufacturers paying for Qt that do not care at all about this issue.
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.
> There are at least some car manufacturers paying for Qt that do not care at all about this issue.
I work for a car company using Qt. The open source community around Qt is a significant contributor to the talent pool we hire from (myself included), and it is also a regular contributor to (and indirectly/broadly, the inspiration for) integration-related Qt modules (e.g. QtWayland) we like. Its health is important.
But why would your average developer even bother learning about QT if not because of its popularity in the open source community? The companies that pay for QT will have a hard time finding talent if QT wasn't popular due to its open source nature.
> every week Qt changes their licensing model, every time less in favor of open source
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
They can't just stop licensing the core of Qt under GPL or LGPL (I forget which) due to an old agreement between Trolltech and KDE e.V. that states (roughly) that if there are no more OSS releases of Qt for more than a year, the last public release gets automatically relicensed under something more liberal (BSD or MIT).
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.
To put that another way then: they seem to feel they have some freedom to decide which components should be covered by the KDE agreement.
(To put a finer point on the specifics you mentioned: I believe they once had a policy of making the QML-to-C++ compiler available only to commercial customers, and not to FOSS users, treating it as something distinct from the 'core of Qt'. They later changed their minds on this. [0][1])
Presumably they could start work on a whole new toolkit, call it something other than Qt, and be free of the KDE agreement. This would no doubt be much more work than a typical major Qt release, but they do presumably have the option.
No, that's not true. The Qt Company makes stuff open source but it's open source under a license (GPL) you don't like because you want LGPL or even something more liberal that would allow you to use Qt for free in your closed-sourced application.
LGPLv3 is useless for people developing proprietary applications, which was what I was answering to. Those people want LGPLv2.1, which is how Qt used to be licensed during Nokia times.
How is the LGPLv3 materially different from LGPLv2.1? It's perfectly possible to use Qt under LGPLv3 in a closed source program with dynamic linking without much fuss.
We were trying to document EoL dates for Qt at endoflife.date/qt and it was made needlessly difficult by Qt patches being technically open-source via KDE patches.
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?
Building a cross-platform UI with support for theming, layouts, accessibility, high-DPI, internationalization, and lots of targets is brutally soul-crushingly hard. It involves a ton of the sort of work that is absolutely not fun and that therefore programmers have to be paid to do.
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.
That's definitely a good point. But it's also sort of self-fulfilling: those layout misalignments and RTL font issues you mentioned become less of an issue as more people embrace Qt. Chrome presumably has figured it out simply because so many people are reliant on it working. If more people embraced Qt, they'd fix the hard parts as they would have more investment.
Have you ever done the math on what developer time costs? Even if Qt looks very expensive, it is cheap when you take that into account (not to speak of the savings in Qt and post-release bugfixes).
The 11 months old version is opensourcenand nice. The current version is for customers only. That is their current business strategy to fulfill nthe KDEnagreement, while trying to survive as business, which seems to be tough for them.
The current version (6.3, just released) is free and open source.
You must be confused with the LTS which is the commercialy supported version. And yes, if you want a commercially supported version, you have to pay. Isn't that normal?
Many complaints are around about how QT isn’t FOSS, licensing is costly, etc. is everyone happy with its performance as a product and framework, though?
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?
I've used Qt for several desktop apps, both using Widgets and QML; I never used the python bindings, always used the C++ libraries directly.
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.
Not the OP, but Dart, although basically a 90's Java clone, is still superficially different enough that it needs to be learnt - so where's the payoff? It doesn't fix most of Java's issues: pervasive mutability, boilerplate, a kingdom of nouns, Tony Hoare's billion dollar mistake etc. There are many better Java++ languages out there; and this includes the roadmap for Java itself (pattern matching, sealed classes, data classes, fibers etc).
Some fair points here. The differences that I've experienced have generally seemed very positive and it feels like significantly less boilerplate than Java.
As for Tony Hoare's billion dollar mistake, I'm not sure if you've seen the information about Sound Null-Safety[1], but it's actually one of my favorite features about the language. Static analysis in Dart feels a little bit like Rust in that as you write code your IDE can provide smart suggestions and bugs are often found as you write instead of when you compile.
Finally, I'll take the pub.dev[2] toolchain and build system over anything out there today besides Cargo. Plus, compiling to a single executable file without any dependencies that have to be installed on the deployment target is great.
"There are many better Java++ languages out there."
Any in particular you'd suggest? I'd definitely give it a shot if it blows Dart out of the water!
Ok, it looks like they've now retrofitted null safety, but why wasn't it designed in from the start? I can't help but feel this was always a Java-clone to avoid litigation, not any kind of innovative project.
Kotlin looks like a good Java++ language (especially for Android); and Typescript would be the most pragmatic choice for web. But again, Dart is going to have to keep up even with modern Java.
Regarding boilerplate, can Dart define a simple data class with equals and hashcode in one or two lines?
I think you'll find that in many ways that today's Dart is very different from the earlier iterations people experienced in 1.x. You're right it wasn't designed in from the start, but I couldn't possibly say why. I can say it doesn't feel bolted on and it's definitely the default for all Dart code I've seen recently in the wild. Kotlin is certainly nice to write in, but all else being equal, if I can avoid the JVM and get easy AOT compilation, deployment, and distribution I'll take that every time. Typescript transpiles to JS, same as Dart, so that just seems like extra steps, but there are clearly advantages to sticking with regular JS frameworks over Flutter for the moment, so I won't argue that point. I'm really just talking about Dart here.
Frankly, I haven't needed to implement such a basic data structure myself in Dart, but here's a whole book of examples of implementing common data structures[1]. They look pretty straight forward to me. You can also take a look at the Dart language tour.[2]
Pretty much this. It has nullable types now, but it's still a meh java clone.
On the plus side, I wouldn't say it really needs to be learned if you know Java (and maybe Kotlin or Swift, so that you are used to the ? operator). I wrote a couple of apps in Flutter, having never read even a single line about Dart. I picked it up by looking at the Flutter examples.
One particularly annoying thing is that a whole lot of stuff is achieved through code generation (serialization, equality operators, ORM mapping, localization among others), and there are so many different way that code generation can be done - some automatic during the build, some that must be manually invoked. The build system seems really lacking.
It really confuses me how anyone would have anything good to say about QML. Qt taking that direction just seems like a panicked decision to try and compete with Electron when they should really be doing the exact opposite.
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.
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.
Technically, you don't have to. But is that not what you are really supposed to be doing? Who wants to write a Quick app without QML? That would be incredibly painful, I think.
And unless I'm mistaken, if you're doing anything with JavaScript, that's all defined in QML. I don't think there's a way around that, unless I'm mistaken. And often times you need JS to achieve certain things in the separate memory space where the Quick widget is being executed. What that means is that there's a wall between Quick and C++ even if you are instantiating Quick widgets from C++.
While Quick widgets technically share memory space with the rest of the app code, any sort of UI behavior is expected to be handled by JavaScript, which doesn't run in the same memory space, and of course it's not going to in any case because it's not C++. So when data is shared, it has to be type converted, which can become a problem if you even slightly wander off the beaten path:
If you could elaborate on why I'm wrong, I'd certainly appreciate it. It's been about 3 months since I decided to entirely ditch anything involving Quick/QML, so I could be easily misremembering aspects of it.
In no way am I saying that someone shouldn't use Quick if they find that it works well for them. I find Quick's argument versus nearly all alternatives to be lacking. The primary argument against Electron is that it's bulky, and I think that's absolutely the case. The argument for Electron, however, is using the full web stack, which everyone knows how to use, and if you need performance to use WASM and workers, and that makes a lot more sense to me than something that even most C++ devs aren't familiar with that still forces you into dealing with all of Qt's compiler quirks.
I built an editor for creating visualisations for an LED grid hardware project. The editor was built in QML (but with lots of C++). It had a grid visualising the LEDs as squares (I believe that was drawn, iirc, not using QML rectangles) And a timeline track editor where you could place effects (four tracks), drag them around, drag their length, select effects to edit their properties in a properties label etc.
Whole thing was built in about 3 days and I would say it was a huge success (visualisation crested with it was used at a gig of about 1.2k attendees and creating the editor meant being able to iterate quickly to create a visualisation the musicians were happy with, LEDs were attached to clothing). I certainly enjoyed the experience.
Doing it in Qt meant that I could write C++ code to “run” the visualisation, but with a different display implementation (editor version drew to the editor, hardware version outputted to the LED hardware, but the track runtime was the same code). QML made building the UI easy.
Nowadays I mainly do React-based web UI’s, but I still much prefer QML to html/react/css. I especially miss QML’d anchors for layouts.
Thanks for providing an opposite opinion! I don't suppose there's video, photos, or code of your project? No worries if you don't. Just sounds really cool!
I'm not the parent, but I did something similar. It's an editor for fractal flames where the UI is done in QML and rendering and generation is done in C++ and OpenGL. https://github.com/chaoskit/chaoskit
I liked that QML allowed me to iterate quickly on the UI. It was really quick to just compose a bunch of components together and have something working. I also enjoyed the integration with the C++ side. Overall I found QML pretty solid. If I'd build a desktop app again, I'd definitely consider it.
I have the code on GitHub but I haven’t built the code in 4 years so don’t have a screenshot. Like I said, the code was written in about 3 days and QML allowed me to iterate quickly, but the resulting code quality isn’t great (since it was a once off project, built and used in the same week and then never used again, I didn’t clean it up or anything).
The editor simulated the LED strip using the same code to generate the effects as the on device version (which just ran without the UI and a different “driver” class implementation). It ran on a Raspberry Pi so the device wasn’t a microcontroller or anything, which made it easy to run the C++ code. In theory I could have made it run in a microcontroller but it wasn’t necessary for the project and time was limited.
If I were to clean it up, I would at least split the different labels into their own QML files but hey, shortcuts were taken over those few days :)
Visually, it didn’t look all that great, but I’m not a UI person either and it was rushed. Functionally it could have been improved too, but it did what it was supposed to and it worked well. It allowed us to create various LED effect sequences quickly and play them back later.
I personally quite like QML. It’s not perfect, by any means, but I like using it more than React (which is what I’ve been using on projects since due to needing to be web based).
Qt 4.7 (in 2010) is older than electron (2013), how could it be a panicked decision ?
Also, there's nothing wrong with using Qt Quick from C++, or using QML without Qt Quick at all. what matters is your project, not what whatever best practices say.
No, on mobile it was an absolute disaster, our entire mobile team quit rather than deal with it, it's hard to recruit new developers, it's a pain to maintain, it didn't deliver cross platform, it doesn't even deliver across one platform (Just make the customers buy iPads), it has a huge deliverable.
The only people who like it have not developed mobile and are just used to dealing with dependency hell and everything that goes with it and seem to think it's normal.
Have you ever developed a cross-platform application for desktop or embedded? It's quite a challenge, especially if there's GUI involved. Qt makes that a breeze.
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).
Qt on iOS is expensive. Apple requires a static build^, and Qt static build requires a commercial license.
Qt saw this paradox and declared that iOS builds don't count as "embedded" builds, so you can deploy with a desktop license and not pay the exorbitant per-device vig. But it's still non-zero.
^(yes, you can do it dynamically, but you can't use GPL because users can't replace the dynlibs. So you're static whether you like it or not)
If you statically link against an LGPLed library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application.
Now, for mobile apps "providing your [proprietary] application in an object format... so that a user has the opportunity to modify [Qt] and relink" might be challenging/impossible, e.g. given the nature of the iOS platform.
However, what I've found is that many devs believe that Qt static builds (for proprietary apps) are not allowed in general by the LGPL, and that's simply not true per the FSF's own FAQ. Qt's docs/marketing don't help in this regard (in my experience).
The example I was talking about was specifically regarding a Qt app built for iOS.
An end customer cannot modify and/or relink the Qt libraries inside because Apple doesn't allow it through the App Store signing mechanisms.
I agree, Qt docs/marketing regarding licensing are a complete shit-show, and a solid reason why I don't recommend them anymore when I show up in a new organization. And I've been a Qt developer since the version 2 days. It's just too hard to negotiate and explain to management anymore, and the new lean towards a subscription model makes it even worse.
I don't think 'QT makes that a breeze' is true for anything but the most simple of UIs on mobile. It seems to work better for desktops I'll admit, but just seems grossly underprepared for anything smaller than a desktop screen that isn't embedded. (Although I personally really dislike QT interfaces on a mac)
Literally any other cross platform mobile solution is better, possibly the fact that QT tries to stretch itself across mobile and desktop is why it is so frustrating to work with on mobile. The apps tend to come out like desktop apps someone did their very best to shrink down
And while i think about it, the more it annoys me.
I think the only way we can get away with using it is because noone has any choice, if anyone launched an app using native in our field, any qt app is at an instant disadvantage. The qt team worries that an new ios release happened while i’m looking at the release notes and docs looking for things to use to our advantage
A while back I worked on a Qt 5 code base and a another with QML.
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.
> positioning each gadget manually, coding XML, using visual GUI designer
Yes, I have only done manual position. My programs are not that big yet. Some gadgets are not always feature complete, thus sometimes you need to write custom code (like for special events) for each platform or use a canvas. Drawback with canvas is that you need to write it dpi aware thus making it a bit more complex.
GUI for Windows is the old Windows look (win32), not the new modern one.
That is why I was bit excited with a Sciter integration, now you have the possibility to write complex GUI ("modern") with Sciter and classic GUI with PureBasic or a combination.
XML layout, there is some critique against it not being DPI perfect. You can read about it in this thread
Form Designer - popular but to my understanding starts showing some limitations when you start getting multiple windows (handling of identifiers of windows/gadgets). And if the form designer has a default that you can't change then of course you need to change that value manually every time you update your form by the form designer.
To my knowledge there exist two commercial alternative to the built in form designer, PureVision (old) and IceDesign (new).
macOS - I'm not a mac user so I can't tell, but I do know there is frequent mac discussions on the forum. There have been some excitement around the new coming PureBasic 6 release with a new C backend, making it possible to compile to native code for the M1 processor.
Absolutely, I think that the QGraphicsItem canvas-ish API is much simpler for what I need (a lot of custom drawing); QGraphicsScene also has some very useful functions that QtQuick is missing (getting all the items z-ordered at a given x, y position IIRC? Don't remember exactly but I wanted to try to do a port one day and missed a bunch of critical ones... That was 4 or 5 years ago though). And QQuickPaintedItem was too slow for my needs when I had tested it, much slower than QGraphicsItem for large amounts of items. With the OpenGL backend of QPainter the UI is plenty fast even on 4k screens (but even without it it's fine honestly).
What I would really like to see would be a QRhi-based QPainter implementation for things to be future proof but I understand it's a non-trivial task at all.
Also, even though QML is very nice for projects with more or less fixed UIs, for very dynamic things I find it to be more unwieldy; I reach for it for mobile and embedded without hesitation but for "traditional" authoring desktop apps I'm generally faster to develop with QWidgets/QGraphicsScene in C++.
Python QT5 user here. I'm yet to find a better / faster way to build an interactive GUI for a simple desktop application for Python.
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.
The biggest issue for me was that you have to update widgets from the gui thread. Doing it from other threads still works most of the time, but then you sometimes get weird unpredictable crashes.
Am I crazy to think Gtk4 is now a viable cross-platform alternative to Qt?
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.
So you're not even going to do enough homework to see if you've got anything to be upset about here? You're just going to shout your requirements into the wind?
As far as I can tell, GTK 4 is still only accessible on free Unixes, via AT-SPI. There doesn't seem to be any progress in making it accessible on Windows or Mac.
Honestly I am confused by the reactions here -- everyone wants FREE and GREAT and also calls the company management bad names? Some say that danger is not in the path forward, but instead the arrows shot in the back from behind (!) I see that here.. People that have only written mobile, ever, complaining that mobile is not what they expected; people want cross-platform, pixel perfect AND free-no-money and somehow this company employees people ? and etcetera .. suffocating, petty really..
I agree with that is very dominant culture among programmers that they want things for "free" and not pay anything to everyone that have worked hard on it.
Myself I have zero problems paying for software if it is good. My problem with Qt is that it isn't worth my money.
I've noticed that a few times with people pretending to care about open source but in reality they care mostly about the free as in free beer part.
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.
> everyone wants FREE and GREAT and also calls the company management bad names?
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.
Sure and i'd rather see people contribute more to wxWidgets as i prefer it to Qt myself (in that if i really had to choose between the two i'd go with wx), but that is not really relevant in the topic of criticizing the Qt Company's practices.
I understand the confusion, but it makes sense if you look at the history. Qt was initially released by Trolltech into the open source community. There has been some acquisitions and the reason people are on edge about Qt removing open source support is because it’s initial foundation was laid by contributions of the open source community. Several fantastic applications and even linux distributions have used Qt as their primary GUI framework for years. There are commercial licensing available for closed-source projects that would permit a company to use Qt in proprietary software. There have been talks in the past of making the framework entirely closed source, but this was met with instant push back from the community that has made countless major contributions to Qt and implemented countless applications using the framework.
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.
The Qt Company deserves the names they get called. Their licensing model for Qt is designed by complete shitheads and is engineered to mislead, frustrate, and ultimately bleed money from you in perpetuity. If your company is large enough to have lawyers, they will imply a threat of legal action to get you to pony up for their useless commercial licensing as soon as they catch wind that you're using the library under LGPL. This is such a fundamental part of their business model that you can't even use their installer any more without providing an email with which they can ask you about whether or not you're breaking the terms of their license.
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.
Is GNOME/Wayland compatibility any better? Qt5 applications running in Wayland mode (as opposed to xcb fallback) has issues with window decorator, resulting in windows with missing shadows and other minor differences, as compared to GTK applications.
I recently started a hobby project because I was bored and built an Everything clone with Qt for Python as it doesn't run on linux and I was very surprised how straight forward and performant it is. Despite dealing with a lot of tabular data and Python it seems as fast as C++. Can't claim to understand the magic under the hood but it's very solid.
Can you describe your tooling for Qt with Python development? I've tried to get started a few times but there were some licensing trip ups etc and a lot of different tools on the QT website.
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.
for the python environment I use poetry which I think works well (https://python-poetry.org/). As for the licensing (and someone correct me if this is wrong), you have the option to go with PyQt which is GPL licensed and will require you to open source your code, if you go with PySide which is LGPL licensed you do not (unless you make modifications to the Qt code itself which I suppose you're not). So the latter is the better option if you just want to distribute an app.
You don't need to use Qml at all and can use QtWidgets instead which is just their traditional toolkit, or you can combine both. I tried Qml for parts of the UI and it's fairly straight forward.
I think QtCreator supports python now so if you want a complete IDE with graphical tools that works well, I just used my normal editor.
You can use Nuitka [1] to compile your Python app. It's going to be fairly weak against someone trying to prise out your logic with a decompiler, especially since a lot of Python metadata is left in there (e.g. for generating stack traces), but good enough for most purposes, and unlike some "compilers" it does not have a hidden copy of the original Python buried in it.
If you use standalone mode (not onefile) then all the Qt DLLs and pyd files (which are basically also DLLs) are left separate, which lets you satisfy the LGPL.
Edit: The above is about deploying your app. For developing your app, feel free to use whatever flavour of the month pip wrapper you want (personally I'm still happy with vanilla virtualenv). You can assemble widgets and layouts into forms either using code or using UI files created in Qt Designer, just as in C++. I've not tried using QML.
for realtime applications with multiple threads, e.g. audio DSP, how does qt handle all the complexity with async stuff and messaging between threads without locking all over the place and how does it avoid excessive dynamic memory allocations?
my point is that there is an opportunity for a framework that solves all these problems out of the box.
you could argue that drawing text is not a problem that a framework should solve. yet they do, so there is no reason that a framework cannot solve the typical problems of audio applications and inter thread communication etc.
My own experience is with using QtWidgets in C++ for a multithreaded application that does some disk indexing and database management, the answer is "not that well".
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.
That is what I expected. These frameworks look nice, but were often not created with typical real world scenarios in mind but only work well for very simple data in/out applications where performance doesn't matter.
For audio DSP in a Qt app I have good success with using a lock-free queue (e.g. https://github.com/cameron314/readerwriterqueue) to communicate from / to the UI threads. Code more-or-less looks like
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 });
});
and conversely from the engine to the UI thread ; Qt signals do not cut it as emitting them allocate, if only a few bytes. (Doing it naively with std::function doesn't cut it either - I use this instead to store these functions: https://github.com/jcelerier/smallfunction/blob/master/small... ; also, the audio threads feeds back those functions into the main thread after their execution so that any memory owned by the lambda ends up being freed here and not in the audio thread.)
It’s easy to argue that all cross platform C++ GUI libraries suck, but Qt definitely sucks the least.
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.
I think I use two Qt apps regularly and both are related to my 3d printer. The slicer and CAD software.
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?
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.
That makes some sense but I don't think Qt is just the frame. TWhy use Qt if all you need is a frame window? Maybe they are drawing the Qt widgets on a browser canvas or something.
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.
I am just starting my journey with PyQt6 coming from React/Redux madness. I have a slew of questions if you don't mind me asking to more experienced PyQT developers on HN:
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?
Great UI framework, one of The best. And cross platform
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
129 comments
[ 3.9 ms ] story [ 215 ms ] threadAnd 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.
Edit: The KDE bit is wrong, I still stand by the first portion though.
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.
I work for a car company using Qt. The open source community around Qt is a significant contributor to the talent pool we hire from (myself included), and it is also a regular contributor to (and indirectly/broadly, the inspiration for) integration-related Qt modules (e.g. QtWayland) we like. Its health is important.
Plus the GPL version is good enough for the said developer to learn Qt if it happens to be out of cash.
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.
(To put a finer point on the specifics you mentioned: I believe they once had a policy of making the QML-to-C++ compiler available only to commercial customers, and not to FOSS users, treating it as something distinct from the 'core of Qt'. They later changed their minds on this. [0][1])
Presumably they could start work on a whole new toolkit, call it something other than Qt, and be free of the KDE agreement. This would no doubt be much more work than a typical major Qt release, but they do presumably have the option.
[0] https://www.qt.io/blog/the-new-qt-quick-compiler-is-coming-i...
[1] https://stackoverflow.com/questions/9448296/is-qml-translate...
Which part is not true? It all looks correct to me.
https://doc.qt.io/qt-6/licensing.html
The whole thing felt so fragile.
[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.
You must be confused with the LTS which is the commercialy supported version. And yes, if you want a commercially supported version, you have to pay. Isn't that normal?
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.
As for Tony Hoare's billion dollar mistake, I'm not sure if you've seen the information about Sound Null-Safety[1], but it's actually one of my favorite features about the language. Static analysis in Dart feels a little bit like Rust in that as you write code your IDE can provide smart suggestions and bugs are often found as you write instead of when you compile.
Finally, I'll take the pub.dev[2] toolchain and build system over anything out there today besides Cargo. Plus, compiling to a single executable file without any dependencies that have to be installed on the deployment target is great.
Any in particular you'd suggest? I'd definitely give it a shot if it blows Dart out of the water![1]: https://dart.dev/null-safety
[2]: https://pub.dev/
Kotlin looks like a good Java++ language (especially for Android); and Typescript would be the most pragmatic choice for web. But again, Dart is going to have to keep up even with modern Java.
Regarding boilerplate, can Dart define a simple data class with equals and hashcode in one or two lines?
Frankly, I haven't needed to implement such a basic data structure myself in Dart, but here's a whole book of examples of implementing common data structures[1]. They look pretty straight forward to me. You can also take a look at the Dart language tour.[2]
[1]: https://www.raywenderlich.com/books/data-structures-algorith...
[2]: https://dart.dev/guides/language/language-tour
On the plus side, I wouldn't say it really needs to be learned if you know Java (and maybe Kotlin or Swift, so that you are used to the ? operator). I wrote a couple of apps in Flutter, having never read even a single line about Dart. I picked it up by looking at the Flutter examples.
One particularly annoying thing is that a whole lot of stuff is achieved through code generation (serialization, equality operators, ORM mapping, localization among others), and there are so many different way that code generation can be done - some automatic during the build, some that must be manually invoked. The build system seems really lacking.
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.
No, you don't.
And unless I'm mistaken, if you're doing anything with JavaScript, that's all defined in QML. I don't think there's a way around that, unless I'm mistaken. And often times you need JS to achieve certain things in the separate memory space where the Quick widget is being executed. What that means is that there's a wall between Quick and C++ even if you are instantiating Quick widgets from C++.
While Quick widgets technically share memory space with the rest of the app code, any sort of UI behavior is expected to be handled by JavaScript, which doesn't run in the same memory space, and of course it's not going to in any case because it's not C++. So when data is shared, it has to be type converted, which can become a problem if you even slightly wander off the beaten path:
https://doc.qt.io/qt-5/qtqml-cppintegration-data.html#conver...
If you could elaborate on why I'm wrong, I'd certainly appreciate it. It's been about 3 months since I decided to entirely ditch anything involving Quick/QML, so I could be easily misremembering aspects of it.
In no way am I saying that someone shouldn't use Quick if they find that it works well for them. I find Quick's argument versus nearly all alternatives to be lacking. The primary argument against Electron is that it's bulky, and I think that's absolutely the case. The argument for Electron, however, is using the full web stack, which everyone knows how to use, and if you need performance to use WASM and workers, and that makes a lot more sense to me than something that even most C++ devs aren't familiar with that still forces you into dealing with all of Qt's compiler quirks.
Whole thing was built in about 3 days and I would say it was a huge success (visualisation crested with it was used at a gig of about 1.2k attendees and creating the editor meant being able to iterate quickly to create a visualisation the musicians were happy with, LEDs were attached to clothing). I certainly enjoyed the experience.
Doing it in Qt meant that I could write C++ code to “run” the visualisation, but with a different display implementation (editor version drew to the editor, hardware version outputted to the LED hardware, but the track runtime was the same code). QML made building the UI easy.
Nowadays I mainly do React-based web UI’s, but I still much prefer QML to html/react/css. I especially miss QML’d anchors for layouts.
I liked that QML allowed me to iterate quickly on the UI. It was really quick to just compose a bunch of components together and have something working. I also enjoyed the integration with the C++ side. Overall I found QML pretty solid. If I'd build a desktop app again, I'd definitely consider it.
The editor simulated the LED strip using the same code to generate the effects as the on device version (which just ran without the UI and a different “driver” class implementation). It ran on a Raspberry Pi so the device wasn’t a microcontroller or anything, which made it easy to run the C++ code. In theory I could have made it run in a microcontroller but it wasn’t necessary for the project and time was limited.
Anyway, the code is here: https://github.com/danielytics/ledstudio
And the QML specifically is here: https://github.com/danielytics/ledstudio/blob/master/main.qm...
If I were to clean it up, I would at least split the different labels into their own QML files but hey, shortcuts were taken over those few days :)
Visually, it didn’t look all that great, but I’m not a UI person either and it was rushed. Functionally it could have been improved too, but it did what it was supposed to and it worked well. It allowed us to create various LED effect sequences quickly and play them back later.
I personally quite like QML. It’s not perfect, by any means, but I like using it more than React (which is what I’ve been using on projects since due to needing to be web based).
Also, there's nothing wrong with using Qt Quick from C++, or using QML without Qt Quick at all. what matters is your project, not what whatever best practices say.
It's finally matured into a usable system now that application processor horsepower has caught up in the embedded field. It only took 12 years.
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).
Qt saw this paradox and declared that iOS builds don't count as "embedded" builds, so you can deploy with a desktop license and not pay the exorbitant per-device vig. But it's still non-zero.
^(yes, you can do it dynamically, but you can't use GPL because users can't replace the dynlibs. So you're static whether you like it or not)
https://www.gnu.org/licenses/gpl-faq.en.html#LGPLStaticVsDyn...
Now, for mobile apps "providing your [proprietary] application in an object format... so that a user has the opportunity to modify [Qt] and relink" might be challenging/impossible, e.g. given the nature of the iOS platform.However, what I've found is that many devs believe that Qt static builds (for proprietary apps) are not allowed in general by the LGPL, and that's simply not true per the FSF's own FAQ. Qt's docs/marketing don't help in this regard (in my experience).
I agree, Qt docs/marketing regarding licensing are a complete shit-show, and a solid reason why I don't recommend them anymore when I show up in a new organization. And I've been a Qt developer since the version 2 days. It's just too hard to negotiate and explain to management anymore, and the new lean towards a subscription model makes it even worse.
Literally any other cross platform mobile solution is better, possibly the fact that QT tries to stretch itself across mobile and desktop is why it is so frustrating to work with on mobile. The apps tend to come out like desktop apps someone did their very best to shrink down
I think the only way we can get away with using it is because noone has any choice, if anyone launched an app using native in our field, any qt app is at an instant disadvantage. The qt team worries that an new ios release happened while i’m looking at the release notes and docs looking for things to use to our advantage
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.
Yes, I have only done manual position. My programs are not that big yet. Some gadgets are not always feature complete, thus sometimes you need to write custom code (like for special events) for each platform or use a canvas. Drawback with canvas is that you need to write it dpi aware thus making it a bit more complex.
GUI for Windows is the old Windows look (win32), not the new modern one.
That is why I was bit excited with a Sciter integration, now you have the possibility to write complex GUI ("modern") with Sciter and classic GUI with PureBasic or a combination.
XML layout, there is some critique against it not being DPI perfect. You can read about it in this thread
https://www.purebasic.fr/english/viewtopic.php?t=71146
Form Designer - popular but to my understanding starts showing some limitations when you start getting multiple windows (handling of identifiers of windows/gadgets). And if the form designer has a default that you can't change then of course you need to change that value manually every time you update your form by the form designer.
To my knowledge there exist two commercial alternative to the built in form designer, PureVision (old) and IceDesign (new).
macOS - I'm not a mac user so I can't tell, but I do know there is frequent mac discussions on the forum. There have been some excitement around the new coming PureBasic 6 release with a new C backend, making it possible to compile to native code for the M1 processor.
What I would really like to see would be a QRhi-based QPainter implementation for things to be future proof but I understand it's a non-trivial task at all.
Also, even though QML is very nice for projects with more or less fixed UIs, for very dynamic things I find it to be more unwieldy; I reach for it for mobile and embedded without hesitation but for "traditional" authoring desktop apps I'm generally faster to develop with QWidgets/QGraphicsScene in C++.
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.
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.
Accessibility is the hill virtually every FOSS UI cross-platform toolkit dies on.
Dream solution is having a nix flake setup with correct compiler selection and switches for Windows/Linux/Mac and Android.
Myself I have zero problems paying for software if it is good. My problem with Qt is that it isn't worth my money.
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.
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.
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/company
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.
[1]: https://code.qt.io/cgit/qt/qtreleasenotes.git/about/qt/6.3.0...
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.
You don't need to use Qml at all and can use QtWidgets instead which is just their traditional toolkit, or you can combine both. I tried Qml for parts of the UI and it's fairly straight forward.
I think QtCreator supports python now so if you want a complete IDE with graphical tools that works well, I just used my normal editor.
If you use standalone mode (not onefile) then all the Qt DLLs and pyd files (which are basically also DLLs) are left separate, which lets you satisfy the LGPL.
[1] https://nuitka.net/
Edit: The above is about deploying your app. For developing your app, feel free to use whatever flavour of the month pip wrapper you want (personally I'm still happy with vanilla virtualenv). You can assemble widgets and layouts into forms either using code or using UI files created in Qt Designer, just as in C++. I've not tried using QML.
https://www.voidtools.com/
you could argue that drawing text is not a problem that a framework should solve. yet they do, so there is no reason that a framework cannot solve the typical problems of audio applications and inter thread communication etc.
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.
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.
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?
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.
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.
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!
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.
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