[PATCH weston] input: don't send to clients key events eaten by bindings

[Daniel Stone]

Hi,

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.
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20141121/54da7a98/attachment.html>