[PATCH weston] input: don't send to clients key events eaten by bindings
daniel at fooishbar.org
Fri Nov 21 10:30:02 PST 2014
On 20 November 2014 08:31, Giulio Camuffo <giuliocamuffo at gmail.com> wrote:
> 2014-11-20 10:05 GMT+02:00 Daniel Stone <daniel at fooishbar.org>:
> > On 19 November 2014 21:05, Bill Spitzak <spitzak at gmail.com> wrote:
> >> No! Users do NOT want this. Keys take action when you push them.
> >> 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
> > Mod is, however, also used as the prefix for a million other hotkeys. So
> > that case, we have to arm the shortcut when mod is pressed,
> > it if any other keys were pressed, and then trigger on release.
> > Another classic example is Ctrl+Shift used to drive layout change (this
> > 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
> > layout switch) on release, but all others on press. So if you have
> > 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
> >> users expect and what every toolkit in the world does on every platform.
> >> There is nothing special about "compositor shortcuts" and they should
> >> 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
> > 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
- 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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the wayland-devel