(On Hold) Rework Properties UI Editor #159

Demeter Dzadik · 2024-08-06T12:31:01+02:00

Demeter Dzadik commented

2024-08-06 12:31:01 +02:00

The first iteration of the Properties UI editor system was recently finished, and I am very happy with what it can do, but the implementation is a bit of a mess, and it has some limitations:

No nested panels
*No top-level panels
No way to put an operator on its own into the UI, without a property.
No way to put stuff in panel headers
**Cannot rename panels
**Cannot Duplicate elements
Either have to type in a sub-panel or select a parent property from a drop-down. But the drop-down doesn't have the panels, and the panels are never in a drop-down. So, moving a property to another panel is a different set of clicks from moving the property to another property, which is unintuitive.
Can't generate a driver from a property, accounting for its parents. Properties don't know who their parents are, and digging it out of the dictionary would be painful to implement right now.

*: The new system might not immediately enable this either, but in the future it could be added, using the old dynamic panel registration system. Don't really want to bring that back though.
**: These would be doable in the old system too.

The idea with the new system is to store all the UI data in RNA as a flat CollectionProperty of UIElement PropertyGroups, which can have a type (panel, subpanel, label, row, property, operator) and a parent element.

Done:

Separate properties in the pop-up for Bone Name, Collection Name, & Raw Data Path, for better UX.
Technically supports nested panels, although currently only round-about UX to achieve that.
Support operator-only elements
Able to chose UI element location with a drop-down, like before, but also including panels.
Can rename panels and labels.
Nested drawing now allows side-by-side properties to have children. The children will be listed below in several vertical lists.
Ability to add rows to existing labels with the + icon

TODO:

Auto-fill panel and label names if a parent was already selected before pressing the + icon
Batch Add
Re-ordering
Panels with properties or operators in its header (how tho?)
Duplicate element
Versioning
Auto-delete empty Rows.
Hide other empty elements (either only display in edit mode, or auto-delete those too)
Property drawing preview
custom prop edit op

I've decided to put this on hold for now, as adding more flexibility to the system results in major UX challenges. For example, should users be allowed to add empty panels and labels? They weren't allowed before, and they are not very useful.
If we only allow users to add Properties and Operators directly, and panels, labels and rows are added implicitly, how could the user define nested panels?

Should users be allowed to add properties without a Row element? If yes, what if they change their mind and want another property side-by-side with this one? How do they then create the necessary Row element? Or, if a Property must always be parented to a Row element, it becomes quite tricky to manage the implicit removal and addition of those Row elements.

Now that Operators are a separate element from Properties, the resulting editing buttons create a huge visual mess just from one property and operator being next to each other.

Overall, the data structure is definitely more flexible, but the UX to support that level of flexibility feels inferior to the current system. Maybe I'll revisit this in the future, if I feel that the current system's problems are significant enough, but right now, it's not broken, so I'll stop trying to fix it.

The first iteration of the Properties UI editor system was recently finished, and I am very happy with what it can do, but the implementation is a bit of a mess, and it has some limitations: - No nested panels - *No top-level panels - No way to put an operator on its own into the UI, without a property. - No way to put stuff in panel headers - **Cannot rename panels - **Cannot Duplicate elements - Either have to type in a sub-panel or select a parent property from a drop-down. But the drop-down doesn't have the panels, and the panels are never in a drop-down. So, moving a property to another panel is a different set of clicks from moving the property to another property, which is unintuitive. - Can't generate a driver from a property, accounting for its parents. Properties don't know who their parents are, and digging it out of the dictionary would be painful to implement right now. *: The new system might not immediately enable this either, but in the future it could be added, using the old dynamic panel registration system. Don't really want to bring that back though. **: These would be doable in the old system too. The idea with the new system is to store all the UI data in RNA as a flat CollectionProperty of UIElement PropertyGroups, which can have a type (panel, subpanel, label, row, property, operator) and a parent element. ----- Done: - Separate properties in the pop-up for Bone Name, Collection Name, & Raw Data Path, for better UX. - Technically supports nested panels, although currently only round-about UX to achieve that. - Support operator-only elements - Able to chose UI element location with a drop-down, like before, but also including panels. - Can rename panels and labels. - Nested drawing now allows side-by-side properties to have children. The children will be listed below in several vertical lists. - Ability to add rows to existing labels with the + icon TODO: - Auto-fill panel and label names if a parent was already selected before pressing the + icon - Batch Add - Re-ordering - Panels with properties or operators in its header (how tho?) - Duplicate element - Versioning - Auto-delete empty Rows. - Hide other empty elements (either only display in edit mode, or auto-delete those too) - Property drawing preview - custom prop edit op ---- I've decided to put this on hold for now, as adding more flexibility to the system results in major UX challenges. For example, should users be allowed to add empty panels and labels? They weren't allowed before, and they are not very useful. If we only allow users to add Properties and Operators directly, and panels, labels and rows are added implicitly, how could the user define nested panels? Should users be allowed to add properties without a Row element? If yes, what if they change their mind and want another property side-by-side with this one? How do they then create the necessary Row element? Or, if a Property must always be parented to a Row element, it becomes quite tricky to manage the implicit removal and addition of those Row elements. Now that Operators are a separate element from Properties, the resulting editing buttons create a huge visual mess just from one property and operator being next to each other. Overall, the data structure is definitely more flexible, but the UX to support that level of flexibility feels inferior to the current system. Maybe I'll revisit this in the future, if I feel that the current system's problems are significant enough, but right now, it's not broken, so I'll stop trying to fix it.

Demeter Dzadik added 1 commit 2024-08-06 12:31:02 +02:00

New Props UI WIP: Data structure & drawing 3534faebd4

Demeter Dzadik added 3 commits 2024-08-09 02:07:00 +02:00

WIP add operator fd02c2e7eb

Ability to add basic elements and recursive-remove elements e3ec87b486

Ability to add properties to the UI 3ce0db6ce4

Demeter Dzadik added 6 commits 2024-08-11 02:34:11 +02:00

Ability to create a panel, label, and row all in one go, like before 0181297bcb

Handle texts, icons, different prop owner types e322ab8588

Get operators working 2cc2c3c54c

Ability to edit UI elements aeb89d2a7b

Fix nested drawing and deletion 391b0914cc