Daniel Stone wrote:
OK, so what's the point of focus in and out events, if they can be
sent randomly and in fact provide no indication of whether or not
focus is there?
I think I'm still failing to explain this.
The events are not "random". Focus-in events only go to the surface that
has focus. Focus-out events only go to surfaces that don't have focus.
That is not random.
It's just that a surface that has focus may get more than one focus-in,
and a surface that does not have focus may get more than one focus-out.
I don't think you understand how the focus mechanism works within the
compositor. Without this tracking, we cannot accurately deliver
focus.
Sure you can. A wasteful but perfectly working solution would be for the
compositor, after each frame, to send focus-in to the surface it thinks
has focus, and send focus-out to every other surface.
The motivation behind removing the correctness guaranteed by these
events seems to be 'let's remove all this code from the compositor
(and replicate it in every client)'.
I don't think you understand. EVERY CLIENT WILL DO THIS ANYWAY!!! No
programmer in their right mind is going to rely on perfect pairs of
events from the compositor and I can assure you that every toolkit
written will ignore duplicate focus/button events.
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
