PropertyDrawer issue and suggestion

Unity Engine
1

If I have a PropertyDrawer implemented like this in IMGUI:

public override void OnGUI(Rect position,
    SerializedProperty property,
    GUIContent label)
{
    GUI.enabled = false;
    EditorGUI.PropertyField(position, property, label, true);
    GUI.enabled = true;
}

It seems like implementing a CreatePropertyGUI version with a PropertyField referencing the same property parameter will create a stack overflow. Is this just no longer possible?

I found it funny that the official tutorial just released skipped over this by making one specific to float fields instead of something more general.

As a more general query: I understand that a drawer like this will not be able to be combined with other property drawers in a nested fashion, being able to style another drawer as read-only. Is this something that could now be achieved with UIToolkit without too much hacking around (replacing the Inspector/Editor, etc)?
It seems like there could be a new modifier class similar to PropertyDecorator/Drawer that would pass in the root VisualElement of whatever was created after the drawers, that class could then modify it however it wanted.

Additionally, is there a PropertyDrawer API on the horizon? It seems like when you switch to the UIToolkit Default Inspector no decorators work, including the internal ones, and there is no indication of anything implemented internally.

2

It should definitely not cause a stack overflow. That is a bug. If you don’t mind, can you report it as a bug via the Bug reporter?

And you’re a bit reading our minds with your suggestion. We’re indeed looking at how to “nest” PropertyDrawers to add styling and additional details and functionality. I can’t share any specifics or ETAs at this time but it’s being looked at.

As for the state of UI Toolkit PropertyDrawers and default inspectors, we hope to see more progress on this next year. We’ve had to focus on getting Runtime support shipping and so the Inspector slipped a bit. This applies to both:

  1. Bringing up UI Toolkit to the same Inspector and PropertyDrawer/decorator functionality as IMGUI.
  2. Using UI Toolkit to draw the default Inspector, which is key for UI Toolkit-only PropertyDrawers to become viable. This has mostly been a performance problem with UI Toolkit having to create a lot of objects on first-layout which for large inspectors is still a problem.
1 Like
3

Wonderful, thanks for the reply, I was getting worried it wasn’t seen!
See Case 1292133 for my report.
It is a little sad as someone who’s been using UIToolkit for a few years now, that the IMGUI parity hasn’t changed that much, but I do appreciate the challenges of building a more cohesive API that can handle runtime and editor needs. I’ll just be very happy to see it when it comes, so much more opportunities to make cool editors!

I’m not sure what the forum etiquette for new threads is, but I also am finding the UIBuilder doesn’t work when trying to author content for packages in-place, ie. a non-read-only package that is a folder reference.
The builder just complains that the UXML/USS needs to be inside Assets, which seems like a requirement that should be expanded to add this use case.

Where’s the best place to raise issues like that, should I make forum threads or submit bug reports?

4

You can make a forum thread with the Feature Request mention.

By the way thanks a lot of taking the time to report issues and share your feedback with us.

5

The UI Builder does actually work with package assets. The main problem is that Open/Save File Dialogs which don’t know about the package virtual file system. It’s still very much a problem but only for opening (or saving as…) a UXML and adding/creating a USS to the UXML. If you instead just double-click on a UXML asset inside your package, the UI Builder will open with that UXML and everything should work after that, including Saving. You’ll also need to manually add additional USS files to a UXML in a text editor.

1 Like