Qt is still used, but I think part of the reason it is less used is that C++ isn't always the right language anymore for building GUI application.
That’s actually why we're working on Slint (https://slint.dev): It's a cross-platform native UI toolkit where the UI layer is decoupled from the application language, so you can use Rust, JavaScript, Python, etc. for the logic depending on what fits the project better.
How can C++ not be the "right" language? It seems to meet all the requirements for event-driven GUIs - event handlers are function callbacks after all...
C++ works, but compared to other languages it's often no longer the most productive choice for UI work.
Modern UI code is mostly glue and state management, where fast iteration matters more than squeezing out maximum performance. And when performance does matter, there are also newer, safer languages.
For teams comfortable with C++ or with existing C++ libraries to integrate, it can of course still be a strong choice, just not the preferred one for most current teams.
But desktop C++ isn't difficult or slow to write...
It seems odd to me that the software world has gone in the direction of "quick to write - slow to run". It should be the other way around. Things of quality (eg. paintings by Renaissance masters) took time to create, despite being quick to observe.
It also seems proven that releasing software quickly ("fast iteration") doesn't lead to quality - see how many releases of the YouTube app or Netflix there are on iOS or Android; if speedy releases are important, it is valuing rush to production over quality, much like a processed food version of edible content.
In a world that is also facing energy issues, sluggish and inefficient performance should be shunned, not welcomed?
I suppose this mentality is endemic, and why we see a raft of cruddy slow software these days, where upcoming developers ("current teams") no longer value performance over ease of their job. It can only get worse if the "it's good enough" mentality persists. It's quite sad.
The part that takes time in UI isn’t wiring up components, it’s the small changes like something is a pixel to the right or that gap is two pixels wide. Changing those in a C++ project means recompiling and that adds up to significant overhead over a day of polishing the UI. If C++ was able to get builds out in less than a second, this wouldn’t be an issue. People value performance in their own tools more than the tools of their customer.
In modern Qt you don't write UI in C++ anymore - you do that in QML. It is far simpler to create amazing pixel perfect UIs with drooling-inducing animations in QML. I wrote a blog post that talks a bit about this[1].
In wxWidgets you use sizers, so you don't work on pixel-level alignments. I can understand if you're using an ancient framework like MFC, but even then I seem to recall there was a sizer equivalent system (or it is easy enough to write a class to do so, moving components).
I think it is a daft thing to move to shipping a colossal web framework and entire browser simply because of 1px UI alignments (which have been a solved problem for decades in C++ anyway).
> someone has to make a native cross-platform desktop UI framework that doesn't suck
This is exactly what we're trying to do with Slint (https://github.com/slint-ui/slint
).
It’s a native, cross-platform UI framework for desktop and embedded (Rust/C++/Python/JS), with no browser runtime
slintpad.com uses the wasm port to run on a browser and is not the same as when using Slint to build a "native" app, especially on mobile.
Slint does support decent text input and IME. Including text selection with the native handle. As a demo for android you can try the demo from https://material.slint.dev/ ("Download APK")
Of course Rust can handle those use cases fine (GUIs, web browsers, and game engines).
C++ is still high on the TIOBE index mainly because it is indeed old and used in a lot of legacy systems. For new projects, though, there's less reason to choose C++.
Web browsers, yes. With GUIs and games, it's a less clear. Of course you can write GUIs and games in any Turing complete language but there's still a lot of work to be done in finding the right ergonomics in Rust [1, 2].
It's still high because it solves real world problems, so it's still the gold standard for anything ranging from systems programming to scientific computing.
Author of one of these "markup"-based toolkits here. I believe that Rust might not be the best language syntax to express UI. I am curious why you are so strongly against using a DSL.
When I went to go look for a platform to implement a personal text editor on, I somewhat quickly settled on the vt100 terminal api with kitty extensions, particularly its keyboard protocol. Everything else locks you into, not only a language, everybody codes frameworks these days, nobody writes apis, but also what's essentially already a legacy solution, a framework is going to get updates at the speed of the developer's passion.
Whereas when kovid made the kitty terminal protocol, it got implemented by the next 3 or so new terminal emulators. You don't get this kind of modernization from any other UI solution save browsers. And no way do I want to do web development for my own stuff. I suppose I could target Dillo or something like Servo, but I'd be more inclined to consume the base X11 protocol, as Vidar H did.
My Ruby terminal protocol implementation has smooth abstractions from methods performing the bare VT control calls up to semantic methods with better naming, to flexible and extensible text field abstractions. All the concerns are separated nicely and Ruby lets me scope everything just right, so I can call a debugger anywhere as the necessary logic is scoped module-wide.
I simply cannot imagine having any kind of fun doing this in a static compiled language. And I'll be able to build on top of this to make things that aren't editors.
That’s actually why we're working on Slint (https://slint.dev): It's a cross-platform native UI toolkit where the UI layer is decoupled from the application language, so you can use Rust, JavaScript, Python, etc. for the logic depending on what fits the project better.
reply