MRTK input event handling: FallbackHandler behaviour proposal

[PJBowron]

I've been looking at the revised input system, specifically event handling, as it currently stands in mrtk_development, and have been pleased to find it remains fundamentally the same as it was in HTK.

With that in mind however, I'd like to propose a small change:

FallbackHandlers are currently managed as a stack, with only the latest pushed handler receiving events.

I'd like to change this so that they are managed as a list, and that all Handlers receive the event, unless it gets consumed.

There are two main reasons behind the proposal:

1. Unlike modal input elements, FallbackHandlers tend not to be instantiated and removed symmetrically;
2. Like global listeners, a developer may want multiple handlers active simultaneously.

Allowing multiple handlers to exist, while also allowing any of them to consume the event could lead to unpredictable behaviour. Therefore I would suggest either:

1. Simply relying on instantiation ordering, which would be little different to the current setup;
2. Allow user-defined ordering, details TBD

I’m happy to carry out the changes, but would like to open this up to consultation first.

[StephenHodgson]

@PJBowron please take a look at #277

@maxouellet do you have any comments about this proposal?

[StephenHodgson]

I'm pretty sure this a duplicate proposal someplace too, but can't find it after a quick search. Will update when I do.

Here it is #2494

[maxouellet]

@StephenHodgson I think initially, the fallback handler wasn't a stack, but just a single handler, with the idea being than an app should only have one fallback handler. I think we added the stack later so to handle scenarios such as "a modal popup UI appears, and we want it to be dismissed when the user selects while gazing outside of the popup".

@PJBowron , can you elaborate on why you say that fallback handlers tend not be be instantiated / removed symmetrically?

I have no major concerns over this and am not currently doing HoloLens development, so I'm happy for this to go in if people think it's the right thing to do :)

[PJBowron]

Hi @maxouellet - thanks for a very nice InputManager! 😄
Regarding fallback handlers, I guess it boils down to us not always using them 'situationally' (as in your modality-supporting example). We will often have systems that respond to non-targeted input that have potentially long or overlapping lifetimes. Imagine segregating functional aspects of an app by scene, and having a toolbox UI that allows users to activate/deactivate a number of these functions at will. If two or more of these functional scenes each utilise a fallback handler, things will get messy!

@StephenHodgson thanks for flagging #2494, I forgot I'd posted briefly on this subject before. However this isn't a straight dupe of the earlier proposal for two reasons:

• I would not propose to alter the modal stack;
• I wasn't going to alter the cleanup method - I saw your recent general proposal to move towards IDisposable so fair enough if we go that way in the wider scope, but I see in 2494 that there was some debate about using that approach.

[polar-kev]

Keeping this until we make the call on XR interaction.

[david-c-kline]

This is written talking about input events, but the logic needs to be consistent regardless of event type

[Zee2]

Marking as stale as XRI takes a fundamentally different approach here. We may still want to implement a stack-like modality at some point to support input suppression while interacting with modal content, but that'll require a custom XRInteractionManager.