[FEATURE REQUEST] Move some features of Relm4 to gtk-rs

[AaronErhardt]

Relm4 and gtk-rs share the goal to make GUI development with GTK on Rust as convenient as possible. Over time, Relm4 has gained features that might be useful for gtk-rs users too. Therefore, I thought it would be nice to write down a list of features that don't depend on Relm4 and could be moved to gtk-rs.

Of course, this is just a suggestion and you can decide which features are suitable to be included and how they should be included.

Features

• Type-safe actions: example and implementation
• Menu macro to create menus conveniently, together with type-safe actions: example
• Multithreaded async runtime based on glib (early version available here)
• view! macro to initialize widgets conveniently (even without the relm4 crate)

Extension traits

• WidgetPlus: convenience methods that extend WidgetExt

Not part of this issue anymore but handled upstream:

• RelmIterChildrenExt: Iterate over the children of widgets
• RelmContainerExt: A re-implementation of ContainerExt for suitable widgets
• RelmSetChildExt: container_set_child method
• RelmRemoveExt: container_remove method

[Hofer-Julian]

• Type-safe actions: example and implementation
• Menu macro to create menus conveniently, together with type-safe actions: example
• Multithreaded async runtime based on glib (not published yet)

Especially those sound very useful to me

[sdroege]

Multithreaded async runtime based on glib (not published yet)

I think that should be a separate crate as that gets away from bindings quite a bit. Sounds interesting though. I assume that's juggling lots of main contexts and then schedules tasks between them in some way?

[AaronErhardt]

Yes, I planned to create a crate called "glib_async_executor" for this. Indeed, it's just a bunch of main contexts and a flume channel in a nutshell. It doesn't have outstanding latencies but works quite well otherwise. I think I will publish my local code very soon.

[sdroege]

I have more questions about that but let's discuss that in a separate issue or PR once the code is there :)

[AaronErhardt]

I've posted the code of the runtime here. It still needs quite a bit of polish but the core features are implemented.

[sdroege]

As long as it stays that small I guess we can put it behind a feature flag into the glib crate, but I'm not entirely sure what the use case of this is. How are you using it? :)

Also you probably want to implement the various executor traits from the futures crate and provide the various functions that other runtimes have like block_on, spawn_local, etc.

[AaronErhardt]

Relm4 allows you to run background tasks in your components (like commands in Elm), for example for HTTP requests or CPU intensive tasks. So far, this has been handled by tokio, but we want to allow users to choose other runtimes: Relm4/Relm4#114

[AaronErhardt]

Apart from of the async runtime discussions, what features are you interested in?

[sdroege]

The others are all quite GTK specific so I'm the wrong person to ask. For me they all sound quite interesting though

[Hofer-Julian]

Any opinions @bilelmoussaoui?

Or something to ask for feedback in the matrix room?

[bilelmoussaoui]

Regarding the extensions traits, all of them except RelmIterChildrenExt should be suggested as APIs upstream but most of them were removed in gtk3 due to reasons like the removal of GtkContainer API. For type safe actions, there is already a PR for that in gtk-rs-core, maybe helping finishing that one would be great & see if there are things that could be added to it.

The menu! & view! macros looks interesting though. Do you mind sharing some examples how they work or a link to their source code?

[Hofer-Julian]

For type safe actions, there is already a PR for that in gtk-rs-core, maybe helping finishing that one would be great & see if there are things that could be added to it.

One small note here, if possible I think it would be nice if Relm4 and the bindings would end up with the same API in the end.

[AaronErhardt]

Regarding the extensions traits, all of them except RelmIterChildrenExt should be suggested as APIs upstream

We don't have a GTK dev in our team and although I know C and can understand most of GTK's source code, some guidance would be appreciated. Also, this is not just an extension of GTK's widgets, but is implemented for some types from libadwaita and libpanel too.

The menu! & view! macros looks interesting though. Do you mind sharing some examples how they work or a link to their source code?

Docs with examples including the macro expansion and the source code:

• view: docs, code
• menu: docs, code

The view! macro itself doesn't need any Relm4-specific features, but I should note that it supports additional features in certain contexts (for example combined with the #[component] attribute macro) that only work together with Relm4. Entirely separating those features into another crate does not make sense because a lot of code is shared, but those features could be put behind a feature flag.

The menu! macro is a lot simpler in comparison and does not depend on anything else but the type safe actions implementation of Relm4. I hope we can work together on a type safe actions implementation. Honestly, I'm not entirely sure which PR in gtk-rs-core you were referring to.

[bilelmoussaoui]

We don't have a GTK dev in our team and although I know C and can understand most of GTK's source code, some guidance would be appreciated. Also, this is not just an extension of GTK's widgets, but is implemented for some types from libadwaita and libpanel too.

Opening an issue with API suggestions and seeing how the upstream gtk developers want to go forward is a good idea. The implementation part is a different story but I definitely don't want the bindings to try and fix the original API. gtkmm did that and it ended up in a very bad shape.

[bilelmoussaoui]

I'm not entirely sure which PR in gtk-rs-core you were referring to.

gtk-rs/gtk-rs-core#67

[AaronErhardt]

gtk-rs/gtk-rs-core#67

Maybe we should discuss this separately, but I think this PR is doing something very different for a different use-case. It seems to target use-cases in combination with UI templates, whereas the approach from Relm4 is more lightweight and less opinionated (but rather targets UIs built with Rust code). Naturally, UI templates that use GTK builder can't transport any type information. However, the implementation in Relm4 is explicitly type safe: you can't accidentally pass an action with the wrong signature nor misspell the action name.

[AaronErhardt]

Opening an issue with API suggestions and seeing how the upstream gtk developers want to go forward is a good idea.

I've created https://gitlab.gnome.org/GNOME/gtk/-/issues/4991