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.
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
