Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Recommended approach for disabling all interactions in a MRTK enabled UI Canvas #951

Open
TheXRMonk opened this issue Oct 29, 2024 · 6 comments
Labels
Needs: Author Attention Needs additional information from the issue author Needs: Triage Needs to be triaged. Type: Documentation Issue for new or existing documentation.

Comments

@TheXRMonk
Copy link

Describe the issue

Let's say we have a couple of pages swiping from left to right. The PressableButton together with the RectTransformColliderFitter will nicely shorten the box collider as a page transitions across the "screen" and outside the "UI Mask", meaning you can't click buttons that are off screen. Great!
However, how does one disable the buttons while they are transitioning? We want to block users from accidentally pressing buttons that are going off or coming onto the screen.

There's no clear way to do this.

In native unity UI you would just disable the Graphics Raycaster or put an invisible component over the screen to block raycasts, but there's no way to do this in MRTK.

What we've tried so far:

  • Turn off the colliders on the buttons, but there seems to be a single physics update frame where the buttons are still active (so you can quickly click two buttons (navigate left and navigate right) on the same screen even though both button colliders are disabled as soon as one of the OnClick events are fired).
  • Turn off the button. This kinda works, but for some reason MRTK has decided that component.enabled = button.interactable, so not only does the visual appearance of the buttons change, but now we also have to manually save and restore the "previous" interactable state of the button, which quickly becomes a nightmare.

So main question: How should one turn off a whole "canvas" of MRTK UI?

Feature area

MRTK Canvas UI

@TheXRMonk TheXRMonk added Needs: Triage Needs to be triaged. Type: Documentation Issue for new or existing documentation. labels Oct 29, 2024
@AMollis
Copy link
Contributor

AMollis commented Nov 20, 2024

@ghazen-ml can you please add your recommendations to this issue?

@AMollis
Copy link
Contributor

AMollis commented Nov 20, 2024

@TheXRMonk can you please describe the end user impact of this issue? What issue are you hitting "while buttons are transitioning"?

@AMollis AMollis added the Needs: Author Attention Needs additional information from the issue author label Nov 20, 2024
@ghazen-ml
Copy link
Contributor

A few tricks that could be useful for situations like this:

  1. Adjust the raycast mask for the XRRayInteractor while you would like to disable input, e.g. to remove a particular layer and then re-add it afterwards
  2. Add a temporary large collider to capture raycasts before they hit a particular panel (this may not work well if the user would be very close to the panel)
  3. Switch the layers of the interactables in question so they are temporarily not targetable by the interactor raycasts.

It would be great to understand more about your use case -- why are users attempting to click while a view is paging? Did their interaction cause the transition or is it happening automatically or on a timer?

@TheXRMonk
Copy link
Author

TheXRMonk commented Nov 22, 2024

A few tricks that could be useful for situations like this:

  1. Adjust the raycast mask for the XRRayInteractor while you would like to disable input, e.g. to remove a particular layer and then re-add it afterwards
  2. Add a temporary large collider to capture raycasts before they hit a particular panel (this may not work well if the user would be very close to the panel)
  3. Switch the layers of the interactables in question so they are temporarily not targetable by the interactor raycasts.

We're only using near interactions - no rays. Not sure point 3 will solve it, but that might be possible,

It would be great to understand more about your use case -- why are users attempting to click while a view is paging? Did their interaction cause the transition or is it happening automatically or on a timer?

Basically when a user clicks "next" the page transitions a whole page. While this is happening the user's finger might be accidentally clicking buttons that are "transitioning" across the screen, leading to the UI reacting to for instance going back again to the previous page, or fast forwarding to the next one before the user has even seen/read it.

@ghazen-ml
Copy link
Contributor

ghazen-ml commented Dec 11, 2024

Hi @TheXRMonk , were you able to have success with one of the approaches above e.g. to disable the poke/ray interactors etc during a UI transition?

@TheXRMonk
Copy link
Author

I'm sorry we haven't had the time to look into this yet. We'll probably have to go with the raycast layering approach though, since we also now have "pop-up dialogs" in the UI that requires buttons behind to be disabled, so in that case disabling the whole poke/ray will not work since we still need it for clicking the pop-up dialog.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs: Author Attention Needs additional information from the issue author Needs: Triage Needs to be triaged. Type: Documentation Issue for new or existing documentation.
Projects
None yet
Development

No branches or pull requests

3 participants