MixedRealityToolkit.InputSystem.EyeGazeProvider.GazeCursor.SetVisibility() does not do anything.
Steps to reproduce the behavior:
MixedRealityToolkit.InputSystem.EyeGazeProvider.GazeCursor.SetVisibility(false);,Upon calling MixedRealityToolkit.InputSystem.EyeGazeProvider.GazeCursor.SetVisibility(false);, the cursor should turn invisible.
Calling MixedRealityToolkit.InputSystem.EyeGazeProvider.GazeCursor.GameObjectReference.SetActive(false); seems to work as a temporary workaround to achieve the desired effect of hiding the cursor.
I have the same problem. I found that the Gaze cursor visibility is actually driven by
FocusProvider.ReconcilePointers() which re enable it based on it's internal state machine. I think adding an option to disable this behaviour would be helpful
Thanks for reporting this one - as @michel-de-verdelhan calls out, this is mostly because the gaze cursor visibility is powered by the internal state machine of the focus provider + the gaze provider itself.
I'm gonna send out a PR for this one shortly.
@Pycorax FYI, in case you can take a peek at the PR
@Pycorax, @timGerken FYI, I chatted with @julenka offline about the linked PR, and we decided it would make sense to roll up the solution to this issue into another issue that she is tracking.
https://github.com/microsoft/MixedRealityToolkit-Unity/issues/4954
The main thing here is that there are a few other scenarios where people want to disable/enable things at runtime (i.e. turn of hand ray, turn off poke pointer, turn off gaze).
The key thing there is that with that change, we're probably going to be disabling the gaze pointer as a whole, rather than just the cursor - if this isn't what you want (i.e. you actually want the gaze pointer to still be active, but just hide the cursor so it doesn't look like it's active) then please comment on https://github.com/microsoft/MixedRealityToolkit-Unity/issues/4954 so that we can capture that appropriately.
In the interim to unblock yourself, you can definitely patch https://github.com/microsoft/MixedRealityToolkit-Unity/pull/5799 that locally to get the desired behavior.
I think in my approach to solving this issue, my focus was too narrow, and I do think it makes sense to approach this more holistically across other input mechanisms.
Most helpful comment
@Pycorax FYI, in case you can take a peek at the PR