Naming Render traits / methods

[Nickel]

@matta

I think Ratatui uses the term “widget” in a far looser sense than just implementing one trait. It is a design pattern, and an expressed intent to allow for re-use and composition of some sort

I completely agree with this. It is very useful to understand and use in design, but the use of the Widget trait makes it feel like you are required to implement the widget trait, or you aren’t able to render at all - which is actually quite opposite to how the rendering works.

I personally have been brought over to the side of Render just because when you see the render trait, you say “oh, that’s where the rendering happens”, instead of “that’s where the magic functionality of the widget happens”. Because the rendering in actually very straightforward.

@matta

I find it quite easy to imagine a future where a Ratatui “widget” could choose to implement additional traits, at which time it will be strange that one of the traits in the “widget family of traits” is called “Widget” and the others follow a different convention

The trait is there to provide a universal contract for calling renderable things in a backwards compatible way, and Widget isn’t very forwards compatible.

[joshka]

So I implemented a Focus trait crate:

Focusable crate - manage focus state for your widgets

https://crates.io/crates/focusable This lets you do things like automatically derive focus for a widget: #[derive(Debug, Clone, Focus)] pub(crate) struct TextBox { pub(crate) is_focused: bool, pub(crate) content: String, } Including widgets that won’t be focusable (can_focus() / is_focused return false and focus() / blur() do nothing). #[derive(Debug, Clone, Focus)] pub(crate) struct Label { pub(crate) text: String, } You can use the trait to generically handle focusable widge…

There I just added a new trait that is both Widget + Focus:

trait FocusableWidget: WidgetRef + Focus {
    fn boxed(self) -> Box<dyn FocusableWidget>
    where
        Self: 'static + Sized,
    {
        Box::new(self)
    }
}

And defined a form which uses it:

#[derive(Focus, FocusContainer)]
pub(crate) struct Form {
    pub(crate) children: Vec<Box<dyn FocusableWidget>>,
}

Fill it with some widgets:

    let mut form = Form::from_iter([
        Label::new("Label 1:").boxed(),
        TextBox::new("Text 1").boxed(),
        Label::new("Label 2:").boxed(),
        TextBox::new("Text 2").boxed(),
        Label::new("Label 3:").boxed(),
        TextBox::new("Text 3").boxed(),
    ]);
    form.focus_first();

Which is then rendered:

impl WidgetRef for Form {
    fn render_ref(&self, area: Rect, buf: &mut Buffer) {
        let areas = Layout::vertical(vec![Constraint::Length(1); self.children.len()]).split(area);
        for (child, area) in zip(self.children.iter(), areas.iter()) {
            child.render_ref(*area, buf);
        }
    }
}

The ability to just slap form fields into a vec like this and be able to produce a rendered form is what I’m talking about when I suggest that WidgetRef is a useful abstaction. This wouldn’t be possible to build with the no Widget traits approach.

[Nickel]

I think we can all agree that having a WidgetRef-like trait would be a good thing (as long as it isn’t required), but we are trying to decide on what the naming convention for it should be. If we were to change the name, it would take 5+ years to depreciate the old name, which means we can’t use the Wdget trait in a way that makes more current sense.

I think the rest of this discussion has been on whether Widgets are required to use the crate (they aren’t) and their existence confusing new users. (Personally I would like to see several examples without the Widget trait explaining the use cases for the Widget trait)

Correct me if I’m wrong though.

[kdheepak]

( I just wanted to say to everyone thanks for the engaging discussion and thanks for taking the time to articulate your thoughts and explore these ideas in so much detail! )