Hacker News Reader

Comment by smoldesu | Hacker News Reader

I personally disagree with a lot of the changes GTK4 introduces, but I still think it's my favorite way to build quick little native apps on Linux. If you're well-versed in Rust, I really recommend checking out gtk-rs[0], a fantastic little crate with a surprisingly robust GTK implementation. If you're familiar with 'builder' style tools (particularly Glade), your workflow will feel right at home. Plus, memory safety/type safety/good concurrency and all those other awesome Rust freebies you get are super nice for GUI apps.

[0] https://gtk-rs.org/

View on HN

Gtk-rs is still pretty bare bone.

I tried to do my part by removing boilerplate using macros [1] [2], but it is still complicated to design GTK apps. Even more now, because Glade has been deprecated for GTK4 and no visual editor is available to replace it for now, making developers manually write XML while exploring the sparse documentation. This is a regression for developers' experience.

I am really trying to like GTK after using Qt a lot in the past, but there is just too much effort. Things should be as simple as VB6/WinForms. With no visual GUI editor, I find myself to just write CLI tools in Rust instead of going the extra mile and creating GUIs.

[1] https://github.com/MicroJoe/gladis

[2] https://github.com/MicroJoe/gtk_liststore_item

I haven’t tried it yet myself but there is https://gitlab.gnome.org/jpu/cambalache which supports both gtk3 and 4

I downloaded and tried it just now.

When creating a project, I get an empty .ui file with no possibility to add any widget. This project still seems in its infancy, or I am doing something wrong. It also seems to enforce a "framework" instead of just being a graphical .ui file editor. How I am supposed to use this if I am using Rust instead of Python, and Relm instead of their MVC framework?

I miss Glade (and it had issues!).

Try writing the name of the widget in the search bar in the top left. Something like GtkWindow.

Thanks, it works.

However adding a GtkApplicationWindow and a GtkButton inside of the component tree is not updating the preview area. Adding a know valid GTK3 .ui file [0] does not update the preview area either.

Seems like the "preview" button is also missing from Glade. Oh well, let's edit XML files afterall. :)

[0] https://github.com/MicroJoe/gtk_liststore_item/blob/master/g...

Yeah, it is still very early on in development. I am personally a fan of QtCreator, it is very similar to how visual studio used to work regarding ui creation.

The UI is a bit rough and still unstable, I think you have to press the search button and then type the name of the widget in the search box and double click.

It's just a .ui file editor, so unfortunately you can't use it with Relm. Maybe someone could write a tool that converts .ui files to Relm code. Although I guess it would be a one-way transition, so perhaps not so useful.

You do not have to convert .ui files to Relm code, see gladis's relm example [0].

[0] https://github.com/MicroJoe/gladis/blob/master/gladis/exampl...

Sorry, I thought you meant if you wanted to save it in the style of those Relm declarative macros.

Thanks for sharing, it seems to be in heavy development right now though. I'll admit though, forcing you to choose from 5 stylesheets before implementing basic design features did get a chuckle out of me. What's GNOME may never change, I suppose.

That "gladis" crate seems to be redundant since it does the same thing as template widgets [1]. I would say you can probably drop that one.

The "gtk_liststore_item" crate seems useful, have you thought about starting a conversation with the gtk-rs developers to try to upstream something like that?

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

I cannot find any relevant documentation while searching "gtk template widgets" in my favorite search engines. Do you have a link? Maybe this crate is still needed because of discoverability issues, if one cannot find an alternative easily.

I have not started to discuss with gtk_rs team for the moment.

Since this second crate has less "stars", I guess the gladis crate should be figured out first: incorporated, or documented in gtk-rs so that it is made obsolete.

EDIT: here is the feature request to merge gtk_liststore_item into gtk-rs: https://github.com/gtk-rs/gtk-rs-core/issues/297

Sorry, I edited my comment. Check that for the link about templates. This tutorial also has a C example: https://github.com/ToshioCP/Gtk4-tutorial/blob/main/gfm/sec2...

The term to look up is "gtk composite templates".

The gtk4-rs book has a tutorial on them: https://gtk-rs.org/gtk4-rs/stable/latest/book/interface_buil...

Gladis seems to wrap the child widgets in a regular Rust struct. The composite template stuff in GTK uses subclassing to make a new widget wrapping the child widgets.

GTK has a better approach imo - the issue is that the macros for subclassing in gtk4-rs are _really_ verbose and confusing. You need two different structs, with several trait impls on them. Adding GObject properties is verbose and tedious. Adding methods on the widget is confusing - it's confusing which struct the method goes on and how to access the widget in each part.

Overall I liked GTK for the end result it produces, but not the API. I've been meaning to give Relm4 a try - it seems like a much better way to handle state and widget composition in Rust than the vanilla GTK stuff.

"the issue is that the macros for subclassing in gtk4-rs are _really_ verbose and confusing."

I didn't find it that complicated but I've also worked on plenty of GObject code in C. It's mostly a direct equivalent to what the C code would look like. I think part of the problem is that some of the examples are not really structured well, the mod/imp split makes it a lot more confusing than it needs to be. In my opinion you can just skip putting methods on the private struct and only put it on the public one and that also simplifies it a lot.

But Relm should be a step up if you like the declarative style.

Ah yeah if you're coming from using GObject in C, it probably makes much more sense. Still, I would highly prefer macros that made it much quicker to subclass. Things like:

* Automatically figuring out which parent objects the class you're subclassing derives from, instead of having to import and then list out all of them individually. This is for the glib::wrapper!() macro. * Automatically filling out ObjectSubclass, and WidgetImpl, etc. * Helpers for properties and signals * A flat list of methods, instead of the public/imp split

The bigger issue that Relm solves imo, is state management. I feel like I had a difficult time figuring out how to share state between widgets. You end up with lots of OnceCell, Rc, and RefCell, and it quickly becomes confusing, especially when you start subclassing GObject and making your own objects.

As soon as I think of a good project to work on, I'm going to try out Relm4 and see if it is better than gtk4-rs.

"Automatically figuring out which parent objects the class you're subclassing derives from"

AFAIK this is a language limitation, there is no way in a Rust macro to take a type and get all the traits that are implemented for that type. It would need some kind of reflection API. Maybe someone could try it with this crate? https://crates.io/crates/reflect

"Helpers for properties and signals"

There are some open issues for this: https://github.com/gtk-rs/gtk-rs-core/issues/27 https://github.com/gtk-rs/gtk-rs-core/issues/214

"A flat list of methods, instead of the public/imp split"

You can already do this in your code and use "pub fn" and "fn" like normal.

"I feel like I had a difficult time figuring out how to share state between widgets. You end up with lots of OnceCell, Rc, and RefCell, and it quickly becomes confusing,"

I think you are supposed to use bind_property and the gtk::Expression objects to do data binding, though that part is not so convenient to use from C or Rust either.

Oh, I haven't written much with the 4.0 version yet (I'll cling to 3.38 till I die), so that's news to me. I'll just toss that in the pile of "user/developer regressions introduced with GTK4/Gnome 40", I suppose.

Personally I am philosophically opposed to hard-coded widget positions like Win32, and Qt's graphical layout editing system is awkward to edit, so I mostly write code. :(

Reply on news.ycombinator.com