wl_tablet draft v2

[Bill Spitzak]

On 08/27/2014 04:15 AM, Pekka Paalanen wrote:

>> That describes the situation pretty closely, except the action is on
>> some subset of the wl_surfaces (for instance, only on the wl_surfaces
>> that belong to the client).
>
> What I described in the quote above was just a meaningless chain of
> abstract happenings, that in my imagination has no use in the real
> world, that is, a use case.
>
> Help me, explain what real use case would match that chain?

	+--------THIS CLIENT WINDOW--------+
	|    [HIGHLIGHTED SELECTION]       |---OTHER CLIENT-----+
	|                               3----> 4                |
	|                    +--------DIALOG BOX--------+       |
	|                  1---->2                      |-------+
	+--------------------|                          |
	                     +--------------------------+

The highlighted selection should remain highlighted as long as the 
cursor is pointing either at "this client window" or "dialog box", but 
not when it is pointing at "other client".

However cursor motion 1---->2 and 3---->4 produce identical exit events. 
But only 3---->4 should redraw the text with the highlighting turned 
off. The client cannot tell whether to do this unless it uses lookahead 
to see if it gets an enter event for the dialog box.

This problem also applies to keyboard focus, activation, drag and drop, 
and any other resource that is transferred between surfaces.

The simplest fix would be to send the enter event before the exit event, 
or not send the exit event at all if an enter will be sent. A more 
intrusive but nicer fix would be to merge all the enter+exit pairs into 
single events. They would send the id of the new surface (the client can 
easily remember the old one), sending zero for surfaces belonging to 
other clients.