Is there a plan for a string-less workflow in UI Toolkit?
I’ve only briefly used it so perhaps it’s already possible and I’m just missing something, but from what I understand the way you grab specific elements is through their name/id by doing a Query
rootVisualElement.Q<Button>("myButtonId");
Is there any way to get an object reference without a string?
Some way to drag the reference directly in the editor?
Or perhaps like the Input System, some way to automatically generate a C# class with fields that have a direct reference?
There is no such workflow in UI Toolkit at the moment, no. Main optimization you can do is to cache query results in variables so you don’t have to keep querying every time you need an element. In general, it’s difficult to serialize references to VisualElements because they are not UnityEngine.Objects. They have no unique identifiers either. This thinking here is that most VisualElements will never need to be known by scripts. They are just for visuals and layout.
Also, on the styles side, all reusable styles via USS (StyleSheets) are exclusively matched by strings. There’s no getting away from that. Once the matches are made, we do heavily optimize and cache these styles under the hood, but the initial match is still the string.
Is there a specific use case you have in mind where this is a problem?
Is there a specific use case you have in mind where this is a problem? […] They are just for visuals and layout.
Will it ever be possible to use the physics system with UIToolkit?
At the moment, you cannot add a collider to a VisualElement.
Of course, one could create a GameObject for each VisualElement, but that’s duplicating the UI for physics purpose.
I fear, if people cannot do everything with UIToolkit that they can do with uGUI right now, then uGUI will never become obsolete and the UI in Unity will never be unified.
They have no unique identifiers either.
Maybe re-use the element id (you called it “name”, I know multiple elements could use the same value).
If there are mutliple elements with the same id (again, I mean the “name” attribute), reject it and throw an error that the user has to fix.
I don’t have a use case.
But others need physics, otherwise you would not have implemented 2d colliders.
In the long run (say 30 years from now), I expected UIToolkit to be the only needed in-game UI for Unity games. Therfor, it has to be able to do everything that uGUI can do.
Is this not the goal?
Should UIToolkit replace uGUI at some time in the future?
Or will UIToolkit and uGUI continue live side by side, each having their own use case?
It’s not so much that we have no “way around this problem”, it’s more that VisualElements were never designed to be uniquely identifiable. It’s actually a feature. It means you can clone your UI indefinitely and all the styles and callbacks would match on the clones the same way. So it’s a bit difficult to create a unique identification system while also preserving the advantages the lack of one provides.
2d colliders are for 2D graphics. It’s important to draw a line between “UI” and “2D graphics/gameplay”. While UI is (mostly) 2D graphics, true, what makes it different is that it comes with a layout engine, specialized interaction behavior/events, and styling system. You can certainly combine UI with 2D graphics (just like 3D graphics), but then that’s what you have: a combination. The 2D Sprites would themselves have 2D Colliders, but the UI would not.
I can sort of see colliders for UI being useful for XR “pointers”, where you need full-on ray intersection computation, which you get for “free” with colliders. But that’s still a pretty specialized use case that warrants potentially specialized non-collider based implementations. I don’t think we’ll implement generic assignment of colliders to VisualElements just to have it.
Yes, the goal is indeed to replace uGUI with UI Toolkit. With that, you can also assume that we are aiming or full parity with uGUI. But it doesn’t mean we’ll have exactly the same priorities and focus. So the two frameworks might have the same features, but not at the same level of detail.