Rust and GTK3/4 are fairly well supported, no?
I know QT is a bit more of a pain to do from Rust, but I wanna say that's possible too... though nowhere near as evident as gtk-rs.
I know QT is a bit more of a pain to do from Rust, but I wanna say that's possible too... though nowhere near as evident as gtk-rs.
All the necessary components are there, but there just aren't enough guides out there to get started. I tried looking into how existing applications use the ecosystem, but experienced GUI developers pull tons of dependencies and use complicated code structures that are hardly documented.
I think switching from Python/GTK to Rust/GTK is probably an easy move, but as someone coming from .NET Forms GUI design, it's been tough getting into GTK. GTK Builder is supposed to have native support for Glade and all the other nice tools, but for me that either doesn't compile any code or refuses to even work at all.
Just file an issue on gitlab and I'll take a look.
Usually when we come across bugs like this it's related to distro packaging as we have no hand in that and the Flatpak packages I maintain generally do-as-advertised.
I don't know what's wrong exactly, I think it's Flatpak related. From what I remember, it had something to do with a certain version of the GNOME SDK not being installed (I think it was looking for a version of something that didn't exist?) so it failed a dependency check when I hit the install button from the Builder popup. I think this caused the tool to get into a faulty state where it thought the dependency was installed but simultaneously suggested installing the dependency, so it freaked out. I'm usually working on Ubuntu so combining the outdated Ubuntu stable-ish packages with Flatpak's bleeding edge stuff causes issues from time to time.
This could've been a temporary problem and I could've had a streak of bad luck, or maybe my deskop and laptop are somehow just set up plain wrong. I'm no expert in Flatpak internals. I also don't have Builder set up any more so reproducing the problem is kind of hard. Next time I'm giving it a try, I'll try to keep in mind to actually post a bug report.
Hope you'll try it out! (It's also available on Nightly).
That said, the whole thing is an open ended plugin architecture and we are very liberal about accepting all sorts of things. Many people do use it successfully outside it’s intended scope.
If no one has yet wrapped this into a Rust crate, someone should…
You can also build GTK for macOS easily with meson as it has subprojects for everything. In fact, our CI does it from scratch on every commit w/ macOS. On Windows you can just open GTK with visual studio and build it by using Meson to generate the project files.
A bunch of work is about to land to make the macOS backend more solid/faster too similar to the work Firefox did in the last couple of years to reduce power usage w/ OpenGL/IOSurface/etc.
QML still has only rudimentary support for AOT compilation. Both the old qmlcompiler and the new qmlsc compiler are commercial-only: https://www.qt.io/blog/the-new-qtquick-compiler-technology . LGPL users only get the interpreter.
Widgets is still the 'Real Qt'. Some very modern, responsive-layout desktop apps like Telegram are written entirely with Widgets.
It uses significantly less resources and QML and QtQuick are pretty nice to work with compared to targeting a weird embedded browser with HTML, CSS and JS.
qmltc and qmlcachegen are available in the qtdeclarative.git repo (on either code.qt.io or GitHub) but i can't find qmlcompiler nor qmlsc anywhere. I believe they are commercial only under the "Qt for Device Creation" license.
Except, none of that is what's wrong with Electron. What's wrong with Electron is the bloat inherent in being an entire web browser, and the fact that the DOM+CSS is terrible for UI development.
From my experience, if you develop Qt widgets (like dialogs with many child widgets), it is possible (some might say easy) to make things resize correctly by using QHBoxLayout (horizontal) and QVBoxLayout (vertical).
Nope. Electron is a whole browser under your seat, QML is a declarative language to instantiate C++ UI objects. The core logic of your application is written in C++/Qt instead of Javascript.
> QML still has only rudimentary support for AOT compilation
Fair point. But it shouldn't really matter in any application today, as your logic must reside in C++ models if you want to have real performance.