Trait for containers?

[mankinskin]

Could there be a trait for containers? There is an implicit pattern of containers implementing something similar to

fn show<R>(self, ctx: &CtxRef, add_contents: impl FnOnce(&mut Ui) -> R) -> InnerResponse<R>

for example CentralPanel, SidePanel, TopBottomPanel

but there is also

fn show(self, ctx: &CtxRef, add_contents: impl FnOnce(&mut Ui)) -> Response

Area

fn show<R>(self, ui: &mut Ui, add_contents: impl FnOnce(&mut Ui) -> R) -> R

Resize, ScrollArea

fn show(self, ctx: &CtxRef, add_contents: impl FnOnce(&mut Ui)) -> Option<Response>

Window

fn show<R>(self, ui: &mut Ui, add_contents: impl FnOnce(&mut Ui) -> R) -> CollapsingResponse<R>

CollapsingHeader

and both

fn show_ui(self, ui: &mut Ui, menu_contents: impl FnOnce(&mut Ui)) -> Response

fn show_index(self, ui: &mut Ui, selected: &mut usize, len: usize, get: impl Fn(usize) -> String) -> Response

for ComboBox

I'm sure this has already been thought about and i think it would make it easier to implement custom Ui containers, because it would be easier to know what you have to implement.

There seems to be a distinction between containers that add their own Ui and those that just wrap another and pass their responses right through. This seems to determine whether the method takes a &CtxRef or a &mut Ui and also what kind of response it returns. In general the response seems to be pretty generic, so maybe a Response trait would make sense too?

Maybe there are more abstractions needed here to make this clean, but I think these parts of the code are still very much implicit and not fully modelled out. That makes it kind of difficult to understand how the pieces belong together.

[mankinskin]

I have thought about it some more and I think the show methods are usually very individual and it is probably not clear yet where a useful common denominator lies.

[singalen]

I'd say it might be worth finding a common denominator.
Even if there isn't one for show(), maybe there are 2 or 3 kinds of Show traits that can be extracted here.

The same goes for min_height/max_height/default_height, resizable/drag_bounds, anchor/fixed_pos/current_pos, auto_shrink.

As a complete newcomer, I got an impression that containers lack unification, which can cause a further fragmentation of APIs.

[mankinskin]

yes, I had the same impression. I think the methods you mentioned would be very good starting points to integrate this pattern.

[emilk]

I think consistency is a higher priority than putting them under the same trait.

[mankinskin]

One advantage traits can bring is generic programming over types implementing max_width() or resizable() etc. This can help reuse a lot of code that just requires some type implementing these methods. Also it would enforce consistency by the compiler.

My approach would be to look for methods commonly implemented in the same way and to look for code duplication using different types implementing these methods. If that exists we would definitely benefit from implementing those methods with traits and calling them on abstract types in generic functions.