[PATCH] Refine compositor grabs behavior

[Peter Hutterer]

On Sat, Nov 21, 2015 at 02:42:25PM +0000, Daniel Stone wrote:
> 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.

Jonas and I discussed this on IRC on Friday, but it's unclear whether it'll
work. It looks fine and great for the simple case, the cost of implementing
it in the compositor is small, but the client side is a bit trickier if you
have multiple wl_pointer objects.

simple case split:
leave, frame *FOCUS OUT* enter, frame *FOCUS IN*

simple case merged:
leave, enter, frame *FOCUS TRANSITIONED*

double pointer case when split across frames:
p1.leave, p1.frame, *FOCUS OUT* \
  p2.leave, p2.frame *FOCUS OUT* \
  p1.enter, p1.frame *FOCUS IN* \
  p2.enter, p2.frame *FOCUS IN*

double pointer case merged:
p1.leave, p1.enter, p1.frame *FOCUS TRANSITIONED* \
  p2.leave, p2.enter, p2.frame *FOCUS TRANSITIONED*

in the split case, a part of the client can be lagging behind in state,
there's no time where the pointer is focused on two surfaces. That's not the
case in the merged case. If we enforce the protocol to this instead:

p1.leave, p2.leave, \
  p1.enter, p2.enter,\
  p1.frame *FOCUS TRANSITIONED*, p2.frame *FOCUS TRANSITIONED*

we have the same issue where two surfaces are focused simultaneously though
at least in this case it's detectable. I don't know how much of an issue
this is in the real world, Carlos may have more feedback here.

coincidentally, the simplest weston implementation would give us the last
case.

Cheers,
   Peter