wl_tablet specification draft

[Bill Spitzak]

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 <spitzak at gmail.com>:
>>
>>
>> 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
>> wayland-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel