[PATCH v2] protocol: Define further the behavior of input on the presence of grabs

[Bill Spitzak]

On Thu, Nov 12, 2015 at 4:31 AM, Carlos Garnacho <carlosg at gnome.org> wrote:

> The leave events in the respective device interfaces has been further
> documented so those can convey the necessary info when input is being
> redirected out of their currently focused surface.
>
> Only wl_touch is missing something semantically similar, a wl_touch.leave
> event has been added so the touch interface can cope with such input
> redirection situations.
>
> Changes since v1:
>   - Reuse leave events for this purpose. This meant one had to be added
>     on wl_touch.
>

+       Normally, a pointer will not leave a surface while there are
> +       buttons pressed, there's however circumstances where this event
> +       may be received in this situation, for example:
>

I have some doubts some of these can happen, or that the need is so rare or
esoteric that it might be better to just not allow it at all:

+       - When a popup is shown by this or other client.
>

For "this" client I would prefer that no exit event be sent, only an enter
event for the new surface. At the moment these fake exit events are a pain
to handle and the client has to add specific code to ignore them (see
below). Fixing this would remove the primary reason clients need to be able
to peek ahead in the event queue.

For "other" clients: are they really capable of making a popup without the
pointer focus? It seems like only the compositor could do this, but is
there really a need to support this?


> +       - When a drag-and-drop operation is initiated from this or
> +         any other surface.
>

Again for "this" client, I would greatly prefer not getting an exit event
that I have to ignore. And it sure seems like the grab is still going on:
the client gets all information about mouse motion, the modifiers, and the
client is in control of the cursor, and everything goes away when the mouse
is released. So I certainly would not expect this to be any different than
a normal automatic grab.

Again I doubt other clients without the pointer focus could start a drag,
and whether there is any reason to support this.


> +       - Other compositor-specific grabs, like pointer gestures.
>

As the gesture may go to the same client, it does not seem like exit events
are correct. Send the gesture-cancel event, and clients have to know this
cancels grabs by the wl_pointer device.

2.5.0
>

If this is possible it seems like a client could also get focus back while
there are buttons held down. How is that handled? I guess you can send
button-down events in the "frame" along with the enter. Though the keyboard
is done differently, by sending a "keymap" event.

Exit events generated by the client's own actions are a huge pain, it
forces clients to look ahead for the enter event to distinguish between the
focus moving to another surface and losing it entirely. This should be
fixed. A few ideas:

1. (my preference) don't send exit events if the enter is going to the same
client. Exit events are "none of your surfaces now have focus". I believe
this is the simplest solution and will not break any client written by a
sane programmer.

2. Sent enter events *before* exit events. Clients can then ignore exit
events for the "wrong" surface. This has the least invasive change to the
api, though I can imagine this breaking some clients.

3. Pair the exit + enter events into a single "frame". This is a new
possible fix introduced by the new frame ideas. The advantage here is that
it really is compatible with any old client.

My personal opinion is that all there should be a single pointer focus per
seat, and the wl_pointer enter/leave events reused for all of these.
Otherwise you are going to end up adding enter/leave events to every new
device api, and sending them all simultaneously. So a better fix would be
to just say that anything using the wl_touch api should obey the wl_pointer
enter/exit events for the same seat. I'm guessing this idea will be tough
to sell here, but wanted to mention it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20151116/3f767b1d/attachment.html>