I meant a type of popup that stays up when the button is released. I
think in Wayland terms it is a child or transient-for window, not what
it is calling a "popup" in wl_shell.
This is a real problem and anybody who has written a popup menu system
would know about it.
I do think the problem can be worked around by the client looking in the
*same* block of events received from the compositor to see if there is
an Enter event after the Exit. This is a bit annoying because it
complicates event processing by requiring the ability to mess with the
event queue in response to an event. Also all transports used for
wayland communication must not break up blocks of events. But the client
does not have to do an additional sync and wait while processing exit
events.
A solution that would change things very little is to send the Enter
before the Exit. Then clients could process events as it gets them
without lookahead.
A more intrusive fix is to replace Enter/Exit entirely with a transition
event that says what surface the mouse is leaving and what one it is
entering (using null for surfaces belonging to other clients).
On 07/02/2014 12:20 AM, Giulio Camuffo wrote:
2014-07-02 1:55 GMT+03:00 Bill Spitzak <[email protected]>:
On 07/01/2014 12:35 PM, Jasper St. Pierre wrote:
"A blink in the highlighting"?
Yes. Say the client wants to highlight the button being pressed and it has
popped up a menu, If the mouse is moved from the button to the menu, the
client wants to keep the button highlighted.
If in fact the server sends an "exit" event and then an "enter" event for
the menu, a naive client will draw the button un-highlighted (since as far
as it knows the exit was because the mouse entered a different client's
window) and then when it sees the enter it has to draw it again highlighted.
If it does a commit, the user will see it blink. This is wrong.
If the client hasn't received a "popup_done" event it knows the popup
is open and has the focus, so it knows it should keep the button
highlighted in your example.
Not sure if you have other examples, I can't think of any where having
enter/exit events is a problem.
--
Giulio
Now obviously the client can wait (I think actually zero time because it
should be in the same block of events) and see if there is an enter event,
but it would be a lot easier on the logic if it did not get the enter event
at all!
This is not a joke, these sort of problems make toolkits annoying and
complex to write.
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
