Hacker News new | past | comments | ask | show | jobs | submit login

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've been experimenting with gtk-rs, but the GTK ecosystem is really difficult to get right. The examples are few and far between, and the type exceptions the macro DSL throws are very difficult to parse.

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.


Assuming you meant "GNOME" Builder rather than GtkBuilder (the template loader for GTK), I'm the author of it and can help figure out what is going wrong on your system wrt not compiling anything.

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.


You're right, I did mean the GNOME builder.

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.


42 will be out in a couple weeks, and it has a lot of work to make flatpak stuff work better in the presence of "system" installations (rather than user installations where we normally install SDKs).

Hope you'll try it out! (It's also available on Nightly).


Is GNOME Builder intended to be usable as a general-purpose IDE, beyond just developing GNOME applications? It seems like with a bit of work it could be a very nice alternative to the usual picks.


There are really only a few of us that make Builder, mostly just in our free time. So that means we have to be very focused with our time and choose to focus on making it easier to write GNOME software.

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.


GTK and Rust works really well on Linux, which I suppose is the pertinent part given the focus of the article. I've yet to work out how to get GTK and Rust to work on macOS or Windows, which makes cross-platform UI difficult.


I built a new GTK 4 backend specifically for macOS so we have native support for rendering all of the UI with OpenGL like we do on Linux and Windows. I'm fairly quick to fix bugs if I get good reports, and it can be installed with `brew install gtk4`.

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.


FWIW, my smallish project [1] (Rust + GTK3) builds and works on Windows out of the box. I use the MSYS2 build environment.

[1] https://github.com/GreatAttractor/vidoxide


Thanks. I'll take a look. I've tried Relm 3, Relm 4, and gtk-rs, but they all use Linux only in their CI. I just can't work out what to install and what env vars I need. I didn't the official GTK docs all that helpful on the topic. I'm keen to see how to package the whole thing up, too. Ideally, I could just put the necessary libraries in a directory with the executable.


GTK4 is supposed to "just" build with meson on Windows – yes, just with MSVC, not requiring any of the GNU toolchain type things: https://www.collabora.com/news-and-blog/blog/2021/04/29/buil...

If no one has yet wrapped this into a Rust crate, someone should…


Oh, nifty. I tried getting it going with msys2 and didn't have good luck. I think something might be conflicting. I haven't gotten to the point of wiping the machine yet. Maybe I'll have better luck with meson.


gtk-rs has a book[1] which has setup information for windows. The install was easy on windows following the instructions. I have yet to build an app with GTK4 so I can't comment on the writing and building of apps just yet.

[1] https://gtk-rs.org/gtk4-rs/stable/latest/book/


Thanks. I'll try running through that. relm4 links to https://www.gtk.org/docs/installations/windows/ and I followed those steps without success.


I followed those as well but changed to whats in the gtk-rs book A word of warning: before you start, if you choose to go down the MSVC path, you have to uinstall msys2 and remove msys from your environment paths. If the Meson build find msys2 in your environment path variable, it will try to build using msys2.


For Qt (QML/QtQuick; Widgets are no linger the preferred method afaik) you have qmetaobjects-rs, which is reeally nice.


QML is practically electron - it's runtime interpreted declarative UI plus a Javascript engine.

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.


> QML is practically electron - it's runtime interpreted declarative UI plus a Javascript engine.

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.


> practically electron - it's runtime interpreted declarative UI plus a Javascript engine

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.


I'm so glad someone said it. I have long stopped working in GUI space, but I remember how horrible HTML/CSS is for app development and how great and flexible Qt was. Even more frustrating seeing where the industry is going now with Electron.


Having a declarative UI does not make it comparable to Electron. Same as XAML is not comparable. They don't embed the whole browser.


> QML is practically electron

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.


Real question: You wrote "responsive-layout desktop app". What do you mean by this term?

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).


I meant "Responsive" to mean something like media query breakpoints - at certain widths, Telegram will rearrange entire UI elements and change the navigation paradigm.


qmlcompiler is open source and the new qmlsc is also open source. It's just the extensions that helps making your qml code compatible with the new compiler that isn't open source. This is indeed annoying but not everything is commercial only.


Where can I find the source code for qmlcompiler and qmlsc?

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.


I found a qmlcompiler folder at https://github.com/qt/qtdeclarative/tree/dev/src/qmlcompiler, but I don't know if it's the compiler itself or bindings. I can't find qmlsc in GitHub qt or qtproject though.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: