Do these "modern" UI toolkits not have visual editors for knocking up the UI anymore?
One of the strengths of Qt based UIs is that the framework has IDE like tools where creating UIs is just a matter of drag and dropping the UI widgets into a layout. No need to write code by hand. Both QtCreator and QtDesigner can support this workflow.
Secondarily this comparison table has several problems when it comes to Qt.
* Their license is dual license LGPL *and* commercial.
* Minimum binary size is definitely not 20MB but less. In general your apps distribution size depends on which features of the toolkit you're using.
* Comparing "Syntax Highlighting" makes no sense... QSyntaxHighligther is an interface by which you can add your own syntax highlighting to any QDocument. You're welcome to use reg exps, parsers (such as tree-sitter) or whatever you want there.
* QRichText supports markdown such as HTML.
They do, but you have to look into the right ones, from ex-Qt employees,
https://slint.dev/
You can make use of Figma integration for something similar to Qt Design Studio.
Too many folks nowadays don't seem to fully understand how powerful GUI designers for native code used to be.
You always get some arguments about pixel perfect positioning, completly ignoring the fact most of them had layout managers available, even VB pre-VB.NET (yes Windows Forms does support layout managers).
The thing that irks me about slint is the use of the more restrictive GPLv3-only which prevents it from being incorporated into a project which is licensed GPLv3-or-later. I don't get why it is done like that.
GPLv4 could be the MIT license. GPLv3-or-later is a statement of arbitrary trust towards the FSF. Corporations serious about licensure, like SixtyFPS, aren't fans of that. (I don't think I've ever seen GPLv3-or-later in the wild from non-GNU/FSF software.)
GPLv3-or-later is pretty commonplace in the world of free software even outside of GNU stuff.
Easy, similar to Qt.
Don't want to pay upstream? Also don't get to charge money.
Want to pay up stream? Another license can be arranged where both parties get to earn money.
Qt is LGPL 3. Slint is GPL 3. There is a massive difference there for a “library “
But to be fair to Slint, they do have a free proprietary license which can be used for developing proprietary applications as long as it’s not considers in the “embedded” space.
I think you misread the post you're replying to. GP is complaining about it being incompatible with "GPLv3-or-later" Free Software, not with commercial or permissive OSS.
Yes, and being incompatible with GPLv3-or-later may be done on purpose to push folks into a commercial license.
GPLv3-or-later is currently almost the same as GPLv3-only at the moment given there is no GPLv4.
The reason why it's not possible to include GPLv3-only code in a GPLv3-or-later codebase is that the latter is more permissive, allowing the FSF to release an updated version of the GPL.
They won't make GPLv4 any less copyleft and more permissive than GPLv3, if they ever do make one. At worst, the GPLv4 will cause some commercial user of the code to be even more inconvenienced.
You can freely charge money with either GPLv3-only or GPLv3-or-later.
I am not asking them to remove GPLv3-only and replace it with MIT, I am asking them to use GPLv3-or-later.
> * Minimum binary size is definitely not 20MB but less. In general your apps distribution size depends on which features of the toolkit you're using.
In my experience that point is absolutely correct. Qt is good but big. You usually end up with 30-40MB of it.
Core, Gui, QML, Widget are 8MB each. For a Hello World you need 3 of those. Maybe 2.
Yes you could build Qt yourself with various flags, or possibly do a static build with LTO might help. But that's not the typical way Qt is used.
Yes and no.
I just checked against Qt5 on ArchLinux. Core, GUI and Widget .so are all about 6mb each.
I concede that it's closer to 20mb after all but at the same time it's not a fair apples to apples comparison because those libraries provide you with so much more functionality than just the UI.
> because those libraries provide you with so much more functionality than just the UI.
Comparing GPUI to Qt based only on what they offer gui-wise is fair, in my opinion. What QtCore provides is sugar over C++: the object model, the signal system, some data types, many helpers. But the thing is, all of those things are in Rust already. They're even in modern C++.
So comparing a Qt hello world that uses QtCore+QtGUI+(QtQML|QtWidget) to a Rust GPUI hello world seems fair to me. It's not like the author also counted QtNetwork, QtSQL, QtSVG, QtHTML, etc.
I would think you could absolutely create something like that with a few steps on top of a relatively complete component library like linked.
You would probably want an xml/markup representation of component hierarchies, similar to other efforts, this can work with Rust with a macro interface that replaces the render hierarchy with the component structure format of this library. From there, you would need an application to hot-mount the same markup "live" as part of an interactive design tool.
In the end it wouldn't be much different than Glade, XAML or QT Designer. That said, you have to build a foundation before you can put solar panels on the roof.
This is just meant to show how awesome their toolkit is, without the goal of having fair comparison. They list chart widget, but they do not list 3D chart widget, because then they would need to show that they do not have it, but Qt does. Same for equivalent of QGraphicScene etc.
Truth is Rust doesn't have, and will not have anytime soon anything comparable to Qt or VCL/LCL. No amount of GitHub starts and "made in Rust" disclaimers is going to change that.
They also note that Qt6 is not themeable which is completely wrong.
In my experience QT designer was awful to use. It’s probably fine if you are doing super vanilla layouts and widgets but as soon as my team started implementing custom css (or whatever the qt equivalent is called) things went off the rails. We pretty quickly abandoned to the tool completely to write the ui files by hand. They ended up much smaller and cleaner as a result. For some reason the designer seemed to add loads of unnecessary cruft.
So yea I can understand why they aren’t a priority.
That would seem odd.. the QSS is completely orthogonal to the code generated by the UI tool.
I accept that sometimes you need to some tricks with it and sometimes the layout in the preview is not the same you get at runtime which is annoying.
But in my UIs I use hundreds of widgets and I can't even begin to think about the useless effort required to write all the code by hand vs. spending seconds to drag and drop widgets into their place visually in the GUI editor...
WYSIWG and code are almost always if not always not done well together.