<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 1, 2015 at 12:57 PM, Carlos Garnacho <span dir="ltr"><<a href="mailto:carlosg@gnome.org" target="_blank">carlosg@gnome.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Thu, Oct 1, 2015 at 8:48 PM, Bill Spitzak <<a href="mailto:spitzak@gmail.com">spitzak@gmail.com</a>> wrote:<br>
><br>
><br>
> On Wed, Sep 30, 2015 at 1:45 PM, Carlos Garnacho <<a href="mailto:carlosg@gnome.org">carlosg@gnome.org</a>> wrote:<br>
>><br>
>><br>
>> - wl_data_source.drop_performed: Happens when the operation has been<br>
>>   physically finished (eg. the button is released), it could be the right<br>
>>   place to reset the pointer cursor back and undo any other state<br>
>> resulting<br>
>>   from the initial button press.<br>
><br>
><br>
> This should not be necessary. When the grab is lost, whatever client is<br>
> under the pointer should get an enter event and should then set the cursor<br>
> to whatever it wants. The dnd source should certainly not set the cursor in<br>
> this case because it may set it to the wrong one, resulting in a blink of<br>
> this wrong cursor (ie it will quickly change between the drag cursor, the<br>
> cursor the source thought it should be, and the actual cursor for that<br>
> screen location).<br>
<br>
</div></div>Remember, toolkits preserve some state. The drag source is in control<br>
of the pointer cursor as long as the DnD operation holds, so it should<br>
reset its internal current cursor to the regular one for the next time<br>
the pointer enters the surface. And that's the bare minimals to be<br>
done there, in X11-land toolkits usually implemented DnD and its<br>
cursor changes through a grab, at least in the case of GTK+ this is<br>
carried on, and brings in a lot more side effects than just an<br>
extraneous cursor, so really can't wait until the next<br>
wl_pointer.enter.<br>
<span class="HOEnZb"><font color="#888888"><br>
  Carlos<br></font></span></blockquote><div><br></div><div>I think you misunderstood. The *destination* (if the cursor is still pointing at it) is what sets the cursor. It should get an enter event the moment the compositor finishes the state where the source can send drag events, and can update the cursor. If the user moves the mouse fast enough perhaps some client other than the destination would get the enter event, and it should set the cursor.<br><br></div><div>Absolutely no way should the source try to do anything to the cursor. All it might do is set it to the wrong image. It has no idea what cursor the client being currently pointed at wants.<br><br></div></div><br></div></div>