<div dir="ltr">On Thu, Nov 12, 2015 at 4:31 AM, Carlos Garnacho <span dir="ltr"><<a href="mailto:carlosg@gnome.org" target="_blank">carlosg@gnome.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The leave events in the respective device interfaces has been further<br>
documented so those can convey the necessary info when input is being<br>
redirected out of their currently focused surface.<br>
<br>
Only wl_touch is missing something semantically similar, a wl_touch.leave<br>
event has been added so the touch interface can cope with such input<br>
redirection situations.<br>
<br>
Changes since v1:<br>
  - Reuse leave events for this purpose. This meant one had to be added<br>
    on wl_touch.<br></blockquote><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
+       Normally, a pointer will not leave a surface while there are<br>
+       buttons pressed, there's however circumstances where this event<br>
+       may be received in this situation, for example:<br></blockquote><div><br></div><div>I have some doubts some of these can happen, or that the need is so rare or esoteric that it might be better to just not allow it at all:<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
+       - When a popup is shown by this or other client.<br></blockquote><div><br></div><div>For "this" client I would prefer that no exit event be sent, only an enter event for the new surface. At the moment these fake exit events are a pain to handle and the client has to add specific code to ignore them (see below). Fixing this would remove the primary reason clients need to be able to peek ahead in the event queue.<br><br></div><div>For "other" clients: are they really capable of making a popup without the pointer focus? It seems like only the compositor could do this, but is there really a need to support this?<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
+       - When a drag-and-drop operation is initiated from this or<br>
+         any other surface.<br></blockquote><div><br></div><div>Again for "this" client, I would greatly prefer not getting an exit event that I have to ignore. And it sure seems like the grab is still going on: the client gets all information about mouse motion, the modifiers, and the client is in control of the cursor, and everything goes away when the mouse is released. So I certainly would not expect this to be any different than a normal automatic grab.<br><br></div><div>Again I doubt other clients without the pointer focus could start a drag, and whether there is any reason to support this.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
+       - Other compositor-specific grabs, like pointer gestures.<br></blockquote><div><br></div><div>As the gesture may go to the same client, it does not seem like exit events are correct. Send the gesture-cancel event, and clients have to know this cancels grabs by the wl_pointer device.<br></div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class=""><font color="#888888">
2.5.0<br></font></span></blockquote><div><br>If
 this is possible it seems like a client could also get focus back while
 there are buttons held down. How is that handled? I guess you can send 
button-down events in the "frame" along with the enter. Though the 
keyboard is done differently, by sending a "keymap" event.<br><div><br></div><div>Exit events generated by the client's own actions
 are a huge pain, it forces clients to look ahead for the enter event to distinguish between the focus moving to another surface and losing it entirely. This should be fixed. A few ideas:<br><br></div><div>1. (my 
preference) don't send exit events if the enter is going to the same 
client. Exit events are "none of your surfaces now have focus". I believe this is the simplest solution and will not break any client written by a sane programmer.<br><br></div><div>2.
 Sent enter events *before* exit events. Clients can then ignore exit 
events for the "wrong" surface. This has the least invasive change to 
the api, though I can imagine this breaking some clients.<br><br></div>3.
 Pair the exit + enter events into a single "frame". This is a new 
possible fix introduced by the new frame ideas. The advantage here is 
that it really is compatible with any old client.<br></div><br><div>My personal opinion is that all there should be a single pointer 
focus per seat, and the wl_pointer enter/leave events reused for all of 
these. Otherwise you are going to end up adding enter/leave events to 
every new device api, and sending them all simultaneously. So a better 
fix would be to just say that anything using the wl_touch api should 
obey the wl_pointer enter/exit events for the same seat. I'm guessing 
this idea will be tough to sell here, but wanted to mention it.<br><br></div><br></div></div></div>