UI Layout Engine
All buttons windows will become generated based on a new "Layout Engine". Wintercamp reports on this topic:
Panels, Templates and Items
We can think of the UI layout consisting of 3 levels:
- Panel. These are collapsible and movable, and contain one or more templates.
- Template. This is a method to layout a number of items.
- Item. A single item in a template. Not always a single button, can expand to multiple for an array for example.
The kind of templates needed will become clear when laying out buttons, some ideas:
- ID Context/Browse
- Curve Mapping
- Transform Coordinates
- Default Header Buttons
- Preview Render
- Simple Collection Item
- Extended Collection Item
Items would be:
- RNA properties
- Icon/Text Label
If we allow editing of multiple datablocks simultaneously, this presents a number of challenges. Rather than a single datablock / RNA pointer, a collection of them would passed along.
- Single Button: If all values agree, display the value. If not, display a dash.
- If conditional on properties: If all values evaluate to true, run the code. If some evaluate to true but not all, something could indicate that there are more buttons not diplayed. If all values evaluate to false, do nothing.
- For loop over collection properties: the collections need to be merged somehow. A reasonable method may be to retain all items with the same name & type in all collections. If some items only exist in some collections, there could again be an indicator that some are not displayed.
Further some implementation issues are:
- In python then all conditionals and for loops should take this into account, and use utility functions or perhaps builtin collection mechanisms to work with collections instead of single datablocks.
- Each button should not store this full collection, so such collection can be shared and stored at a higher level.
- Displaying 1000 objects may get quite slow, how to avoid major slowdowns on an select all operations? Have a built-in limit, abort drawing buttons after timeout, ..?
Ideally we would like to do minimal redraws and minimal python code evaluation. Currently in 2.5 even button highlights do a full redraw, though this will be fixed with partial redraws. Doing partial redraws while editing is more complicated, if the UI updates interactively while editing the button it becomes difficult to know if this requires a redraw, though it could be reasonable to assume none is needed, also to avoid buttons moving around while editing them.
What the performance implications of python code evaluation are is hard to predict. In principle the python code could be run once and the layout tree stored. The difficulty with such an approach however is that also conditionals and for loops need to be part of the layout tree.