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

[Pekka Paalanen]

On Thu, 20 Nov 2014 10:31:18 +0200
Giulio Camuffo <giuliocamuffo at gmail.com> wrote:

> 2014-11-20 10:05 GMT+02:00 Daniel Stone <daniel at fooishbar.org>:
> > Hi,
> >
> > On 19 November 2014 21:05, Bill Spitzak <spitzak at gmail.com> wrote:
> >>
> >> On 11/19/2014 05:08 AM, Pekka Paalanen wrote:
> >>>>>
> >>>>> Just like Jasper said, it is a mistake to use wl_keyboard focus for
> >>>>> window focus, xdg_shell has a separate mechanism for window focus.
> >>>>> Window focus is a shell concept IMO, anyway.
> >>
> >>
> >> Can you explain when (except to fix this bug) then "xdg_shell focus" will
> >> be set differently than the input device focus? I think you are talking
> >> about "activation" which is DIFFERENT than keyboard focus.
> >>
> >> Unless your goal is to make point-to-type impossible?
> >
> >
> > As far as I can tell from what the others are saying - which I'd totally
> > agree with - is that wl_keyboard's focus would be much more transient than
> > it is now, reflecting where keyboard events are _actually_ being delivered
> > _right now_. So if the compositor took a long-lived grab, e.g. for the lock
> > screen, you'd lose keyboard focus as you do today, as well as losing
> > xdg_shell focus. But if the compositor just took an ephemeral grab (e.g. key
> > binding), then while you would lose keyboard focus, you wouldn't lose
> > xdg_shell focus.
> >
> > So think of keyboard focus as tightly bound to actual event delivery at that
> > very particular moment in time, and a hint that keys may be pressed
> > underneath you, so you could well come back with pressed keys you shouldn't
> > take action on, whereas shell focus is what you'd use to drive things like
> > rendering your decorations with (in)active highlights.

Exactly.


> >> You also mentioned an "enter debug mode" shortcut. That must NOT send a
> >> focus-out event, as it could change the state of the client being debugged!

By the very same reasoning, nothing about the debug key combo should be
sent to any client - except that's not possible. Right now the debug
key works by first hitting Mod+Shift+Space, then hitting the actual
debug key (a letter key usually). At least the Mod and Shift will
somehow end up in some client.

> > Heh. To be fair, these debug shortcuts are pretty ephemeral - things like
> > screenshots,

Our debug things include tinting all GL-composited stuff green, drawing
the triangle mesh edges, toggling cursor and overlay planes of DRM, etc.


> >>>
> >>> Mod down -> send key Mod down
> >>> 's' down -> oooh, hotkey, steal kbd focus, send kbd.leave
> >>>
> >>> Then either
> >>>
> >>> 's' up -> do screenshot, restore kbd focus, send kbd.enter with Mod
> >>> down.
> >>>
> >>> or
> >>>
> >>> 'x' down -> not our hotkey after all, restore kbd focus, send kbd.enter
> >>> with Mod down, send key 'x' down
> >>
> >>
> >> I think you meant the kbd.enter would include the Mod *and* the 's' key.
> >
> >
> > Yes.

Whoops, yes indeed.


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

Well, I just personally hate triggering unwanted side-actions when
reaching for a single final action. Maybe that's just me.

If the client was handling both shortcuts, it could do either way.

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

Yeah, I'm confused too.

I tried to think of a stack of:
	evdev <- Weston <- nested (compositor) <- app
and the different cases of how Weston behaves towards nested vs. OS
(e.g. VT-switching) behaves towards Weston, and I'm not sure I see what
nested would need to do differently from weston with what I thought.

So how should it work?

I would still assume, that if I press Mod+s to take a screenshot, I
wouldn't want the 's' to appear on the terminal that happened to have
the keyboard focus when Mod went down. If the terminal had a Mod+s
shortcut too, should it run or not?

That is, if all of Weston, nested, and app happened to have the same
shortcut, should all three fire, or only Weston's?


Thanks,
pq