So, yesterday I decied to give the UI Toolkit a try and create a Custom Property Drawer for a class I have in my project that I use in a lot of places, but the default inspector for it is very confusing to use. I followed some tutorials, created a test custom inspector and finally felt ready to create my own custom drawer. Except… Apparently you can only use Custom Property Drawers made with UI Elements inside a inspector built with UI Elements, which seems like it’s not the case for the default inspector Unity creates for all Monobehaviors!
I remember seeing in some UI elements presentations at Unite people saying the new Unity UI was entirely made with the new UI Elements, which then seems to either be a lie or I’m understanding something wrong.
After searching for a while, I found this thread from last year saying exactly what I told earlier: Unity’s default inspector for Monobehaviors doesn’t use UI Elements yet, which I find very weird that it STILL doesn’t use it! I mean, from what I remember, Unity said UI Elements are ready for production for creating custom inspectors and editor windows, but you can’t make a custom property drawer without rewritting all inspectors that uses that property? How does this makes sense?
Now, in the thread, they do provide a script to “redraw the default inspector while we wait for the real thing”, which is a workaround, but again, I need to create this script for all scripts that use my property! And it’s been almost an year since they provided that, and STILL no default inspector with UI Elements? That sounds like a bigger priority than runtime UI, if you ask me.
So, any idea on where is this gonna be impremented? It was just a bummer to find this out when I finally decided to try it, and the only way I can make it work is to use a hacky method…
Are you sure you didn’t misunderstand the re-drawing the default example? They replace the base editor so every inspector would now be the ui elements inspector version. I’m not following on the “Create one for every inspector that uses a specific property”
( not to detract from the point of unity fixing this natively )
I don’t think so. The script provided in this post only works if you create another script defining which monobehavior’s inspector to override, as stated in the post itself. And from my tests (which includes using the UI Elements debugger), I was only able to make it work by doing exactly that. That means if I have a custom property “X” and I use it on scripts “A” and “B”, I have to then create both “EditorA” and “EditorB” in order for it to show my property (otherwise, it shows the message “No GUI implemented”). Also, I noticed that, by using this approach, the inspector loses some of its functionality (like object reference icons and the possibility of being able to click the script name to highlight it in the project view).
Also, I was not able to make the script on this post work (which, according to the post, should override every object inspector, but the UI elements debugger shows that all inspectors are still using IMGUI).
But DO correct me if I’m just being dumb and are making things wrong.
Unfortunately you’re right, the default inspectors are still using Imgui. However, using the DefaultEditor mentionned in the post you linked, will create UIToolkit PropertyFields for components that don’t have a custom editor defined. Keep in mind that most built-in Unity components do have custom editors and most of them are using imgui.
Also, if a custom editor using imgui uses EditorGUI.PropertyField, while it would pickup your custom property drawer, it would need to use its IMGUI implementation (OnInspectorGUI) and not UIToolkit’s. This limitation comes from the fact that we can embed IMGUI content inside a VisualElement hierarchy using IMGUIContainer, we can’t do it the other way around. Once we’re in IMGUI land, we’re stuck there.
Nope sorry I had just saw the default inspector code and wanted to make sure you had seen it to explore it as an option. I hope you get it all figured out!
Yeah, I know that, you explained that on the other thread.
I don’t mind that the built-in components from Unity still uses IMGUI, since I think it’ll be very rare for someone to try adding new functionality to these inspectors, but for custom monobehaviors and properties, that’s two of the most commom cases for someone to want to make a custom inspector. I just think it’s weird that we still don’t have this ability available, but you guys are already focusing on Runtime UI. I mean, I bet if I ask you when this is gonna be available, you won’t even have an idea of a date, but If I ask when runtime UI using UI toolkit will be available, you guys even have a roadmap for it! Seems like the wrong order of priorities here.
Yeah, I get people are more excited for Runtime UI than custom editors, but this feels like it should be a thing you should’ve already implemented because, from my point of view, the only real use for UI Toolkit right know is to make full custom tools.