<html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> On 09/30/2012 09:08 AM, Bill Spitzak wrote: <blockquote cite="mid:mailman.50.1349031639.8641.wayland-devel@lists.freedesktop.org" type="cite"> << SNIP >> </blockquote> I hope these comments are useful; if they're just a bunch of obvious "baggage", I apologize. <blockquote cite="mid:mailman.50.1349031639.8641.wayland-devel@lists.freedesktop.org" type="cite"> <div class="moz-text-flowed" style="font-family: -moz-fixed; font-size: 16px;" lang="x-western">All the normal keystorkes that a client handles are a roundtrip, so I really can't see this being a problem. I certainly agree with Wayland's design that once a client decides to change it's display, that it be able to do that with no further roundtrips. But that is different than event handling. <blockquote type="cite" style="color: #000000;">Furthermore, it allows clients override global shortcuts of the compositor, which means that it would be impossible to have secure shortcuts, e.g. "kill this client" or "switch sessions". </blockquote> There certainly would still be "secure shortcuts" like you describe. These are identifiable to the user as "you hold down lots of strange shift keys". For instance ctrl+alt+del. The reason "lots of strange shift keys" are needed is to avoid breaking applications by blocking a keystroke the application designer thought was available. My main concern is that we don't have to make *ALL* shortcuts "lots of strange shift keys". The type of shortcuts I think me and Daniel are worrying about is the volume buttons. I would like hitting the volume button to change the volume in the current app that has focus, and only change the global volume if that app does not have a local control. </div> </blockquote> You are suggesting a design with which I agree: First-priority WM/Compositor shortcuts (e.g., switch from a frozen App Window; halt the entire user's Session) are "owned" by Weston, in an unconditional manner. Weston will act on these "lots of strange keys" Events before the App even gets a chance to see them events (Keyboard for usre; and maybe some user-specified Pointer Evts., if we do offer a "registry" implementation which users can modify for themselves.) Second-Priority Weston shortcuts are "lots of strange keys" (AKA "keysequence" of length one, or more, events in the correct order) ... which were offered to the Application and returned to Weston (or another WM) as un-handled events. Or, they are directly generated within the application via logic (or GUI events), leading to an App request that the "shortcut" be used. This is the land of HIG, and IMO Weston/Wayland needs to create and document such guidelines: Analogous to a new column in the "shortcuts" which are understood by Qt, when a Qt Application runs within KWin versus Gnome or OS-X Window managers. (Reference <a class="moz-txt-link-freetext" href="http://qt-project.org/doc/qt-5.0/qkeysequence.html#StandardKey-enum">http://qt-project.org/doc/qt-5.0/qkeysequence.html#StandardKey-enum</a>.) For example, an Qt Application request to switch to "fullscreen" will pass Ctrl+Meta+F on OS-X, F11 on KDE (which can also use Ctrl+Shift+F), and Ctrl+F11 under Gnome. The program is compiled ONCE, and the alternative implementations of the corresponding keysequence are executed within the Qt library. In the particular case which you're describing: This is not a "First-priority" WM shortcut. We should pass the volume button "press" evt. to the Application with keyboard, allowing it to process in a way which it chooses. If it ignores the key, then the key event should be RETURNED from the application (or even generated by the Application), "back" into the WM/Compositor, where we may apply it globally. <blockquote cite="mid:mailman.50.1349031639.8641.wayland-devel@lists.freedesktop.org" type="cite"> <div class="moz-text-flowed" style="font-family: -moz-fixed; font-size: 16px;" lang="x-western"> <blockquote type="cite" style="color: #000000;">Third, if the client hangs, it would mean global shortcuts would stop working, and you could not e.g. alt-tab away from a frozen window, which might be even fullscreen. </blockquote> There would be a timeout, same as being suggested for the window drag controls, after which the shell acts as though the client ignored the keystroke. <blockquote type="cite" style="color: #000000;">It would also mean, that every application would need additional code to cooperate with the compositor. Missing that code would by default stop all global shortcuts from working. Programmers would have to spend effort to not break the *whole* desktop, instead of just having their app working right with the desktop by no effort. </blockquote> This just requires toolkits to require a "I used the key" return value from keystroke handlers.</div> </blockquote> IIRC, The Qt/KDE design is the opposite: If they "USED" the key within some level of code (class or interface), then they suck it in and nothing comes back to Weston. If they want to ignore the key, then the keystroke event gets "pushed up" through all of the Application classes, eventually reaching the top-level window. And that Window passes it back to the WM/Compositor. <blockquote cite="mid:mailman.50.1349031639.8641.wayland-devel@lists.freedesktop.org" type="cite"> <div class="moz-text-flowed" style="font-family: -moz-fixed; font-size: 16px;" lang="x-western"> The amount of work for a programmer to support that is trivial (they are likely calling several functions that already return this information), and failure of the programmer to do this will result in obvious bad behavior of the application (such as breaking Tab navigation) even if there are no global shortcuts. <blockquote type="cite" style="color: #000000;">You might invent elaborate schemes to overcome the latter cons, but even the roundtrip argument alone is a serious one, and there would have to be a serious benefit in doing so. This would just bring a lot more problems than it would solve. </blockquote> I'm worried that a "shortcut registry" will add enormous complexity and bugs and make it difficult for programmers to get the behavior they want. </div> </blockquote> That depends how complex/ sophisticated Weston intends to become. If Weston will eventually have spinning cubes of multiple Desktops and/or "workspaces", then we'll need to let users avoid "sequences" which applications want to use. And we'll need to have pointer support- for a number of buttons which is AT LEAST competitive with Compiz. If we want to leave Weston as a more limited Compositor, - - - - - With those introductory comments we get to the "guts" of my reply: Perhaps Weston/Wayland HIG should be defined with a clear distinction between those "Global Shortcuts" will be taken and executed by Wayland/Weston before an application can even see them, versus other "Global Shortcuts" which will only execute a global Wayland/Weston function when passed back, in a round trip, from an Application program which chose to ignore it. And, OT: Do you intend to support EMACS-style "keysequences" of separate events, or merely single-event combinations of modifiers with key(s)? The latter brings up issues of A18n .... if you're typing with a single-pointed tool in your mouth, it's REALLY HARD to hold "Ctrl" and "Alt" at the same time you press "Del" ;) </body> </html>