[PATCH] Refine compositor grabs behavior

[Daniel Stone]

Hi,

On 20 November 2015 at 03:47, Peter Hutterer <peter.hutterer at who-t.net> wrote:
> On Thu, Nov 12, 2015 at 01:27:05PM +0100, Carlos Garnacho wrote:
>> - There are grabbing situations where the focus surfaces don't really change
>>   within the compositor (eg. dragging a window, it will probably "have" the
>>   keyboard focus, you however don't want keypresses to trigger anything on
>>   the client). I admit this is an implementation detail, but temporarily
>>   unsetting focus surfaces doesn't strike me as the best solution, plus there
>>   are other cases where you legitimately want to move the focus to another
>>   surface.
>
> as for pointer and keyboard leave events, afaict the ship has sailed on this
> and this has been the behaviour for long enough that your additions just
> document the current behaviour. Any change will likely break things, so
> documenting the cases where a button or key release event gets left hanging
> seems the only solution.

Regurgitating Bill's suggestion in a more constructive manner:

If this does pan out for touch events, are we able to encode
leave/enter/frame grouping for keyboard and pointer, so clients can
discover focus transitions? I think it's a pretty elegant solution to
the problem.

Cheers,
Daniel