<div dir="ltr">On Sun, Aug 23, 2015 at 8:19 PM, Jonas Ådahl <span dir="ltr"><<a href="mailto:jadahl@gmail.com" target="_blank">jadahl@gmail.com</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"><br>
1. the pointer "attaches" to the UI element.<br>
<br>
One would create a lock region on the scroll handle. When enabled one<br>
would hide the cursor, create an identical cursor surface and add it as<br>
a subsurface positioning relative to the scroll handle. One would now<br>
listen for events from wl_relative_pointer, update the subsurface<br>
position and the scroll handle widget under it. When done, one would<br>
unlock the lock, destroy the subsurface, and reset the pointer cursor.<br>
During the moving, one would set the cursor position hint so when<br>
resetting the cursor position would be updated.<br></blockquote><div><br>This is the first sign that you have actually thought about this. However you seem blind to the trivial solution. Here is my rewrite of the above paragraph with the set_cursor_pos proposal:<br><br>"One would create a lock region on the scroll handle. When enabled one 
would now listen for events from wl_relative_pointer, update the cursor 
position and the scroll handle widget under it. When done, one would 
unlock the lock."<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">
This is the only way to guarantee the "attachment" effect. There is one<br>
unsolved issue which is that the cursor sprite and the subsurface might<br>
be visible at the same time, and we'd need some kind of "transaction"<br>
protocol to solve this. There has been ideas to have a "set_cursor_pos"<br>
but this method would never give us any guarantees about "attachment".<br></blockquote><div><br></div><div>WTF???. Your proposal is that the client draw a fake cursor in a subsurface and setting that to some x,y position to move the cursor. I propose that the same x,y are sent to set_cursor_pos. THE EXACT SAME NUMBERS!  It is impossible for "attachement" to be different between the two proposals!!!!<br><br></div><div>All I can guess is that you think that there is going to be synchronization between subsurface positioning and the surface image, but for some reason such synchronization will be missing for set_cursor_pos. But why? The cursor surface belongs to the locking client just as much as any subsurface, so any rules for subsurfaces can be applied to it as well. I'd also like to know why suddenly this is important, when you have repeatedly claimed that avoiding latency is more important that sync image updating.<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"><span class="">
</span>If the client wants to control the activation, it can simply request the<br>
lock exactly at the point it wants it to be activated. resize.c in<br>
weston is an example of this - it activates the lock on a pointer button<br>
event.<br></blockquote><div><br></div><div>This is great if it works, however I hope you realize that this will be the ONLY way that any clients with small lock regions will turn on pointer lock. Having to update the "activation region" for every widget on every layout change is extremely bad, it will send large amounts of data to the server for no reason, kind of like old X11 toolkits that sent every widget as a subwindow. This was known to be a mistake back in the mid 80's when lightweight widgets were added to x intrinsics.<br><br></div></div></div></div>