New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
render
methods should be passed context instead of buffer
#1044
Comments
A theme would be added to a widget before rendering like a border or character set is done. We shouldn’t mix render and widget configuration. Otherwise it’s interesting to explore this idea. |
I like the idea of adding a My only question is, how can we make it backwards compatible? I'm assuming it is not really possible to do it so. Maybe we can have a - render(area, buffer)
+ render(area, buffer.into()) Just throwing some ideas. |
For the average Ratatui user this change won't be breaking. For example, this code will remain unchanged: frame.render_widget(
Paragraph::new("Example of a paragraph that a user writes")
.alignment(Alignment::Center),
area,
); However, every Ratatui widget developer OR Ratatui user that implements the one of the widgets trait will have to update their code. Currently If we want to make a change to the impl Widget for UserDefinedWidget {
fn render<T>(self, area: Rect, buf: &mut T) where T: Into<Context> {
// ...
}
}
impl WidgetRef for UserDefinedWidget {
fn render_ref<T>(&self, area: Rect, buf: &mut T) where T: Into<Context> {
// ...
}
} If we did this, any widget developer will be able to write |
Another reason a This will allow better interfaces for "focus". For example, |
This is definitely a good area to explore, but also one to do so conservatively. It would be easy to mistake the common elements that all apps need here. I think it's worth trying a few different ideas outside of ratatui (Edit: in a trait defined in an app) for this and seeing what works and enables the right use cases. The palette example makes me concerned as it implies a pretty big investment in making a design scheme (i.e. choosing the right pieces to palettize). I like that the buffer and frame count have a nicer place to live. To be clear, I want to see something like this in Ratatui long term definitely, but not done in a hasty manner which drastically changes things without building up the narrative around it first. It could be worth making this a discussion rather than an issue (the distinction being that an issue gets closed when done, while a discussion can be more long term). |
I agree that this shouldn’t be done in haste. I think frame count is probably the strongest motivation for this right now. |
The cursor would do it for me. And maybe some extra layers of buffers to render Hovers, Combobox and the like. |
Problem
Currently, there's no way for the render method to know additional contextual information that would be useful for widgets.
For example, frame count is currently unavailable to the render method. Additional features require more parameters to the method.
Solution
While
WidgetRef
andStatefulWidgetRef
are unstable, I'd like to propose aContext
instead of buffer.Context
can be defined like so:We can even have
Context
have the similar methods asBuffer
, and instead ofwidget authors would write the following instead:
The main advantage of this is that we can add features to
Context
in the future without breaking backward compatibility.For example,
Context
can contain a frame count.The main motivation for this idea was having a
Palette
inContext
. For example, ifContext
is defined as this:Imagine a
Palette
that is defined like so:Now, every widget's
render_ref
method can be passed a context that has palette information and we can make a Ratatui application styled automatically based on themes.There's probably more use cases for a
Context
(other user preferences like light mode / dark mode?) that we could expand on in the future if this feature was enabled.Thoughts?
The text was updated successfully, but these errors were encountered: