Comment 0 for bug 1527387

== Ask ==

I want to add SwipeArea.monitorOnly (name is up for debate) which lets input events "fall through" (i.e. it doesn't own them) but continues to monitor them.

I have a specific need for it, but it might be a generally useful thing?

== Backstory ==

Recently, the UITK got SwipeArea, which is great. In unity8, I'm working on a redesign of the edge introduction tutorial on first boot of your device.

There's a part of it where we put a shell-wide overlay on top of the screen that says "Swipe from the bottom to do ..." and this should fade out as the user swipes up (but should do the right thing if the drag isn't completed or is held in place).

One way to do this would be to communicate with the app. But that's a lot of infrastructure for one little feature. And this feature might be short-lived, because eventually we're going to try to move those "coach mark" help screens in the UITK as well for apps to use themselves. But for now, the shell is showing the bottom edge coach mark for a select few apps.

So another easy way to do it is to be able to monitor the user's drag, but not interfere with it. So the shell can see what the drag is doing, but the app still does the drag itself.

== Next Steps ==

I was working on a unity8 branch to add a monitorOnly field to DirectionalDragArea, but that got moved into UITK as SwipeArea and is being dropped from unity8. So now I've come here to try to add it.

You can see https://code.launchpad.net/~mterry/unity8/tutorial-redesign/+merge/271342 and search for DirectionalDragArea for the kind of change I'd propose.

I'll whip up a UITK branch, but would appreciate feedback on how receptive you are to it, whether you want a different name than 'monitorOnly', etc. Thanks.