Support Back button/KeyCode on Android

[MarijnS95]

Started playing about with VirtualKeyCode on Android, and it seems there's no mapping for KeyCode::Back which would be needed to handle a graceful app exit (or going to the previous page) when the user presses it. The implementation for VirtualKeyCode::Back reads:

winit/src/event.rs

Lines 962 to 964 in f04fa5d

	/// The Backspace key, right over Enter.
	// TODO: rename
	Back,

So I don't think we should add a new Back VirtualKeyCode and rename existing uses to Backspace, as that's really hard to notice for end-users upgrading their winit. Perhaps we can piggyback NavigateBackward but android already supports that as KeyCode::NavigatePrevious:

Keycode::Back => Some(VirtualKeyCode::NavigateBackward),

How do you think we should go forward?

Originally posted by @MarijnS95 in #2226 (comment)

[kchibisov]

@MarijnS95 is this still an issue?

[MarijnS95]

@kchibisov I don't see Keycode::Back being handled anywhere in Android's platform_impl, so I guess not?

[MarijnS95]

@kchibisov note that while searching for VirtualKeyCode I could still find some references in src/platform_impl/linux/x11/events.rs even though it was renamed to Key in #2662. This module doesn't seem to be referenced anywhere, was the file not deleted while X11 was refactored?

EDIT: Turns out that refactor happened in #2662 :)

[kchibisov]

I guess everything is fine, right?

[MarijnS95]

@kchibisov it's not exactly fine as we cannot handle that keycode yet, it's not mapped.

What's worse, we don't have a way to optionally mark the keycode as used at runtime (e.g. given how inconsistently we're forced to handle volume keys now since #2748) as users would likely want to back out of some menu stack. Once they are at the bottom of the stack, they will set handled=false on Keycode::Back (probably via a KeyEvent extension trait) so that Android handles it instead and leaves or stops the app.

[kchibisov]

But you can define a filter mask on event loop builder whether we want to accept or not? Like HashSet<Key>. Could use something else, but setting a filter mask for events user want to handle or not sounds 'sane'.

[MarijnS95]

Was that built already? Your comment sounded like a suggestion but I'll check it out. Most important question: can we change the contents of the HashSet at runtime after building the event loop? As explained above that is vital to supporting these things.

[kchibisov]

Well, it's not here, but nothing stops you from defining such a thing. You can change the event delivery at runtime, for example we have similar concept with listen_device_events, you can change it at runtime just fine.

[MarijnS95]

Sure, I'll think about it but doubt I can find the time.

Am I right in assuming that you're suggesting this route because going the extension way on KeyEvent might be very hard to synchronize back to the platform implementation?

[kchibisov]

Right, and because events are just data which could be send between threads.

[MarijnS95]

Exactly, we have to call finish_event(evt, handled: bool) at some point, and have to know the value of handled. That is impossible if the user holds on to a KeyEvent for who knows how long.

EDIT: I still haven't decided whether we should give the user the event if it is in the "don't mark this as handled" HashSet<Key>. Perhaps there are cases to be made where a user first inspects the event before marking it as handled, the API is designed like this for a reason.