[PATCH weston] input: don't send to clients key events eaten by bindings
daniel at fooishbar.org
Thu Nov 20 00:14:45 PST 2014
On 20 November 2014 08:05, Daniel Stone <daniel at fooishbar.org> wrote:
> 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.
I should add that none of this precludes point-to-type/sloppy-focus. The
focus remains entirely at the discretion of the compositor, and this makes
it no more or less difficult than it is today: just adds another focus
annotation which better accounts for ephemeral focus changes.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the wayland-devel