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