Page MenuHome

Support Marking Operator Properties as Basic or Advanced
AbandonedPublic

Authored by Julian Eisel (Severin) on Oct 14 2017, 7:12 PM.

Details

Summary

Support Marking Operator Properties as Basic or Advanced

With this it's possible to split operator properties into basic and advanced ones. This will be needed so top-bar can move advanced properties into a "More" popup. We agreed on supporting this during the 2.8 UI workshop (see https://wiki.blender.org/index.php/Dev:2.8/UI/Workshop_Writeup#Top_Bar)

How it works

The current implementation is a simple solution, but it's rather evil :)

All properties added after a call to WM_operatortype_props_advanced() are considered advanced.

Internally, this does nothing but counting and storing the items added so far, which gives a threshold between basic and advanced props. To draw properties separated in the UI code, I added WM_operatortype_is_prop_advanced (runs a loop over properties currently, shouldn't be a performance issue).

I'd mainly like to hear if this approach is fine, or if it's too ugly. If it's fine, I'll probably just remove testing code in interface_layout.c and commit to master.

For Testing

For testing, I made the redo panel draw only basic properties. And I also slit up draw-able properties into basic/advanced of a bunch of operators:

  • All transform operators in transform_ops.c
  • All VIEW3D_OT_snap operators (only one had properties)
  • Some mesh-edit operators (loop-cut, subdivide, mark seam, mark sharp, smooth vertex, laplacian Smooth vertex, merge)

Open Questions

  • How would this work for Python defined operator properties?
  • How should calling WM_operatortype_props_advanced() multiple times be handled? (E.g. calling once in TRANSFORM_OT_translate and once in Transform_Properties. Currently all properties added prior to the last call are considered basic)
  • How will we update operators to use this? Updating all operators would be a tedious task.
  • How should UI handly operators that only have advanced properties? A "More" button would be weird then. (More of a top-bar design question)

Diff Detail

Repository
rB Blender
Branch
temp-operator_prop_split
Build Status
Buildable 888
Build 888: arc lint + arc unit

Event Timeline

Julian Eisel (Severin) edited the summary of this revision. (Show Details)Oct 14 2017, 7:18 PM

(Summary of IRC discussion)

As a quick way to split out categories this seems fine.

From discussion on IRC if we add this, we will want to have Python support, which means we're not going to want to break the API later on.


For a longer term solution we discussed having named property tags.

This means we can have an advanced tag for UI where it makes sense. (other tags could be used for categories and auto-generating an interface).

Julian Eisel (Severin) updated this revision to Diff 9406.EditedOct 16 2017, 7:21 PM

EDIT: Please ignore, Arc updated this patch instead of creating new one.

Revert last update - wanted to open a new diff instead.

Submitted patch for the RNA property tagging support, D2883. It also contains an alternative solution for this patch here, that is, tagging of operator properties as basic.

We chose to go with an alternative solution (quite similar in some regards), see D2883.