Open JCQuintas opened 2 months ago
An alternative solution to this that goes one step further is to create a container type that accepts widgets and constraints together. The recent addition of the WidgetRef
trait allows Box
ed widgets to be stored in containers alongside the contstraint. A PoC version of this is available in https://docs.rs/ratatui-widgets/latest/ratatui_widgets/stack_container/struct.StackContainer.html
let stack = StackContainer::horizontal().with_widgets(vec![
(Box::new(Paragraph::new("Left")), Constraint::Fill(1)),
(Box::new(Paragraph::new("Center")), Constraint::Fill(2)),
(Box::new(Paragraph::new("Right")), Constraint::Fill(1)),
]);
The one part this doesn't do is handle being able to use the areas for things like mouse click checks, but there might be a nice way to do that if designed right.
Note that ratatui-widgets is in an experimental state, with progress highly dependent on availability of inspiration and motivation. Feel free to borrow and adapt in your own app.
A third alternative is to write a proc macro that adapts some sort of syntax that makes variables and constraints easier to write together. Perhaps something like:
vertical! {
header => length!(1),
body => fill!(4, horizontal! {
books_list => percentage!(90),
books_test => percentage!(10),
},
footer = max!(5, horizontal! {
scroll_up => fill!(1),
scroll_down => fill!(1),
previous_page => fill!(1),
next_page => fill!(1),
}
}
There's probably some parts of this that can't easily work, or are better expressed some other way, and perhaps the tagged layout would be the underlying piece that would make such a macro possible to write easily. This could work well with some of the ideas in https://github.com/ratatui-org/ratatui-macros
Problem
I'm always struggling to name the variables results of calling
area(rect)|split(rect)
, as you have to do them in orderbigger elements
tosmaller elements
and make sure everything aligns.Example:
Solution
I would like a way to define the UI/Constraints in a single structure, and then
build/split
it only once. With all the constraints being automatically fed to the split/areas behind the scenes, in a way I have a simple way to access the resulting "tagged" areas/layouts.API Suggestion:
this could also allow parts of the UI be defined/built by different parts of the application, or on arbitrary orders, like in the example below, where we first thefine the smaller areas into variables, and only then build the main layout. So
smaller elements
beforebigger elements
. Which is the oposite way of the current api.Alternatives
Additional context