[PATCH] Refine compositor grabs behavior

Peter Hutterer peter.hutterer at who-t.net
Mon Nov 23 13:49:41 PST 2015


On Mon, Nov 23, 2015 at 10:57:01AM -0800, Bill Spitzak wrote:
> 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.

two wl_pointer objects != two actual pointers. you can have multiple
wl_pointer objects in the same client by calling wl_seat.get_pointer
multiple times.

Cheers,
   Peter

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


More information about the wayland-devel mailing list