Trait-like styling for UI

[alice-i-cecile]

There are a few basic approaches I see to styling:

1. Individual styling only: you can only style a UI element locally
2. Fixed styles: you can define UI styles and reuse them, but there's no way to combine them
3. Inherited styles: as 2, but with an OOP-style hierarchy where the child styles override the parent
4. Trait-like styles: as 2, but using composition to combine styles

Approach 1 is clearly bad.

Approach 3 is very powerful, but tends to lead to horribly complex behavior and weird workarounds, just like other OOP.

Approach 2 avoids that, but then you need to write out a new style every single time you change a small detail.

Approach 4 seems like the way to go, but the devil is in the details: how do we handle conflicting fields?

This is the same phenomenon we see with the multiple labels approach proposed for the ECS (see #1375). You have several important fields, you want to set them in some reusable and composable way.

The most sensible approach, IMO, is to use the builder pattern. Apply the "style labels" sequentially, then overwrite other field values if they're already set. This gives you a really nice syntax and mental model, something like MyWidget.base_style().specialized_style() and lets you mix and match styles in a way that you can't with the inheritance approach.

Under the hood, I think what you'd probably want to do in Bevy is something like make each of those fields a component, and then use commands to apply the styles in order. I'm not entirely confident on that point; there are some issues with that due to the command-processing delay.

(lifted from Discord)

[colepoirier]

Hi @alice-i-cecile, there's two important snippets from the same discord discussion that I wanted to extract (let me know if this isn't the right way to do it). Also apologies if I've left too much in and should have pared it down more, I've done my best but my brain struggles with this kind of task, so feel free to give me pointers on this or edit it down as you see fit.

First snippet

CooCooCaCha:

One thing I liked about flutter is that it modularizes the layout algorithm in a clean way. For example, not every component has padding but if you want padding you can use the Padding component. That component contains the logic to compute padding.
Would that map to the trait-based styling approach?

What's also nice about the modular layout approach is that users can implement their own mini-layout algorithms

I'll keep using flutter as an example. So in traditional CSS you have a single layout algorithm that needs to take every possible CSS property into account. With flutter, the logic for padding is encapsulated in the Padding class. If you don't use the Padding class then that layout algorithm isn't executed. Same with flex style layouts

Cagey:

Alice's proposal is specifically about manually applying styles to things - we'd still have to build something to automatically choose what styles go where if that was something we wanted

Cole Poirier:

What about something like default labels Alice? Where there are certain default styles for UI components, but different from from how CSS cascading works.

I would strongly advocate against implementing CSS in bevy. There's a reason the decision was made to do a custom from the ground up UI system for bevy and not use VueJS or React or something else from the web GUI sphere. I think CSS is fatally and fundamentally flawed and we shouldn't tarnish the promise of bevy by tying that boulder around its neck. There's a lot that can be learned from the web; things that were done right as well as an abundance of anti-patterns.

Cagey:

I'm not suggesting re-implementing CSS

Alice:

I think the more common thing that you would do is make your own custom WidgetBundles with specific components set to default values, ideally with some nice way to create new bundles based on "X but with the following style labels applied".

Second snippet

Cole quoting Cagey:

Just saying that automatically applying styles based on hierarchy and view type is a feature we might want.

Can you elaborate on this?

Cagey

Like i might want buttons inside popups to be automatically styled one way, but buttons outside popups to be styled another
instead of manually choosing which, I could just have a rule that says "popup > button" for styling buttons inside popups

Alice:
This seems super easy with marker components and a styling system

CooCooCaCha:

An alternative is we could allow devs to define styling presets and provide a way to combine presets.
let button_style = Style::combine(vec![style1, style2, style3]);

Alice:

I think the builder pattern I discussed above is a bit clearer

CooCooCaCha:

True, either way as an alternative to selectors

Mdan:

Is there a way to query based on parent/child component relationship though?

S33n:

You can query for Parent, Children and slap marker components based on their relationships ahead of time

Mdan:

that makes sense, as long as the style definitions aren't dynamic

S33n:

I'd think it should work even if they were?
Since you're reacting to changes

Cagey

Then you need some logic for unapplying a style, which isn't super intuitive how to implement

S33n:

You'd need logic to re-build the style imo
Cagey:

I settled on applying a default style (which effectively unsets everything)

Mdan:

First pass - just discard and re-create the components when style changes?

[alice-i-cecile]

Cathartic notes from @plof27 on the problems with CSS and the trait-like styles proposal:

1. You still want a single global default for each styling component type. e.g. default font
2. Style wrappers from Flutter are the most sensible way to do inheritance, because it uses physical hierarchies. Probably not needed.
3. Some common style properties affect other components indirectly, which causes very painful precedence issues, even if they're not directly writing to the same component initially. This is probably unavoidable, but creates a lot of conceptual complexity. E.g. children's size vs. the box's size
4. CSS-style filters are bad: they cause cross-code dependency and exploding complexity. Just use the ECS.
5. Updating styles at run-times needs to be feasible, but isn't obvious how it would be accomplished. E.g. hovering over a button and the text becomes bold
6. Pixel measurements are painful, especially with variable DPI: use Transforms instead. They make absolute positioning much better.
7. Possible positioning styles: absolute (current GlobalTransform), parent-relative (current Transform) and percentile variants of the above
8. Interesting idea: align relative to any of the sides of the screen, to allow for more natural definition and adaptive scaling (Alice: relative to other objects too is really good)
9. Surprisingly difficult features: centering, put things side-by-side, automatic resizing to fill space.
10. Other issues with CSS:
    a) Units used are inconsistent, and vary across seemingly coherent parts of the API
    b) Property names and values are often unclear and non-obvious: Position property is the worst.
    c) Some properties inherit, and others don't, making the complexity issues with inheritance so much worse.
    d) Precedence for properties is defined in part by insertion order, causing a much worse variant of the same issue we saw pre-System sets and parallel executor v2 #1144.
    e) Many near-duplicate properties: partly due to point 3, partly due to backwards compatibility requirements.
11. Scrolling is extremely complicated, and one of the main arguments for a top-left coordinate system. We can quarantine this complexity.
12. Properties that are too atomic fail when you don't set the other properties correctly: flexbox has this issue. Related to Add position and rotation components to Camera entities #3.
13. Very much try to minimize cross-entity dependencies: e.g. issues with having to set properties on both the flexbox and its parent.
14. We need escape hatches for automatic positioning. Ideally this is made of composable systems that you can toggle on / off one at a time on a per-widget basis.

[alice-i-cecile]

A builder pattern snippet for defining styles:

struct DefaultStyle;

impl Style for DefaultStyle{
  fn appply(&self, widget: &mut Widget){
      widget
        .font("Times New Rome")
        .background_color("Blue")
        .text_weight("Medium")
  }
}

struct BoldStyle;
impl Style for DefaultStyle{
  fn apply(&self, widget: &mut Widget){
      widget
        .background_color("Red")
        .text_weight("Bold")
  }
}

// In some system
{
    widget.apply::<DefaultStyle>().apply::<BoldStyle>();
}

From me, on Discord.

[alice-i-cecile]

In order to support this, create a Styles component that every widget (entity with the Widget component) should also have.

Styles is an ordered list of Style trait objects (Vec<Box<dyn Style>>), which are applied in order. This should be handled internally in one of bevy_ui's systems, which rebuilds widget properties based on a Changed<Styles> query filter.

Changing the style of a widget should be done by appending to its Styles component, which is then automatically updated, rather than by directly modifying its fields. This should significantly improve predictability and composability of styling.

[colepoirier]

Ideas from #ui on discord today

CooCooCaCha: (https://discord.com/channels/691052431525675048/743663673393938453/818207087062155306)
Random idea from a rust noob. But what if the Style component contained a list of style structs where each struct contains logic for laying out itself and its children via dynamic dispatch.

struct Style {
  styles: Vec<&dyn Layoutable>
}

struct Padding(f32);

impl Layoutable for Padding {
  // some api that I haven't thought through.
}

// Somewhere else
commands.spawn(TextBundle {
  style: Style {
    styles: vec![Padding(16.0)]
  }
}

geom3trik: (https://discord.com/channels/691052431525675048/743663673393938453/818206481215127552)
Right yeh, this (#1205) is very similar to how I imagined an ecs ui system could work. I think I commented on it in my first comment on this server.

geom3trik: (https://discord.com/channels/691052431525675048/743663673393938453/818208145158438932)
Essentially you have components which define the behaviour of widgets. I'm doing something like this in tuix but not using an ecs. You have say a checkable component. Any widget with this component can be checked. Similar for buttons where they can be pressed. Movable could be another kind of component. You can add multiple components to a widget to make it presable, checkable and movable for example. The tricky part is how the systems should work because they need to run on a particular set of components but in a certain order defined by the widget hierarchy.

geom3trik: (https://discord.com/channels/691052431525675048/743663673393938453/818209917583884338)
My original idea was also to have behaviour as components. I called it handlers. So you could add additional behaviour to widgets with particular components. So imagine a textbox widget that just holds some text and adding a handler which adds a syntax highlighting feature or something. In tuix you can inherit widgets so that's how I do it but I could imagine an ecs way of doing it.

[hoj-senna]

Experiments with styling based on the idea with traits above: https://gist.github.com/rust-play/383c2b96fa97633e26fa3412f38eb12b

[jihiggins]

A simple version of styling based on lenses https://gist.github.com/jihiggins/d14774276fe0af48ae0beaeaf1050a34

[alice-i-cecile]

So, proper notes of what I'm thinking of for UI styles:

1. Each style-able widget is its own widget entity
2. Widgets can be composed of many sub-widgets
3. Each styling option (e.g. text settings, color, transparency, decorations) gets its own styling component. Eventually, these can be grouped together using archetype invariants.
4. Styling components have two fields: base and realized. base records information about the underlying default pre-styles, while realized is used for final rendering
5. Users can define styles, which are entities that store styling components, to be copied onto other widgets
6. Each widget entity has a Styles component, which stores an ordered list of the styles (in terms of entity ids) that should be applied to it. Eventually, this can be replaced with HasStyle relations, which store data about their relative order.
7. When this Styles component is changed, the realized field of each styling component is modified to match the corresponding base value of the matching styling component in the compile. This process repeats, from first to last, until all styles have been layered over top of each other. The list of styling components can be either a) inferred from the components on the styles, b) registered somehow c) inferred by the presence of a Styling trait using reflection

discussed on Discord