Hi, On 20 November 2014 08:31, Giulio Camuffo <[email protected]> wrote:
> 2014-11-20 10:05 GMT+02:00 Daniel Stone <[email protected]>: > > On 19 November 2014 21:05, Bill Spitzak <[email protected]> wrote: > >> No! Users do NOT want this. Keys take action when you push them. > Otherwise > >> the interface looks slow and drives users crazy. > > > > > > That sometimes conflicts with the goal of having ambiguous hotkeys. For > > instance, if you press and release Mod on its own, you'll get Exposay > mode; > > Mod is, however, also used as the prefix for a million other hotkeys. So > in > > that case, we have to arm the shortcut when mod is pressed, > disarm/release > > it if any other keys were pressed, and then trigger on release. > > > > Another classic example is Ctrl+Shift used to drive layout change (this > is > > the Windows default), when you still want Ctrl+Shift shortcuts. > > > > I'd hope that this was restricted to modifiers, so we could just say as a > > general rule that the compositor will drive modifier-only hotkeys > (Exposay, > > layout switch) on release, but all others on press. So if you have > ambiguous > > hotkey combinations which involve non-modifier keys, well, you lose. > [the above is salient] > >> In any case, DO NOT DO THIS!!!! What the above sequence should do is a > >> screenshot, followed by the action of Mod+s+x in the client. This is > what > >> users expect and what every toolkit in the world does on every platform. > >> There is nothing special about "compositor shortcuts" and they should > NEVER > >> act differently than a client would that handles both shortcuts. Here is > >> correct behavior: > > > > I agree 100%. Again, think of nesting compositors: why should our > compositor > > behave completely different if it's nested? The more difficult we make > it to > > sensibly nest compositors, the more we're shooting ourselves in the foot. > > Ok, now you got me confused. Wasn't this what you said would be the > correct way to handle bindings? > Sorry, was kind of mixing theoretical and practical a little bit here. The only case where you need action-on-release rather than on press, is where you have ambiguous/overlapping hotkeys. For instance, Ctrl+Shift switches keyboard layouts, Ctrl+Shift+Q closes Chrome. When you have these kind of overlaps, you need to wait until release to disambiguate. As in the first quoted section, I think it's not really reasonable to guard against the possibility of Mod+S taking a screenshot in the compositor, but the client having a shortcut for Mod+S+X. So I think we can take the easy way out of saying: - for any hotkeys which are _solely_ combinations of modifiers and _not_ non-modifier keys (e.g. Exposay as it is today), then we only take action on release - for all other hotkeys (i.e. including non-modifier keys), then we take action on press - if a client has a hotkey combination which conflicts with the above (e.g. the Mod+S vs. Mod+S+X case), then that's their problem, because it's a stupid hotkey combination anyway Does that help? Cheers, Daniel
_______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
