Yoga implementation Part 1

[IceReaper]

For an example what exactly Yoga is, and how it works, see: https://yogalayout.com/ and https://yogalayout.com/docs

Basically all old Bounds stuff is completely replaced by a proper layout engine, which supports basics like margins, borders, padding and min/max and preferred width/height attributes.
Additionally the parent / child relation has to be tied to the yoga library to properly calculate element positions.

Notice:
This PR ensures the old ui yaml files will still work as before. To ensure compatibility, the layout calculation method is way more often called as it should be. These additional calculation calls will be replaced in the future along with the change of the yaml files towards yoga based setups. In the end there should be exactly 1 call to the root widget before drawing the ui. Everything else will be refactored.

Whats not part of this PR:

• Refactor all the chrome yaml files to make use of the flex layouting engine.

Feature ideas for the future:

• addition of more css styles for gradients, shadows, border images, font, etc.
• Implementation of "classes" which can be used to group the style of widgets ".myclass", "myWidgetType", ".myClass .myChildClass" ...
• Implementation of "pseudo-classes" to implement style overrides for widget states (:hover, :active, ...).

[pchote]

A few more broken things in TD:

• Dropdown menus
• Color picker color-watches
• Lobby player and options bins
• Button positioning on the "leave mission dialog"

[IceReaper]

Refactored the visibility part, above broken items should be automatically fixed by that.

[IceReaper]

I've included an overhauled mainmenu.yaml relying purely on yoga layouting as an example how future uis will work.

[pchote]

Having this and IsVisible as distinct things feels quite weird IMO, but I don't have any immediate alternatives to suggest.

[IceReaper]

The main problem here is to allow the old ui to work unaltered. Over time, the old ui will be refactored to rely on yoga features only and we can get rid of those workarounds. In the end this can be cleaned up when we no longer need to provide maximum compatibility with the old setup. The problem is actualy, that Nodes must be visible in order to calculate their layout bounds, which is totaly fine on a pure yoga layout, but as long as we manualy set and directly use bounds for further bounds calculations, i had to hack in several visibility and layouting calls to make sure the old ui properly works. the perfect example is a dropdown, which template widget is not visible, resulting in all clones to not have any bounds. As as conclusion, the end-goal would be to get rid of all the manual calculations, and to refactor the visibility code towards updating the display prop in the layout method.

[pchote]

My expectation/assumption was that clones would copy the string-based definitions (X, Width, etc) and then set their layout based on these values rather than the computed layout of the template. Is there something stopping this from working?

[pchote]

Is it possible to keep the current IsVisible stuff as it is, but then introduce a new ComputeLayout pass to Widget that evaluates IsVisible to update the yoga visibility and recompute layout before rendering?

[pchote]

I'm wondering whether the solution to making progress here might be to refactor out an IWidget interface, and then create a set of duplicated *YogaWidgets that don't have to worry about maintaining two YAML APIs at once. We can then migrate file-by-file by replacing e.g. Button@FOO with YogaButton@FOO and updating the yaml properties to match.

The duplication isn't nice, but neither are any of the other workarounds that we've brainstormed wrt backwards compat. At least this way we could go straight to the final YAML properties without risking regressions in places that haven't yet been ported, and then simply delete all the old widgets once the migration is complete.

[abcdefg30]

What is the status here?

[pchote]

IMO its sad that a lot of @IceReaper's PRs end up sitting idle because they don't get the needed engagement/support from the reviewer side. The last 6 months have been very bad for me, but things are a bit clearer looking forward - if there are no objections then I am thinking I might start with some PRs towards #18151 (comment) during the next release cycle to try and help progress with this feature.

[abcdefg30]

Closing since there is not much to do in this PR if we want to move forwards with several smaller PRs (and also no activity).