Property Drawers

This is Unity 2021.2.1, and we're approaching the 3 year anniversary of broken PropertyDrawer in UIElements, what happened?

 

Is this what you need? Added in 2022.1.0 Alpha 13

• UI Toolkit: Added UI Toolkit implementation for property drawers.
  

 

That's good news at least

 

Sounds like a useful workaround but not very maintainable. Are there any plans to reference visualassettrees more easily and “unity like” so we can design our property drawers in UI builder?

 

I made a Property Drawer like so:

Code (CSharp):

1.     [CustomPropertyDrawer(typeof(PIDValue))]
2.     public class PIDValuePropertyDrawer : PropertyDrawer
3.     {
4.         public override VisualElement CreatePropertyGUI(SerializedProperty property)
5.         {
6.             var uiRootAsset = AssetDatabase.LoadAssetAtPath<VisualTreeAsset>("Assets/PID/Editor/PIDValueUI.uxml");
7.      
8.             var uiRoot = uiRootAsset.CloneTree();
9.  
10.             uiRoot.BindProperty(property);
11.      
12.             return uiRoot;
13.         }
14.     }

Then I made an editor wrapper like @pirho_luke suggested:

Code (CSharp):

1.     [CustomEditor(typeof(MonoBehaviour), true)]
2.     public class ImguiToToolkitWrapper: UnityEditor.Editor
3.     {
4.         public override VisualElement CreateInspectorGUI()
5.         {
6.             var root = new VisualElement();
7.        
8.             var prop = serializedObject.GetIterator();
9.             if (prop.NextVisible(true))
10.             {
11.                 do
12.                 {
13.                     var field = new PropertyField(prop);
14.  
15.                     if (prop.name == "m_Script")
16.                     {
17.                         field.SetEnabled(false);
18.                     }
19.                
20.                     root.Add(field);
21.                 }
22.                 while (prop.NextVisible(false));
23.             }
24.  
25.             return root;
26.         }
27.     }

So far I've not really run in to any issues. This should also be really easy to code-gen (make a template file and just replace the type names) should the boilerplate be too much.

 

@PeppeJ2 you can just create this editor as a base class, and inherit from it every time you have a new type that needs the property drawer. Then it's just 2 lines of code, not a full template.

But I still wasn't happy, because the point of a property drawer is to avoid having to make any editors that serve no other purpose than contain the properties.

With 2022.1.0 Alpha 13 though, property drawers are still working as advertised again (if the rumors are true) .

 

Looks like this is still a problem and it's really inconvenient right now. I'm using 2022.1.a12

 

Since the fix, now mentioned multiple times in this thread, is in 2022.1.0 Alpha 13, it makes sense that the fix was not there in alpha 12.

 

I hope this "fix" will soon see its light in 2021, otherwise what a joke this is. Are we supposed to upgrade to 2022, which won't see an LTS version for another 1.5 YEARS in order for property drawers to work properly? Hasn't UIElements been in development for years?

 

Hi, in this method "CreatePropertyGUI" is no way to access the custom label and tooltips in PropertyField.
I post this question from: https://forum.unity.com/threads/how...rawer-createpropertygui.1184404/#post-7603942

 

Hi, is there really no one met this problem?

The label of a PropertyField can not pass to a custom PropertyDrawer.CreatePropertyGUI. But it has duty to create a label. So the only way to get label is from the SerailizeProperty, but not the PropertyField specified label.
This behaviour is different from the OnGUI version and not correct.

 

CreatePropertyGUI and OnGUI are alternatives. The first one works with UI Toolkit, the second one works with IMGUI. I don't see why you would want both, or why you would pass data between them. In UI Toolkit, the label is a child VisualElement of the PropertyField. The label VisualElement has a text property.

Correct me if I misunderstood.

 

I am not need both, it want to use the 'CreatePropertyGUI' to implement the same ability as the 'OnGUI' could be.
For example, when I use ‘OnGUI’ I can write this code to specify a custom label:

Code (CSharp):

1.  
2. EditorGUILayout.PropertyField(prop, new GUIContent("My Custom Label"));
3.  
4. class MyCustomPropDrawer : PropertyDrawer
5. {
6.     public override void OnGUI(Rect position, SerializedProperty property, GUIContent label)
7.     {
8.         EditorGUI.Label(position, label); // label = "My Custom Label"
9.     }
10. }
11.  

But when I use the UIElements, there is no way to get the label:

Code (CSharp):

1.  
2. <?xml version="1.0" encoding="utf-8"?>
3. <engine:UXML>
4.     <editor:PropertyField label="My Custom Label" binding-path="prop"/>
5. </engine:UXML>
6.  
7. class MyCustomPropDrawer : PropertyDrawer
8. {
9.     public override VisualElement CreatePropertyGUI(SerializedProperty property)
10.     {
11.         var root = new Label();
12.         root.text = property.displayName; // This is not "My Custom Label"
13.         return root;
14.     }
15. }
16.  

There is no way to get the label specify in the uxml(As it can specified in EditorGUI.PropertyField)。

 

SerializedProperty is not a UI Toolkit thing, it's unitys internal serialization.

To get a hold of the label you have there you need to load it from file, like this:

Code (CSharp):

1. var visualTree = AssetDatabase.LoadAssetAtPath<VisualTreeAsset>("Assets/RW/Editor/PresetWindow.uxml");
2. VisualElement labelFromUXML = visualTree.CloneTree();

Then you can return that.

Or you can build it from code, like in this example: https://docs.unity3d.com/ScriptReference/PropertyDrawer.html

 

I means if I use the PropertyField widget in UIElements, to display a SerializedProperty with custom PropertyDrawer. If the PropertyDrawer implement the CreatePropertyGUI, it have no way to get the correct label provide from PropertyField.

What I want is the label specified in the UXML, but not the only, specified UXML. I want to get the label specify in any PropertyField.

For example I have a class name 'A' with a PropertyDrawer. And I use A in more than one place, give it custom name in custom editor(not the variable name from SerializedProperty). I need a way to get the label, just as the OnGUI last parameter.

Just like the 'label' parameter in this method:

public override void OnGUI(Rect position, SerializedProperty property, GUIContent label);

I need the 'label' parameter in this method:

public override VisualElement CreatePropertyGUI(SerializedProperty property, GUIContent label);

 

Aha, now I've understood your problem, at least

Before the UI Toolkit propertydrawers became default, this is what I used as editor base class, to enable UIElements property drawers:

Code (CSharp):

1. using UnityEngine.UIElements;
2. using UnityEditor.UIElements;
3.  
4. public class UIElements_DefaultEditor : UnityEditor.Editor {
5.  
6.     public override VisualElement CreateInspectorGUI() {
7.         var container = new VisualElement();
8.  
9.         var iterator = serializedObject.GetIterator();
10.         if (iterator.NextVisible(true)) {
11.             do {
12.                 var propertyField = new PropertyField(iterator.Copy()) { name = "PropertyField:" + iterator.propertyPath };
13.  
14.                 if (iterator.propertyPath == "m_Script" && serializedObject.targetObject != null)
15.                     propertyField.SetEnabled(value: false);
16.  
17.                 container.Add(propertyField);
18.             }
19.             while (iterator.NextVisible(false));
20.         }
21.         return container;
22.     }
23. }

In this case it does not seem like setting propertyField.label will create a label for me, even when I set it from the editor code. I don't know what's going on with that.

 

In the source code it try to invoke 'CreatePropertyGUI' first:

Code (CSharp):

1.  
2. customPropertyGUI = handler.propertyDrawer.CreatePropertyGUI(m_SerializedProperty);
3. if (customPropertyGUI == null) {
4.     customPropertyGUI = CreatePropertyIMGUIContainer();
5. } else {
6.     RegisterPropertyChangesOnCustomDrawerElement(customPropertyGUI);
7. }
8.  

In the 'CreatePropertyIMGUIContainer', it pass the label into it, but the label is not pass to 'CreatePropertyGUI':

Code (CSharp):

1.  
2. private VisualElement CreatePropertyIMGUIContainer() {
3.     GUIContent customLabel = string.IsNullOrEmpty(label) ? null : new GUIContent(label);
4.     return new IMGUIContainer(() => {
5.         EditorGUILayout.PropertyField(serializedProperty, new GUIContent(label), true);
6.     });
7.  

So I think the unity need change it API to pass the label into 'CreatePropertyGUI'.

 

Read through the thread, seeing the custom editor workaround, seeing a mention of a fix having been implemented in 2022.1.0 Alpha 13, but still seeing the same issue in 2022.1.0b14


To my understanding, b14 should contain fixes from a13 correct?

 

Well. One way or another, I've updated to 2022.2.0a9, the bleeding edge.
`CreatePropertyGUI` now works as expected, without the need of a custom editor.

Who needs API stability when they're just an hobbyist indie dev?

 

I remember the UIElements can embed an OnGUI. But OnGUI can not embed UIElements. If the PropertyDrawer is used inside another OnGUI editor, with only `CreatePropertyGUI` but no 'OnGUI', it looks like this.

 

I appreciate all the useful input from everyone on this thread. It has been some time since I used Unity and wanted to reacquaint myself with the new tooling provided in that timespan. Learned quite a bit about some of the pitfalls of using the UI Toolkit API... after hearing about this years ago!

I wanted to create some customized PropertyDrawers and Editors only to find that the new UI Toolkit, confusingly in the UnityEngine.UIElements and UnityEditor.UIElements namespaces, only work properly in the latest alphas of 2022.2.x + ... I was able to get them working after reading this thread.

A simple, serializable class...

Code (CSharp):

1. using UnityEngine;
2.  
3. [System.Serializable]
4. public class FollowPoint
5. {
6.     public string name;
7.     public Vector3 offset = Vector3.zero;
8.     public Vector3 lookAt = Vector3.zero;
9. }

The property drawer for said class...

Code (CSharp):

1. using UnityEditor;
2. using UnityEngine.UIElements;
3.  
4. [CustomPropertyDrawer(typeof(FollowPoint))]
5. public class FollowPointDrawer : PropertyDrawer
6. {
7.     public override VisualElement CreatePropertyGUI(SerializedProperty property)
8.     {
9.         VisualTreeAsset vta = AssetDatabase.LoadAssetAtPath<VisualTreeAsset>("Assets/Resources/UI/XML/FollowPointDrawer.uxml");
10.         VisualElement ve = vta.CloneTree();
11.         return ve;
12.     }
13. }
14.  

I was getting an error using the CloneTree method example provided on the Load UXML from C# scripts page. An argument of null is ambiguous between the other overloaded methods, so I didn't pass any parameters.

Is this minimal example correct usage?

 

I think you'd want to:

Code (csharp):

1. VisualElement ve  = vta.CloneTree(property.propertyPath);

Otherwise you'd have to go through the sub properties (name, offset, lookAt) one by one and bind them by hand.

 

Is there a better way to reference the visual tree for a property drawer yet? rather than a hard-coded path?

 

Property drawer with UI Toolkit following instructions in documentation is still not working for me in 2022.1.16f1, only showing "No GUI Implemented". Are the docs ahead of the editor?

 

Hi @uDamian , any chance that UI Toolkit custom propertyDrawers for default inspector will be supported in Unity3D 2021?

 

How would that base class look? Couldnt make it work either way

 

It is showing "No GUI Implemented" for me in 2022.2.1f1 =/

 

Maybe it because the UIElements implemented PropertyDrawer can not invoked by OnGUI. You need implement both the UIElements and OnGUI implement for a PropertyDrawer?

 

idk...

I have just created an empty project using Unity 2022.2.1f1, and the Inspector is being drawn using IMGUIContainers.

According to the release notes, it should use UIToolkit elements (Label/Box/etc).

 

I just found the issue:

I had this somewhere in my codebase:

Code (CSharp):

1. // Required for the fetching of a default editor on MonoBehaviour objects.
2.     [CanEditMultipleObjects]
3.     [CustomEditor(typeof(MonoBehaviour), true)]
4.     public class MonoBehaviourEditor : UnityEditor.Editor { }
5.  
6.     // Required for the fetching of a default editor on ScriptableObject objects.
7.     [CanEditMultipleObjects]
8.     [CustomEditor(typeof(ScriptableObject), true)]
9.     public class ScriptableObjectEditor : UnityEditor.Editor { }

And it was forcing my drawer to use OnGUI. Not sure why though.

 

Code (CSharp):

1. [CustomEditor(typeof(UnityEngine.Object))]
2. public class DefaultUIElementsEditor : Editor
3. {
4.     private const string script_property_name = "m_Script";
5.     public override VisualElement CreateInspectorGUI()
6.     {
7.         var root = new VisualElement();
8.         var iterator = serializedObject.GetIterator();
9.         if (iterator.NextVisible(true))
10.         {
11.             do
12.             {
13.                 VisualElement propertyField;
14.                 if (iterator.propertyPath.Equals(script_property_name) && serializedObject.targetObject)
15.                 {
16.                     propertyField = CommonUIElements.CreateDisabledClickableObjectField(
17.                         iterator.Copy(),
18.                         obj=> AssetDatabase.OpenAsset(obj),
19.                         out _);
20.                 }
21.                 else propertyField = new PropertyField(iterator.Copy()) { name = $"PropertyField: {iterator.propertyPath}" };
22.                 root.Add(propertyField);
23.             }
24.             while (iterator.NextVisible(false));
25.         }
26.         return root;
27.     }
28. }
29. ... (following is in another static class for shorthand)
30. public static VisualElement CreateDisabledClickableObjectField(
31.     SerializedProperty objectReferenceProperty,
32.     Action<Object> doubleClickAction,
33.     out ObjectField underlyingField)
34. {
35.  
36.     var objectField = new ObjectField(objectReferenceProperty.displayName)
37.     {
38.         value = objectReferenceProperty.objectReferenceValue
39.     };
40.     objectField.SetEnabled(false);
41.     var clickableContainer = new VisualElement();
42.     clickableContainer.Add(objectField);
43.     clickableContainer.RegisterCallback<MouseDownEvent>(evt =>
44.     {
45.         if (!objectField.value)
46.             return;
47.         EditorGUIUtility.PingObject(objectField.value);
48.         if (evt.clickCount == 2)
49.             doubleClickAction?.Invoke(objectField.value);
50.          
51.     } );
52.     underlyingField = objectField;
53.     return clickableContainer;
54. }

I've slightly improved your awesome Default UIElements Editor: added an actually functional Script field (clickable), also there is no need to have 'fallback = true' parameter because it sometimes breaks the inspector.

 

This is the topic of my days. Not specifically in regards to drawing default properties, but more about IMGUI vs UIT support and performance across Unity versions. TLDR: I want to create a tool with a wide support across versions to reach as many users as possible. Therefore I have created it in IMGUI as a custom property drawer in 2020 LTS. However because I need the inspector responsive, I am using Repaint, which generates GC Allocations. The GCs are ok in 2020 LTS (around 24 kb) but each major Unity release increases this significantly probably due to the transition to UITK - in 2022 it's 4x and in 2023 beta it's almost 10x higher than 2020 LTS.
Full story: https://forum.unity.com/threads/inspector-repaint-and-gc-allocations-in-unity-versions.1402837/

So naturally I wanted to remake the tool in UITK, but struggling with wide editor support. I enabled support for UIT alternative for Unity versions older than 2022.2 by using code in this thread, and it stops working correctly at 2020 LTS where the behavior is a bit different. So for older versions I wanted to retain the IMGUI implementation. Could you please answer or give any insight for the following issues?

1) Is this workaround a bad practice for a public editor tool?

Code (CSharp):

1. [CustomEditor(typeof(UnityEngine.Object))]
2. public class DefaultUIElementsEditor : Editor
3. {

It seems that this affects all drawers and can have undesirable impact or conflicts in people's projects.

2) I have enclosed the workaround in

Code (CSharp):

1. #if UNITY_2021_3_OR_NEWER

so that in older versions the default IMGUI alternative is drawn. Is there a better way of making the alternatives coexist across editor versions?

3) Or perhaps, should I even be worried about GC when constantly repainting the inspector?

Thanks for any insights!

 

This is a solution suggested in this thread. I am not using it currently because my use case is a public tool.

 

That's good to know! Thanks. However the question stands - in general, causing constant 25 kB GC by my inspector tool is ok? In the meantime I optimized it a lot and I'm only repainting when dragging things, but I want to keep a fully responsive mode as an option (25 - 50 kB GC depending on Unity version).

 

This is a common workflow. A good example is Odin, which does this. We have also done it for our own games earlier, though we haven't had the need in the last game, so I'm not 100% clear on the details anymore.

Usually what you do is to define your own inspector for everything, and then you use reflection or some other means to figure out what inspector is defined for the thing, and use that if it exists, so you don't override the BoxCollider inspector.

The reason to override all custom inspectors is twofold:
- The ability to make a custom editor that targets builtin types that doesn't have a type you can target - either because the type is internal, or because it's not got a proper type. The primary example is making custom editors for folders. That can be useful to set up metadata about how the stuff in the folder should be treated by other systems (like importers), and in some cases it's useful to have a custom view for the data inside the folder.

- Support for more kinds of attributes. This is what Odin does, and it's relevant for other workflows. Unity has a very attractive way of defining custom editors through the use of attributes instead of creating your own custom editor, but that workflow is very limited - PropertyFields for attributes has this annoying thing where it targets elements of an array, having the different attributes know about and react to each other is a pain, but totally necessary if say one changes how things are drawn and another conditionally hides it.

 

For a private project it sounds good, and Odin is about overriding all inspectors in some way or another. The original question is whether this is a good practice for a use case where a inspector tool with a custom drawer for public use could end up overriding all other drawers in people's projects, possibly creating issues and conflicts. As you seem to have a lot of experience with this, what's your take on this? Thank you!

 

Right, I was responding to Damian just to make sure we're clear on what people do. It's always worrying to see somebody from Unity going "does that even work?" when it's something we do a lot. It's especially worrying to see someone from Unity going "does that even work" when they're on the team responsible for that thing continuing to work.

But, yeah, to answer your question, overriding all editors is a pretty heavy thing to do! You probably don't want to do it unless there's a very clear benefit to the user. One thing to note is that you're probably making yourself incompatible with Odin, which is a very common tool - unless you're doing some kind of #if ODIN_INSTALLED thing. You're also adding overhead to people who want to both use your attributes and have custom inspectors - they have to inherit from a specific thing (which isn't the end of the world, but it's friction).

So I would avoid it if I could! But if you're making a very large set of tools (aka. you're an Odin competitor, or have something as intrusive), it could be worthwhile.

 

Yeah, that was my feeling too when I saw this suggestion. Wouldn't hesitate to do it this way in my own project, but for the tool, I actually decided not to do UITK version at all (for now) and rather implement it in a later update. Anyway thanks for the insights!