Feedback on relm4 widget macro design

[AaronErhardt]

Relm4 is continuing to improve and I think it's time to think about macros (earlier discussion can be found here: antoyo/relm#289). Since the ContainerExt trait does not exist anymore in gtk4-rs the macros from relm can't be simply ported over to relm4.
Also the new concepts of relm4 like trackers and generators should be integrated into the macros. And since the update function doesn't have access to the widgets anymore, the macros only need to generate code for the widgets but don't have to care about the model.

The following code shows an example of how the new macro for generating widgets could look like:

// Generates code for the
// - AppWidgets struct 
// - init_view() function    \
// - view() function          ) -> impl RelmWidgets
// - root_widget() function  /
#[relm_widgets]
struct AppWidgets {
  // specify generic types
  type Model = AppModel;
  type Components = AppComponents;
  type Msg = AppMsg;

  // RelmRoot is the ApplicationWindow generated by relm4
  main_window = RelmRoot {
    set_default_height: 400,
    set_default_width: 600,
  
    // calls set_titlebar() on main_window
    // adding new widgets follows the syntax:
    // method_to_add_widget: [name =] function_that_creates_widget()
    // [name =] is optional
    set_titlebar: titlebar = gtk::HeaderBar::new() {
      // calls pack_end() on titlebar
      pack_end: gtk::Button::new() {
        clicked => |_| Msg::Clicked,
      },
      
      // calls pack_start() on titlebar
      pack_start: hello_button = gtk::Scale::new(Orientation::Horizontal, None) {
        set_value: 0.5,
        change_value => |_, _, value| {
          Msg::UpdateValue(value);
          Inhibit(false)
        }
      },

      // calls set_title_widget() on titlebar
      set_title_widget: title = gtk::Box::new() {
        // calls append() on title
        append: title_label_1 = gtk::Label::new(None) {
          // set_label only if model.counter changed
          // since counter is an integer we need to specify how to convert to a &str
          set_label: track!(model.counter, {
            &model.counter.to_string()
          }),
        },

        append: gtk::Label::new(None) {
          // same as before but model.label2_string is already a String
          set_label: track!(&model.label2_string),
        },
      },
    },

    // calls set_child() on main_window
    set_child: main_container = gtk::Grid::new() {
      // calls attach() on main_container
      // because attach needs position information we use attach(column, row, width, height)
      // before actually creating the widget
      attach(1, 1, 1, 1): grid_label = gtk::Label::new(None) {
        set_label: "Grid label",
      },
      
      attach(2, 1, 1, 1): gtk::Grid::new() {
        set_row_spacing: 2,
        
        // call a generator on this grid that generates children from blueprint defined in the model
        generate!(model.grid_data),
      },
      
      // attach a component
      attach(1, 2, 1, 1): component!(components.comp1),
    },
  },
}

Please let me know what you think :)

[ghost]

i honestly prefer to do my widgets setup manually because while it might be a little more glue, it's also completely readable. when i first found this project a few days ago i was mildly confused by the macro because i wasn't sure where the AppWidgets struct was being defined.

this would be a huge improvement towards making things easier and more obvious. tho i'll still probably do everything manually.

[AaronErhardt]

IMO the macro is much more readable. But doing it manually is fine as well.

For the macro is simply doesn't make any sense to define the AppWidgets struct. That would actually make things much more complicated. But you can always add fields manually: https://aaronerhardt.github.io/relm4-book/book/widget_macro_reference.html#add-more-fields-to-your-widgets

Also there's a chapter in the book that explains the macro expansion and how the struct it generated: https://aaronerhardt.github.io/relm4-book/book/widget_macro_expansion.html#the-widgets-struct

[sanpii]

https://github.com/orgs/Relm4/discussions/679#discussioncomment-11585685

It would be nice to have a syntax similar to relm3 to do this directly in the view! macro:

view! {
    gtk::Box {
        Foo(/* init */) {
            /* Messages forwarding */
        }
    }
}

[AaronErhardt]

While this syntax indeed looks nice, it has some downsides, too. In particular, this makes it difficult to interact with components after initialization because they are not accessible. And even if we make them accessible, e.g. by allowing users to name them similar to widgets, they would be part of the widgets struct, thus mixing app state and UI state. Of course the current way of adding components to the widget tree is a bit bare bones, but I think there are other, more consistent solutions we should try first.

[sanpii]

In this case, it's possible to use a local ref?

[AaronErhardt]

Yes, you can write let foo_widget = foo.widget(); in init() and then use #[local_ref].

[sanpii]

I don’t sure we’re speaking the same thing.

I think a new feature like:

struct Model {
    foo: relm4::Controller<Foo>,
}

#[relm4::component]
impl relm4::SimpleComponent for Model {
    type Init = ();
    type Input = ();
    type Output = ();

    fn init(
        _: Self::Init,
        _: Self::Root,
        _sender: relm4::ComponentSender<Self>,
    ) -> relm4::ComponentParts<Self> {
        let model = Self {
            foo: Foo::unintialized(),
        };

        let widgets = view_output!();

        relm4::ComponentParts { model, widgets }
    }

    view! {
        model.foo -> Foo(/* init */) {
            /* Messages forwarding */
        }
    }
}

A real example: relm3 VS relm4.

[AaronErhardt]

In relm3 the components are not stored in the model, but only added to the widget tree. It's been a while since I've last used it and I don't know how it handled components with individual state, but the suggestion from you with Foo::unitialized() looks pretty tough to implement in safe Rust.