I hope QML/js crap will be abandoned, and C++ API will be prioritized.
And due to C++ API, Qt has poor language bindings, compared to GTK and many others with C API.
Why? And why are scripting languages better?
It's okay to have expensive abstractions where a few milliseconds simply don't matter, but tasks can be done in minutes instead of hours. Declarative UI descriptions also have the benefit of being friendly to visual designer applications, so you need fewer build/run/test cycles (which are far from quick with C++).
I dare you to compare the speed of UIs of Windows XP and Windows 10, even when using the hardware that was current when those OSes were released.
Responsiveness peaked in the 80’s, in the dumb terminal + regional mainframe era. :-(
I can't even imagine why you'd think that reading and parsing XML and constructing a UI would be cheaper than any other way of building UIs.
Really, did you measure it? Since we are, scientists and everything? Where are the numbers?
And how do any differences you've found compare (timing wise) with human initiated action and perception latencies -- like those required to click an on-screen button and see it being depressed?
>as seen in Mozilla's XUL or typical web apps
You see button being pressed time/action as a problem in "XUL or typical web apps"?
(Memory consumption when the drawing is done with DOM, or slow rendering of large scene graphs, I'd buy -- but this is not the model we're talking here, where JS calls a native control directly, and doesn't render through DOM/web rendering).
>I can't even imagine why you'd think that reading and parsing XML and constructing a UI would be cheaper than any other way of building UIs.
Actually that's the way tons of native apps work, from games, to Gnome, to Windows and so on.
Second, if you think the "parsing a XML UI declaration" is in any meaningful way more expensive that imperatively calling a bunch of UI functions directly, you have a distorted idea of what makes a UI slow, or of the time needed to parse an XML file and initialized controls based on it...
This remark should (also) have been directed at his parent comment, who made the contrary claim without any measurement either.
> Second, if you think the "parsing a XML UI declaration" is in any meaningful way more expensive that imperatively calling a bunch of UI functions directly, you have a distorted idea of what makes a UI slow, or of the time needed to parse an XML file and initialized controls based on it...
The numbers?
You might want to read this ode to fast software: https://craigmod.com/essays/fast_software.
Lots of C++ Qt apps create their UIs from XML. They just do it at compile time.
Most of this is no longer as relevant in C++, can't speak for Rust. Programming languages have been converging for quite some time, C++ of today is more dynamic and convenient than any version that came before.
That being said, you can't beat dynamic languages for some tasks. Runtime code generation/eval being the most obvious I can think of. Any kind of extension/plugin architecture has everything to win from going all in with a full scripting language from my experience.
Declarative UI languages do have some advantages compared to regular programming languages, but that's unrelated to the claim you made.
Bindings are not C++'s problem, they're the problem of the other languages which try to use UI frameworks written in C++, like Rust, which still doesn't have any decent UI library.
That may be true for Python, but the Common Lisp bindings for Qt4 were equally as "powerful" as the C++ bindings. It had higher level abstractions that generally made it easier to read and write, as well.
> Bindings are not C++'s problem
Actually, bindings are a problem with C++. Some features (like templates) and implementation details (like name mangling) make it very difficult to create bindings to C++.
Gives the basics of the difference
QML, Swift, Android, UWP, WPF, Forms, Blueprints, Unity, React Native.
QML is way faster to develop in than C++. And it hides a lot of signal/slot boilerplate that doesn't matter. And I can still write C++ classes that interface with QML when I want.
I agree, not necessarily with c++ but it's much better to build UI's with code than declarative xml crap.
It will be a shame if Qt sticks to a pure c++ interface though, I'd hope the build something more usable from more languages so it's an option for C, Zig, Rust, etc.
Microsoft is the only consumer OS vendor that still supports C++ for doing full stack GUI apps, everyone else moved into a mix of C++ plus managed language or layout DSL.
On modern Windows you have C++, and also layout DSL, specifically XAML. And that C++ is not particularly idiomatic, it’s IUnknown-derived interfaces.
If you mean windows desktop, WinAPI uses quite a few DSLs. Dialog and menu resources are the most obvious, but there’s more: WMF/EMF vector graphics format, ribbon markup XML for ribbon control, theme files…
Modern Windows desktop UI, UWP aka WinUI, uses C++17 with a framework called C++/WinRT, that hides those IInspectable COM interfaces.
Yes there used to exit C++/CX and Windows Runtime Library, both now considered legacy and replaced by C++/WinRT.
So for targeting X11/Wayland or Windows, you can bet 100% on C++, only Apple platforms do not offer native C++.
Which UNIX OS SDK uses a C++ GUI full stack?
One could argue for Kubuntu or SuSE, maybe, except KDE isn't tied to a specific OS and then again it uses Qt alongside QML since Plasma, so no pure C++ stack here.
And since you missed to fully read my comment, here it is again:
> Microsoft is the only consumer OS vendor that still supports C++ for doing full stack GUI apps
I like QML but it's not that great for many / most desktop applications. It works better for creating fully custom touch UIs from scratch. The plan for Qt 6 mentions a styling API which is one of the most important missing pieces, and discussion in the comments maybe indicates more ready to use controls.
Plus ca change…