[1061]Desktop mode breaks UI Transitions
child of the beast
UI Transitions for 'Highlighted' break unless you have your UI on the UI layer.
Did some experimenting before wanting to post this and this is what i've found:
If your UI is on the Default layer, the transition for 'Highlighted' will not work for sprite swap, Animation and Color tint.
If your UI is on the UI layer it works as expected as long as you have your menu open.
While this is pretty minor it can inhibit the creation of accessibility tooltips for buttons and can potentially be a mechanical gate for desktop users on maps that decide to use the Animation on Highlight as a mechanic to progress through the map.
Example of accessibility tooltips: https://drive.google.com/file/d/1mhL_sJ-gqPXnGP23LNWAaHZXlmu0X9S8/view?usp=sharing
Here's a video of the bug itself: https://drive.google.com/file/d/1oNPUv9hlVnr56gp_3ah-wEYyQT9Pn-Me/view?usp=sharing
The Animation button shows how this can be used as a mechanical tool, I have a cube that permanently turns on when the animated cube turns on when you hover over the button.
The Sprite Swap button changes sprites on hover.
Color tint is your usual UI button that tints it's color on hover.
This is the world I did the testing in, has UI buttons with all 3 types on both layers:
Log In
techanon
I've done some consideration on this and I think that it's not actually an issue of a technical nature, but one of educating why the current implementation might be the right one.
So consider this: you are a desktop user and you are looking at the UI. It has some hover transition which forces it to a particular state. If the hover was allowed to operate implicitly for desktop users, the only way they could trigger the non-hover state is by looking away, but that makes the user unable to look at the UI without the hover state active.
By having an explicit user interaction required for enabling the hover interactions, it allows the user to explicitly cause their desired hover state.
Having this attached to the a button (currently 'Tab', the ALT isn't needed) isn't a bad idea.
Here's my use case which could help understand it's benefit:
I have a UI which is an overlay style UI that shows up in front of a video screen. In VR, users point their controller at it to trigger the hover state, causing the animation to show the UI controls. VR users are able to just move their hand away from the screen without having to turn their head. Desktop doesn't have that luxury. Instead their interaction control is directly tied to their view direction. So by binding enabling the hover explicitly to a button (aka "temporarily unlocking the cursor"), it allows desktop users to choose whether or not to show the "hover" UI state without having to turn where they are looking.
It might be nice to have a toggle option on the VRCUiShape for specifying whether implicit hover should be enabled (thus the need for tab on that specific canvas is removed). That could be a good compromise.
Aside from that, I think it's necessary to help people learn about the use of the Tab button for desktop.
Blue-kun
Working on a new UI system and encountered this. Alt-tabbing to reveal the windows cursor also causes the highlight button state to work. V sad :((
techanon
Issue is still present. Would really like to see this fixed as UI design can be much cleaner by having the Highlight state be properly triggered, especially for use with animations that cause certain elements to resize for extra data or to show additional options without needing an extra click.
child of the beast
seems to still be an issue in Unity 2019
Kilerbomb
This has been an issue since 2018 at least, would be nice to see this fixed even if it's an admittedly small problem.
FairlySadPanda
It works if you hit tab to free your mouse cursor whilst the cursor is hovering over the button. :|