UI: Add initial UI support for ID pointers custom properties #110458
Customprops to IDs are supported since years through code, but were
never exposed directly in the UI of customporperties.
This commit mainly:
- Adds a new
DATABLOCKtype to UI customprops types.
- Exposes the exiting
id_typesettings to python API.
@JulianEisel will need your help to finalize and polish this I think.
But it would probably need better UX, like optionally grouping/filtering the IDs by type.
Nice! This should probably use the
IDPropertyUIDataID::id_type value to allow limiting the choice to a specific type. Also I think that type should probably be editable with the custom property edit operator.
- If drivers were to get a "Pick one from every ID in the entire .blend" drop-down, I don't think that should be default behaviour. Selecting type first, then ID, is much more intuitive imo.
- In the same vein, I agree that having a type selector for ID custom properties would also be desirable.
- Are ID custom properties allowed to have a default value other than a null pointer? I don't personally need this functionality, but I can see it being both useful and dangerous. (default values are usually quite hidden, and hidden ID pointers are icky).
- Since object names aren't unique, as soon as linked IDs get involved, the drop-down list should ideally also display the library path or .blend file name of linked IDs, in order to allow users to uniquely identify them by just looking through the list.
Updated the diff, removed the 'all ID types' changes/possibility for now (this would require quite some UI work in the ID template), added handling of the ID property
Don't have much to say about this, the little UI code that's here looks fine.
I would expect this to use a simple ID "search" instead of a template (without allowing for Fake User or Duplicate/Make Unique). Similar to how we refer to points elsewhere such as the UV Projection modifier, the set Material nodes, the objects we set in constraints, ...
Basically I don't think we have the option anywhere else in Blender to make a new datablock outside the context where the new data-block can be edited. And I don't see a strong reason to break that rule for the custom properties.
I think ID search is normally used for cases where the user count is not increased, like objects which exist only by being in the scene. For the general case I think showing the user count and fake user buttons is important.
I don't think we need a button to create a new datablock here though.
@brecht The only way to create new IDs here is by the implicit behavior of the user count button, which creates a single-user copy of the selected ID when clicked... AFAIK there is no way to prevent this behavior?
From @dfelinto's reply I got the impression it was possible to create a completely new datablock, but creating a single user copy seems fine to me.
In general this patch looks good, only two points.
- Editing an ID property always resets it to None, even when the description is changed, attached patch that resolves this issue.
- I'd prefer
DATABLOCKfor the enum.
I don't think another review iteration is needed, accepting.
No due date set.
No dependencies set.
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?