Bill,<br><br>On Monday, 16 November 2015, Bill Spitzak <<a href="mailto:spitzak@gmail.com">spitzak@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>There is a need to distinguish proximity-out from exit events. It is quite possible to move the stylus so that the focus enters another client without doing a proximity-out. Clients are interested in distinguishing these.</div></div></blockquote><div><br></div><div>This is true, hence my suggestion.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>I really feel the best method is to say a "seat" has a keyboard focus and a pointer focus, and let the stylus manipulate the pointer focus. Thus the client will get enter/exit events as the stylus is moved around above the tablet, and proximity in/out when it is moved toward/away from the tablet (it may also get a fake proximity-in event on enter).<br></div></div></div></blockquote><div><br></div><div>Pointer and tablet/touch are separate. X11 integrated them, and _that_ was a huge mistake. From our point of view, this is a closed topic.</div><div><br></div><div>We've been over it time and time again, we've seen the ways the alternate model - though it seems attractive at first, which is why we did it for X11 - fails, and we're not going back there.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>I really feel the cursor stuff is a huge mistake. It adds lots of complexity for almost no actual gain. Witness how much code you had to add to toytoolkit to support it. It adds complexity to clients as the client has to pass which tool to subroutines for no reason other than to allow them to change the correct cursor. The clients cannot assume the tool has the "right" cursor and therefore they are required to have code to change it, so this removes no complexity from clients. It is also hugely inconsistent with how normal pointer enter events are handled in Wayland.<br></div></div></blockquote><div><br></div><div>It's not 'no actual gain', it's integral to the model.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">The only argument you had was that the cursor is more likely to be correct, so when the proximity-in event happens, the cursor that appears has a higher chance of being the same as the one the client sets and there will be less blinking. However this can be implemented by the compositor without any client api. Just have the compositor remember what cursor was used and set that as a guess on the enter event. The client can remain completely unaware of whether a cursor is remembered per-tool, or per-surface, or per tool*surface, or whatever.</div></blockquote><div><br></div><div>The reason the protocol does not do this, is because when the cursor is different, you go from the other-surface cursor, to the old new-surface cursor, to the new new-surface cursor, very rapidly. It's ugly, and a bandaid for clients not responding quickly enough.</div><div><br></div><div>This line has been discussed to death, and we won't be pursuing it any further. I've enjoyed some of your more constructive contributions over the past year or so, but am sad to see you regress back into suggesting rewriting the entire protocol - overriding considered discussion made at the time - because you prefer the superficial aspects of an alternate approach. Please don't make a habit of this.</div><div><br></div><div>Cheers,</div><div>Daniel </div>