Mapping shortcuts

[dhardy]

This is partly beyond the scope of Winit but deserves a little discussion.

Key replaces the old VirtualKeyCode as a listing of named keys. The main difference, besides Key being much larger and based off a different standard is that Key includes Character(Str), Unidentified(NativeKey) and Dead(Option<char>) super-categories. (Aside: should Key mix named keys and super-categories in a single enum? Maybe it doesn't matter.)

Fundamentally, Key is about naming keys. Shortcuts are similar, but not quite the same. My attempt at mapping common UI shortcuts resulted in Command. Besides many omissions (e.g. all media controls) this includes a few things you don't see in Key: ViewUp, WordLeft, Italic, Fullscreen.

The point is that there is a large (though not complete) overlap between these enums. Neither should ever be matched exhaustively. So should Key be split up to facilitate mapping "named keys" to "commands"?

Examples:

• Key::Alt, Key::Fn are modifier keys, not commands

[daxpedda]

I'm not sure about "splitting", but generally I like the idea of supporting commands as a way to facilitate cross-platform shortcuts.

[dhardy]

Hence you would support additions like WordLeft to Key? The number of additions I have now is small (probably < 10), but I imagine it could grow significantly.

Or - move most named keys to a (single) separate enum first? This could be called Command, but NamedKey might be more appropriate. On the other hand a short name makes match statements easier to write.

[kchibisov]

I personally wouldn't, because it's subjective, I'd assume you want a WordLeft based on some readline thingy, but honestly such action mapping should be done by UI toolkit.

[dhardy]

Agreed. However, my Command enum emitted from the toolkit to widgets then potentially has a huge overlap with Key. But so be it.

[kchibisov]

But can't you

enum WidgetInput {
    Command // you named thing,
    Key(key) // Key input ,
}

[dhardy]

Sure, but since Key::Character("a") is not a "command" (target of a shortcut), there's a lot more in Key than I need.

(To get text/character/key input, widgets have to request it after receiving keyboard focus, where as commands are always sent.)