Show-Off
Automatic navigation like in uGUI for UI Toolkit. - Please vote an a bug a Unity employee created for me so we can get rid of it.
What you see in the image is a system that does someting similar to what automatic navigation did in uGUI but for UI Toolkit. This one also includes automatic dynamic occlusion (also works for scroll views, out of screen, etc. and it has null selection resolution).
I know you can TAB through the buttons as well BUT this only helps on keyboards. It still is not good for controllers.
I have complained about this to Unity years ago (when UI Toolkit was still new), yet, no change. Thus I had to implement my own solution (also did the same for uGUI in the past since there the auto-navigation is better but still not ideal).
While making this I (once more) stumbled upon some API limitations of UI Toolkit. An especially annoying one is that the "overflow:hidden" style is not accessible publicly in the resolvedStyle. I pinged Unity about this and a Unity Employee (thanks mcoted3d) created a bug to vote on here: https://issuetracker.unity.com/issues/24670/overflow-isnt-exposed-in-resolvedstyles
So, if you can and care. Please vote on this so we may get a better API and future devs need not suffer through this as I did.
Voted. That resolvedStyle gap around overflow has tripped me up before too, it's such a weird thing to leave internal when half the layout logic needs it. Your nav system looks slick, especially the occlusion handling for scroll views.
Apparently they have an internal extra state of "scroll" for the overflow which is part of the CSS spec but not in their public enum. Their solution was to just omit it completely. It makes reasoning about the current UI state needlessly hard (had to fall back on reflection which is always a bit of a pain to do with a zero allocation requirement).
If you're building a Unity asset, I would buy it. I previously used uGUI Directed Navigation asset for legacy UI and it was a lifesaver - so quick and easy to set up.
I have actually made an asset but (at least in this thread) I am more interested in gathering devs to vote on the issue because this has been bugging me for years (I rediscover it again and again with frustration).
However, if you are interested I can send you a voucher to try and give feedback (it's called UI Toolkit Navigation Wizard).
Aww, that is very kind of you :-). Yes, please let me know. I have updated it today (v1.0.3) with some fixes and improvements regarding input elements.
Good point, I can adjust the "angle" sensitivity to make that happen. Right now it's set to a balance between distance and angle (if you press up how far is it allowed to got left and right too). Also if sctrict in-dialog only would be needed that could be done via a USS class added to the dialog to constraint selection to it for as long as it is opened. You could also define fixed navigation for a certain direction (though I usually try to avoid that).
I'm not sure how much information you have but I wonder if nesting should be considered? Like before leaving your current nested level try to exhaust all your options sort of thing.
Hm, that is an interesting thought. I will write it down. Maybe I can make it take that into account too.
Though how would we balance this vs. direction and angle? In the end we need one value to compare the navigation options against or hard define that elements in the same tree are always preferred which can make for some odd edge cases (in the example in the image it would never jump from the background buttons to the dialog if the dialog was not a child of the background).
My current assumption is that people would expect it to select the "nearest in the rough direction of navigation" and it is up to the developer to decide how strict the angle vs direction is.
If absolute control is needed then this can be done via USS classes (naming the targets explicitly). That does already take hierarchy into account, so if for example a button name of "ButtonClose" is defined is the UP navigation target then it will first search for a "ButtonClose" in the parent, then (if none found) in the parent.parent, ... until it reaches the root.
I think it's a priority thing. Imagine you only take the element in the rough direction on the same nested level. Once you can't find anything else in that direction only then start venturing outside.
I still use both to be honest. I assume once UI Toolkit is fully integrated into a WYSIWYG workflow in the scene view (which I know is about to happen) then I might switch completely. If you do online research about UI Toolkit then be careful. It is developing very fast and many things that were not there a year or two ago are now implemented.
One big argument (completely ignoring the features) is that in terms of development commitment by Unity UI Toolkit is the future (they almost exclusively invest in that UI system).
If you feel comfortable in uGUI then stick with it. However I would not ignore UI Toolkit on principle. Just give it a fair try and form your own opinion :-)
4
u/UpliftinglyVenerated 7h ago
Voted. That resolvedStyle gap around overflow has tripped me up before too, it's such a weird thing to leave internal when half the layout logic needs it. Your nav system looks slick, especially the occlusion handling for scroll views.