[RFC] Planning the transition to GTK4 (relm4) about relm HOT 7 CLOSED

Using Channel is indeed much simpler, but I believe you could get the cyclic reference problem that caused a memory leak in relm before.
It seems there's no way to get a weak reference to it. Morever it might be less efficient than the implementation in relm since it uses a Mutex (but that's probably okay, especially since that would allow us to get rid of the Channel type in relm).

The reason it's more complicated in relm is because glib::Channel hides all of the complexity for you ;) .

I pointed @MGlolenstine to here so you two can coordinate.

from relm.

Yeah, that issue is annoying indeed and I'm not sure what the solution should be.

I was wondering whether we could somehow leverage GtkBuilder or the Glade XML format. I see there's a add_child() method in GtkBuildableIface but I'm not sure how to access it and whether that would work for this use case.

Another idea would be to make the view! macro generate the Glade XML format: while I don't particularly like the idea of generating at compile-time something that would be parsed at run-time, that would solve a lot of issues like some widgets not working in the view! macro.
Edit: now that I think of it, maybe it's a bad idea: I guess the XML names might not always match gtk-rs method names so how would we do the type checking?

What are your thoughts on those ideas?
Are you familiar with these concepts?

from relm.

Hi, I'm back.

It took me longer than expected to finish this because I had to work on some other stuff but now I've got an experimental version of relm working with GTK4. Initially, I planned to rewrite relm but I found it the core API rather unnecessarily complicated (but maybe that's for a reason, I'm no expert of the current relm version).
And when I found out that EventStream has a similar implementation in the latest glib bindings I thought I might as well try it out.

And it did work pretty well. I came out with a basic reimplementation of relm in about 100 lines of code. The design has changed a bit but the idea is still the same. Here's the code: https://github.com/AaronErhardt/relm4

I've seen that @MGlolenstine worked on porting relm as well. I think it would make sense to work together on this. I don't think I can contribute a lot over the next weeks due to upcoming exams but I think collaboration makes a lot more sense that porting relm twice :)

from relm.

I think this issue can be closed now since the first beta versions of Relm4 are available.

from relm.

I don't think XML makes sense in the view macro. The current view macro can not only build the UI, it also creates the widgets member of the model struct using the #[name=...] attribute and can update the view automatically to some extend. I can't image how that would work with XML and as you mentioned the XML names basically have to match the gtk4-rs counterparts for this to make even work.

GtkBuildable would actually be the only alternative to containers in GTK. But I don't think that's a good idea either. GtkBuildable wasn't intended for this use-case and this could potentially involve a lot of unsafe code to work.

Maybe Container traits need to be abandoned at this point. After having a rough look at the code of relm I can't say how important the Container traits are but maybe we can rewrite the parts that are using those traits currently.

Maybe the code could be even simplified by only resembling the existing GTK interfaces in an idiomatic manner. Something similar to my code example above. Ideally this would simply match the gtk4-rs interfaces, so that the proc macro just has to call member functions of a gtk widget. Like this for example:

view! {
#[name="main_window"]
gtk::Window {
    set_child: /* internally calls main_window.set_child(), expects gtk widget */,
    set_title: /* internally calls main_window.set_title(), expects Option<&str> */,
    .....
}

So overall less magic, but just a simple solution to access the interfaces of gtk4-rs. Also this could potentially resolve some of the current "workarounds" like nested view macros and the problems when creating something like popovers.

However, in general the code and the implementation of relm isn't yet fully clear to me so I can't confirm whether my solution would work :/

from relm.

Oh, the idea was that we would generate more code than just the XML. Code like:

builder.get_widget("button").connect_clicked(…)

Your last example looks like it would actually require the nested view! macro as in:

view! {
#[name="main_window"]
gtk::Window {
    set_child: view! {
        gtk::Button {
        }
    },
    set_title: /* internally calls main_window.set_title(), expects Option<&str> */,
    .....
}

And I'm not sure how that will solve the other issues.

Another idea would be to use the builders and have relm4 not require any macros (or less macros):

fn view(&self) -> gtk4::Widget {
    gtk4::WindowBuilder::new()
        .title("Title")
        .child(gtk4::ButtonBuilder::new()
            .label("Button")
            .build()
        )
        .build()
}

with a few helper functions to bind properties (maybe even using gtk binding system) and connect events maybe.
That would be a big redesign of relm, but might end up being much simpler.

To be honest, I don't have much time to work on relm, these days, but if you want to experiment with the latter approach, you could try incorporating the core of relm in it to see how to do event handling and model management (see this example to learn how to use this core module).

from relm.

Thanks for linking the resources. I guess it's a good idea to port the core first, anyway. I'll experiment a little bit over the next days and will keep you up to date with my progress :)

from relm.