Key translations requires a rethink

[calmofthestorm]

Right now, the way we handle key translations is less than ideal. The fundamental issue is simple: Dragonfly, Windows, X11, and OS X all use different names for the various keys on the keyboard. We want to make things work with each other as much as possible while avoiding mapping things that aren't equivalent.

Currently, the X11 server maps most Dragonfly keysyms into X11 keysyms. #64 adds a translation layer in the client for < and >. Additionally, Aenea will accept X11 keysyms directly and pass them along to the server.

So the questions I see is:

• Do we need two levels of translation (client and server) or should it entirely be the responsibility of one?
• Should Aenea accept the union of all keys across all platform, just keys for the currently active one (strict and lax do some of this already), or only Dragonfly keys?
  • If only Dragonfly keys, how do we handle platform specific keys (meta, hyper, super, command, etc)?
• Should the client prefer to send Dragonfly symbols, or attempt to translate to the active platform keysyms?

In general, my instinct is it's better for Aenea to pass along anything it can than for it to police what a grammar and the server are allowed to do, insofar as it mediates communication between them. But I do want the same grammar to be able to work across platforms where possible.

My favored solution would probably be to accept union of all platforms on the client, translate all that can be to Dragonfly syms and pass along the rest as are, then the servers translate Dragonfly syms to local platform ones, and executes the rest natively. This means Aenea will let you send a Linux keysym to a Windows server, and the latter will experience an error, but I think this is an acceptable price to pay.

I welcome your thoughts, especially if you have any experience with internationalization and localization -- I've only worked with various layouts of US keyboards, and ideally this would work well for those on other hardware (or at the very least not actively get in their way).

[djr7C4]

I would allow keys for the union of all platforms in Aenea. I think the client should perform the mapping to dragonfly keys where possible. This is independent of the particular platform and thus belongs with the client rather than the server (which should deal with platform-specific issues).

It could be useful to have the servers translate keys that would generate errors to platform specific keys but I think that if this is done some platform independent names should be chosen for these keys (so that we don't have to pick a primary platform). I'm not sure that this is a good idea unless those keybindings are also supported locally however.

I would also add actions that allow different actions on the proxy compared to the local dragonfly context (so for instance, "close window" would trigger w-c on the proxy but a-F4 locally. This is easy to add outside of Aenea of course, but it seems like a useful construct that belongs in Aenea itself.

[calmofthestorm]

Thanks for the thoughts. I favor that approach as well.

I'm not sure how I feel about platform independent actions as you mention -- there are often subtleties. Take the close example -- my platform is X11 but my WM is Awesome, so it's m-c. But if I were on KDE it'd be Alt+F4, and if I were on Gnome there'd be no way to close windows -- the WM would decide whether or not to do so to avoid adding any buttons:P

Another example would be window management commands -- bring to foreground, etc. In principle I could add basic cross-platform window management to Aenea, but given how different WMs, OS X, Windows, etc all manage windows -- pretty different paradigms -- I feel that it would be better to handle that at the grammar level.

Likewise, what about WMs that could be cross platform? You can run XMonad on OS X as well as Linux. I'm not sure how those keybindings interact, but I'd rather deal with it in the XMonad grammar than Aenea.

I'm trying to be very careful about scope creep, given this repository started as me committing all my stuff before we recently pared it down. Aenea is just for remote actions. I know I can't hide from platform-specific issues entirely, but I want to minimize it.

A better question perhaps is what is the simplest set of primitives Aenea could provide to make it easy to add features like you describe -- cross platform commands that grammars can make use of. We already provide ProxyPlatformAction et al, which is a big chunk of it. I could create a module called xplatform.py, add a ProxyPlatformAction, and drop it in MacroSystem, and grammars could import it and return xplatform.CloseWindow.

[djr7C4]

I just mean that I'd like to be able to write something like this

ProxyOrLocalAction(ProxyKey("w-c"), dragonfly.Key("a-F4"))

Of course, this is pretty easy and takes only a few lines of code but it seems like a primitive that should be available.

I agree that Aenea shouldn't worry about window management. The grammars can deal with that. However, I think that your comment brings up another issue. Unless I am mistaken, there is currently no way to have the context depend on the WM (and that seems like the right way to handle the issue you point out). I'm not sure how hard that would be, but it would be useful... So basically, there should be a ProxyWMContext class or something like that...

[calmofthestorm]

My mistake, we have that for contexts but not for actions. This is an oversight, and I'll add it when I have time. ProxyPlatformAction (local or proxy as appropriate) and ProxyCrossPlatformAction (switches between OS as necessary).

Regarding WM context, perhaps it should be simpler but it is possible currently using ProxyAppContext with a custom query -- at least the linux server sends the current WM (ok right now it always sends awesome, but that's easy enough to fix:-) )

[djr7C4]

That is good that it is possible! I think a ProxyWMContext class would be better though. It just seems simpler and more intuitive to me.

[calmofthestorm]

That's fine with me as sugar, I've also been meaning to add convenience ProxyPlatformKey for using one sequence of keystrokes vs other(s) based on platform too, even though you can do that with ProxyPlatformAction.

[calmofthestorm]

Let's move the discussion of different actions based on proxy to its own issue, #72

[mzizzi]

I think that the aenea server should include the union of keys across all platforms simply for the sake of maintaining a single protocol specification. Certain key symbols won't make sense on some platforms and that's something that grammar designers will have to deal with. No amount of mapping will ever make the "command" key make sense on an X11 desktop. My point here is that some grammars will be inherently platform specific and I imagine that most of aenea's users are developing with a single platform in mind. Servers could detect this and choose to either ignore the bad key symbols or fail the RPC that includes them.

If we really want to enable cross-platform grammars then the grammars themselves should map their actions to key symbols depending on what platform they detect at startup.

[calmofthestorm]

Sounds like we have agreement that it should basically be the union, which is what we have now. I agree that any grammar that wishes to work across platforms will need to be platform aware -- my only thought on that topic is that we may wish to make it easy for them to do so. But I agree that the server is not the place for this sort of thing -- it could be exposed client-side as a library grammars can make use of.