[PATCH] Refine compositor grabs behavior

[Bill Spitzak]

On Sun, Nov 22, 2015 at 4:19 PM, Peter Hutterer <peter.hutterer at who-t.net>
wrote:

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

If there are two pointers, then having both surfaces focused simultaneously
is possible anyway, so I don't see how this is a problem.

I am assuming a client will just wait for the frame events and not do
anything until that happens. The fact that it got enter/leave events does
nothing visible to code outside the very low levels so the interleaving is
not a problem. An extremely simplified example of the style of code I
expect clients to use:

  struct ToolkitWindow;
  void (*focusIsNowHere)(ToolkitWindow*, seat); // callback from the toolkit

  toolkit_event_handler() {
    static ToolkitWindow* currentFocus[2];
    static ToolkitWindow* requestedFocus[2]; // This array in particular
cannot be seen by outside code!
    ...
    case wl_pointer.enter:
       requestedFocus[seat] = findWindow(surface);
       break;
    case wl_pointer.exit:
       requestedFocus[seat] = NULL;
       break;
    case wl_pointer.frame:
       if (requestedFocus[seat] != currentFocus[seat]) {
           currentFocus[seat] = requesetedFocus[seat];
           focusIsNowHere(requestedFocus[seat], seat);
       }
       break;
   ...

I find it hard to imagine any client being implemented differently than
this so I really don't see the problem.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20151123/b186bc1c/attachment.html>