Mixedrealitytoolkit-unity: Why are Modal and Fallback listeners stacks and not Lists like Global listeners?

[Gotcab]

One of my object needs to receive unfocused tap events, but not always. I think modal is the way to go but maybe i'm wrong. With a stack there is no way for me to unregister myself. Is there a reason for choosing stacks that I am not aware of?

[StephenHodgson]

They're handled differently from global listeners. Althought @maxouellet would know a bit better, considering his team wrote the initial implementation.

[StephenHodgson]

With a stack there is no way for me to unregister myself

Someone has proposal #2494 which requests changes to add functionality to unregister from specific stacks.

[StephenHodgson]

If we do end up changing this, it'll be in vNEXT to prevent breaking changes.

[Gotcab]

So if I register to global listeners will I receive the event even if a focused object consumed it?

[maxouellet]

You will, but I'm not sure that this is what you should use. The original intent of global listeners was to receive all input events, ignoring whoever might consume it. It was mostly built for things like cursors and 6DOF pointing rays that need to react to everything. There are a couple other edge cases where I've had to use it, but usually I try to stay away from it if I can do things in a different way.

Everything was implemented with stacks to make your app more predictable with regards to how it handle input. The thought was that it's an error if something that is handling input in a modal way try to deregister while it isn't at the top of the stack. Think of it like popup windows: the front popup window should always prevent inputs to other windows it's on top of, and it should always close before anything it's on top of. We could certainly switch the implementation to use lists instead of a stack, but you'd lose the ability to validate that your program is registering / unregistering input handlers in the correct order (which might be acceptable)

I don't know about what your scenario is exactly, but it sounds like what you want is to register your object as a Fallback input handler. Basically, if nothing else consumed the input (like a UI or something else), you want to receive it and potentially do something with it.

[Gotcab]

Thank you so much, that clarify the intend behind that choice. Here is my scenario:

My app is a kind of a promotional virtual space. You walk around and there are interests points and ads that you can interact with. There is a Edit mode and a View mode. Edit mode is where you place objects and view mode you hide editing buttons and you walk around. I have a script CreateObjectOnTap which "spawn" the objects incrementaly when tapping in the air (not focused). So I need to receive unfocused tap on Edit mode and unregister when switching to View mode (event based).

[maxouellet]

I see. Assuming that Edit mode contains other UI, I'd say the right solution would be to have your "CreateObjectOnTap" script register itself as a fallback input handler when your enter EditMode. This would allow other UI that might be present in Edit mode (maybe a piece of UI to exit EditMode, fo example) to still take priority over creating objects, but any "taps" that aren't handled would create an object.

Hope this helps, good luck with your app :)

[PJBowron]

Not a criticism, rather a suggestion - one thing the toolkit input documentation does lack is 'best practices' guide, that encapsulates the kind of things @maxouellet touched on above. I ended up writing one for my team a while ago and I'm happy to see it meshes with the info given here!

The only area I would like to see tweaked is the stack nature of the Fallbacks. A stack makes perfect sense for Modalities, but Fallback systems don't necessarily follow symmetrical patterns and may well have overlapping lifetimes, which makes them hard to support in the current model. /ponderings

[StephenHodgson]

Please do

[wiwei]

Closing issues older than 180 days. If this is still an issue, please reactivate with recent information.