Key translations requires a rethink about aenea HOT 9 CLOSED

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.

from aenea.

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.

from aenea.

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...

from aenea.

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:-) )

from aenea.

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.

from aenea.

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.

from aenea.

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

from aenea.

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.

from aenea.

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.

from aenea.