Feature Requests

[AtomicBob]

While working on a new GUI system for a game, I came across a few things that I thought worthy of mentioning.

• Support for 'sticky selection' - I have a GUI system that will support a mouse and keyboard and controllers simultaneously. It ended up being problematic that you could potentially clear the current selection with the mouse (e.g. by clicking nothing) and then try to use the controller. With nothing selected UIKeyNavigation doesn't work. Maintaining a selection at all times didn't end up being too hard, but in order to keep things visually consistent I wanted to make sure the selected object is always highlighted as well. I ended up getting this working quite well, but it was a pain in the ass and I had to write a few ugly hacks to do it. Maybe there's already an easy way to do this, but I wasn't able to find it.
  
  
• The ability to treat axes more like buttons for UICamera Vertical and Horizontal. In UICamera, when the vertical and horizontal axes are read there is a hard-coded delay of .25 seconds between sending OnKey events. This works great for holding something down, but the delay is very noticeable if you try to do something like tap down on the dpad repeatedly. The way I solved this is by setting the gravity on an axis to match the sensitivity so the axis value will always go back to zero in a single frame. This allows me to do a simple sign check on the axis to see if it has been pressed this frame. Alternatively, I think a better way would be to watch the axis value and just reset the timer each time it moves closer to 0. This means the user has released the button/axis and the next time it moves away from zero is a new press.
  
  
• Support for non-trigger colliders. I'm integrating GUI into an existing game and the other devs are adamant that 'raycasts hit triggers' stay disabled. NGUI seems to work just fine when I change all my colliders to not be triggers. If there's no other issues involved, this may be as simple as setting auto-generated colliders to match the 'raycasts hit triggers' setting (such as the colliders created for UIPopupLists).
  
  
• OnKey repeating. If I hold the left arrow with a slider selected, it would be nice if it continued to move.
  
  
• Add the rest of the possible notifications to UIForwardEvents. I know it's marked as legacy, but it still provides functionality not found elsewhere (Event Triggers don't forward arguments, and don't call private methods the way UICamera.Notify/SendMessage does). It's missing OnKey, OnDragOver, OnDragOut, OnDragStart, OnDragEnd, and OnTooltip.
  
  
• Ability to set the OnKey step size for UISliders. It's currently hardcoded to .125. I'd like to be able to fine tune it on a per-slider basis.
  
  
• UIKeyNavigation should chain when disabled. Currently, they kind of break if you have dynamically enabled elements and overrides. For example, I have a horizontal skill tree and an 'Apply' button below the tree. Intuitively, I expect that pressing down enough times will take me to the Apply button. The problem is that relative to the leftmost and rightmost items in the skill tree, the Apply button is at an angle greater than 45 degrees, so pressing down won't reach it. So for the entire bottom row of skills, I have the down override set to the Apply button. When any of those bottom skills are disabled (locked, unreachable in the tree) you again can't reach the Apply button from the far left or right skills. It seems like a better algorithm for moving selection would try to move like it currently does, but keep track of disabled UIKeyNavigation if it would be reachable and closest, if no new selection is found to move to, use the disabled one and recalculate from there.
  

[ArenMook]

Good suggestions, but I strongly advise submitting these on Saturday so that I have time to look at them. On a weekday I often end up doing support for 12 hours, and I have no time to look into adding anything new.

[AtomicBob]

Saturday bump, as suggested.

[AtomicBob]

Added an idea for UIKeyNavigation

[ArenMook]

Don't be afraid of tweaking NGUI's scripts, or creating your own derivatives from NGUI's functionality. That KeyNavigation is one example. You can just get rid of the 45 degree angle check, or better yet -- have a version of this script that has some kind of a "global override" -- when pressing down, and there is no valid selection, default to some specific object.

[AtomicBob]

I have in some more important circumstances, but it's not a great way to go, imo. NGUI scripts typically don't lend themselves to subclassing since usually stuff is private and not virtual. That leaves either modifying scripts directly, which means it's a pain to update NGUI, or copy-pasting NGUI code into new scripts, which makes updating a little easier but NGUI changes will have to be merged manually and things might break if changes aren't merged.

I may do it anyway though. Might be worth it on this project.

[ArenMook]

Any non-trivial project will require customization, and it's often faster and safer to copy/paste smaller scripts rather than derive. Extending functionality is a good idea for longer scripts, but not for shorter ones. I am often faced with a dilemma of whether to make something short-and-to-the-point, and thus easily modifiable, or make it robust and extensible by sacrificing clarity and shortness of trivial code. For your example, I would most likely just write a script that would GetComponentsInChildren<UIKeyNavigation>() and set the onDown value automatically.