Just wanted to let you know it's not all gray in Qt land.
The open-source Qt is licensed under LGPL. It's not really a mystery. I've built a proprietary app[1] on top of that, and as I explained in my blog post[2], the LGPL allows you to statically link your executable as long as you provide the object files and allow users to relink your app with a different version of Qt.
There's also a lot you can do to drastically limit your binary size. I wrote a little about it on my blog post but haven't experimented that much with it yet. Things like:
1. Compiling Qt from source with only the specific modules needed and using static linking.
2. Use the -optimize-size flag and Link Time Optamization flag -ltcg.
3. Running strip on the resulting executable to remove unused symbols.
4. Use UPX to compress the executable.
BTW, Qt can look very native, if you know how to use it properly (I wish to make it more commoditized!), for example, something I'm cooking at the moment:
Heavy Qt user here... I agree with everything you said. I think a lot of people are rightfully confused about the licensing because I think the Qt Company is vague about it on purpose, they want to sell licenses of course. I just hope their agreement with KDE never ends.
I also think that the vast majority of people that complain about the lack of "native look" are bad takes from people that don't actually ship apps professionally and listen to their customers. End-users don't actually care and it really simplifies things a lot to do it the way they are. wxWidgets uses platform native APIs and I would argue that it looks much worse (and old) compared to Qt.
One thing I will say though is that the fact that Qt specifically now uses LGPL version 3 as opposed to v2 (switched in 5.6 I think), can actually be quite significant and a non-starter for some people. If you're developing something where Qt is embedded fairly deep in to the system, especially if it's a critical system, you don't want to have to give the user the ability to swap out your Qt library with who-knows-what and now all your safety testing/validation/warranties etc. are void... which I guess for bigger companies they just buy a commercial license in that case.
> I think the Qt Company is vague about it on purpose, they want to sell licenses of course. I just hope their agreement with KDE never ends.
Yep, I agree. And I hope so too.
> I also think that the vast majority of people that complain about the lack of "native look" are bad takes from people that don't actually ship apps professionally and listen to their customers
Ding ding ding. Exactly. I would argue that most Qt developers aren't targeting the same audience that native iOS developers target, for example, which causes all Qt apps in the wild to look embarrassingly ugly and out of place. The Qt Company's own lack of taste in design (and their examples) doesn't contribute. It's only when developers with a strong taste for aesthetics and for creating experiences that delights people will take on Qt to develop apps, we will see and be able to show the world the power of Qt. I hope to be part of this change, I'm trying to push Qt limits with every new app I make. And honestly, QML is just an amazing joy to program in. Here's a cool window animation you can do in 1 minute using QML:
What we also need is to create a set of beautiful, easy to use components that work out-of-the-box for developers to tinker with. This is very lacking in the Qt ecosystem compared to other frameworks.
The gist I'm trying to get at is that Qt is not the limiting factor, the limiting factor are developers whose both their target users don't care about aesthetics (or so they think), and developers who themselves lack a good taste (or the know how) for good design.
Not sure about the difference between LGPL v2 and v3, but like you said, if you're a big company, paying for the license is a non-starter (and also helps fund Qt development so why not?), but for almost all developers the LGPL version should be more than enough.
Developing apps with Qt and QML is super easy these days. I wrote a post about my experience[1]. QML is such a joy to program the UI in, and then you can use a compiled language–C++/Rust/etc for amazing performance gains. Also, most Qt Quick components (those exposed via QML) are written in C++, so using these native components means that even working with these abstractions is very performant.
I've built my app[1] using Qt (C++ and QML), and I think the UI looks decent. There's still a long way for it to feel truly native, but I've got some cool ideas.
You are probably not solving the same problems many other people are facing.
Many such applications are accessible on the web, often with the exact UI. They may even have a mobile/iPad version. They may be big enough that they have a design system that needs to be applied to in every UI (including company website). Building C++ code on all platforms and running all the tests may be too expensive. The list goes on.
I just started prototyping a mobile version of my app (which shares the code as my desktop app) and the result looks promising (still work-in-progress tho).
Offering a web app is indeed not trivial. Maybe Qt WebAssembly will be a viable option if I can optimize the binary and users wouldn't mind first long load time (and then the app should be cached for instant load). Or maybe I could build a read-only web app using web technology.
Currently, my focus is building a good native application, and I think most of my users care about that. But in the future, I can see how a web app could be useful for more users. One thing I would like to built is a web browser that could load both QML and HTML files (using regular web engine), so I could simply deploy my app by serving my QML files without the binary over the internet.
Thank you! I think Qt is absolutely great. One need to put a little effort to make it look and behave nicely. I wrote a blog post about it[1], if you're interested.
I wrote about my journey developing a block editor (a la Notion) from scratch in Qt C++ and QML.
Flutter seems to gain quite a lot of popularly lately, but I wanted to show that Qt can also be a performant and efficient alternative to web apps deployed on desktop (via Electron, etc).
You can clearly see in the benchmarks how much more efficient my block editor is compared to existent solutions and how far behind web apps are.
I also tried to stress how, with enough effort, one can create a Qt app that looks and behave similarly to a native app.
When I try to design a beautiful thing, it starts with beauty that convey meaning, function. While visually appealing by itself is nice, it's always the function, the meaning of interaction that should come first. Some examples I've shared in the blog post:
1. Drag and drop → https://rubymamistvalove.com/blog/drag_and_drop_internal.mp4 - the dragged items simply pop from their place and the rest of the items make room for it. This is an intuitive design that makes a lot of sense for end users.
2. Selecting multiple notes shows cards stack → https://rubymamistvalove.com/blog/cards_stack.mp4 - while visually appealing, it also conveys the action the user performs (similarly to how macOS Mail does the same).
It's been 1 year of development since I started this. Would love to hear your thoughts.
Awesome! Would love to hear your thoughts. Any progress on your AI client? I'm intrigued by the so many bindings to Qt. Recently, I got excited about a Mojo binding[1].
Very much agree. I made a cross-platform and open-source note-taking app[1] in Qt C++ but never really talked to common end users and their needs, just built for myself.
Now that I'm working on a proprietary version[2] (with a block editor I rewrote from scratch), I'm talking to these end users and understand their frustration in using my product. For example, many users had issues discovering the different features of the app, so I created a toolbar, which much helped. This is just one example.
I wrote about my journey developing a block editor (a la Notion) from scratch in Qt C++ and QML.
I wanted to prove that Qt can be a performant and efficient alternative to web apps deployed on desktop (via Electron, etc).
You can clearly see in the benchmarks how much more efficient my block editor is compared to existent solutions and how far behind web apps are.
I also tried to stress how with enough effort, one can create a Qt app that looks and behave similarly to a native app.
When I try to design a beautiful thing, it starts with beauty that convey meaning, function. While visually appealing by itself is nice, it's always the function, the meaning of interaction that should come first. Some examples I've shared in the blog post:
1. Drag and drop → https://rubymamistvalove.com/blog/drag_and_drop_internal.mp4 - the dragged items simply pop from their place and the rest of the items make room for it. This is an intuitive design that makes a lot of sense for end users.
2. Selecting multiple notes shows cards stack → https://rubymamistvalove.com/blog/cards_stack.mp4 - while visually appealing, it also conveys the action the user performs (similarly to how macOS Mail does the same).
It's been 1 year of development since I started this. Would love to hear your thoughts.
First of all, I wrote a block editor in QML[1] (the model in C++) that far outperform QTextEdit (part of Qt Widgets) at loading, scrolling and word-wrap resizing of very large documents (think, War and Peace) *with* the additional cost of being a block editor that can include a Kanban board, images, etc. So saying QML isn't performant is incorrect.
Secondly, my knowledge about the internal build tools such as qmltc, qmlcachegen, and qmlsc is quite limited, but isn't qmlcachegen also compiles QML documents[2]? And don't forget that the built-in Qt Quick components are either compiled to C++ or written natively in C++.
Your app looks really nice, I like the smooth animations in the web demo. A benefit of QML is that more of the rendering is done on the GPU, so the performance may differ depending on hardware.
qmlcachegen produces only bytecode, not compiled code.
I used to earn passive income from its previous version, which is open source and is now a different project[1] by having ads on the website. It wasn't much but around $2000 a month semi-consistently across 5 years (sometimes more, sometimes less). A lot of traffic is coming from Google searches 20k-60k monthly (it varies). With Daino Notes I was hoping to focus on subscription more but since paid subscription isn't quite growing as much as I anticipated (although usage is quite high), I reenabled ads again. It doesn't quite cover the bills these days so I'm thinking about getting a job (if you know someone, HMU).
> Do you have some hints as to how you accomplished that with QML?
I'll publish a detailed blog post about the entire development journey very soon. You can hit me up on X (@mamistvalove) or Discord (@rubymamis) and I can send you a draft, if you like.
The open-source Qt is licensed under LGPL. It's not really a mystery. I've built a proprietary app[1] on top of that, and as I explained in my blog post[2], the LGPL allows you to statically link your executable as long as you provide the object files and allow users to relink your app with a different version of Qt.
There's also a lot you can do to drastically limit your binary size. I wrote a little about it on my blog post but haven't experimented that much with it yet. Things like: 1. Compiling Qt from source with only the specific modules needed and using static linking. 2. Use the -optimize-size flag and Link Time Optamization flag -ltcg. 3. Running strip on the resulting executable to remove unused symbols. 4. Use UPX to compress the executable.
BTW, Qt can look very native, if you know how to use it properly (I wish to make it more commoditized!), for example, something I'm cooking at the moment:
Windows: https://imgur.com/8lT0u24
macOS: https://imgur.com/a/GKWSDaK
[1] https://get-notes.com
[2] https://rubymamistvalove.com/block-editor#10-qt-license
reply