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

[Giulio Camuffo]

2014-11-19 23:31 GMT+02:00 Giulio Camuffo <giuliocamuffo at gmail.com>:
> 2014-11-19 23:05 GMT+02:00 Bill Spitzak <spitzak at gmail.com>:
>> 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?
>>
>>>> The only problem with that is that apps using wl_shell can only use
>>>> the keyboard focus as the window focus. Do we just say "too bad,
>>>> wl_shell is broken"?
>>>
>>>
>>> Yup. I think that's a reasonable thing to do. It's meant to be phased
>>> out even though we can "never" drop it completely. (except mutter
>>> already did, IIRC).
>>>
>>> It's not *that* bad. At worst, it's a flicker. At best, might not even
>>> be visible.
>>
>>
>> The *title bar* will flicker. I think that is pretty bad.
>>
>> I also think you are panicking about a non-existent problem. No client is
>> going to fail because it got two focus-in events in a row. Just send two
>> events irregardless of version, and stop adding needless complexity to
>> weston!
>>
>> 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!
>>
>>>> Well, there is also the part about triggering the binding on key
>>>> release instead of press, only if no other key was pressed in the mean
>>>> time. I hope to send the patch(es) for that one of these days.
>>
>>
>> No! Users do NOT want this. Keys take action when you push them. Otherwise
>> the interface looks slow and drives users crazy.
>>
>>> 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.
>>
>> 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:
>
> As a user, i'm very happy my KDE session doesn't work that way. System
> wide bindings must not have side effects depending on the client being
> focused at the moment. That would make them very annoying to use.
> Hitting F12 to show my yakuake window must not open chromium's debug
> window or any other client thing. I want to open yakuake, i don't care
> about what other clients would want to open in my face.

Sorry, i just realized that i misread your mail. Discard my previous reply.


>
>>
>> Mod down -> send key Mod down
>>
>> 's' down -> do the shortcut and take a screen shot, then send a redundant
>> focus-in event that has the Mod and 's' keys down.
>>
>> 'x' down -> send key 'x' down, which may trigger a client action.