[PATCH weston] dnd: reset the mouse cursor after adding a new item

[Derek Foreman]

On 19/11/14 04:41 PM, Bill Spitzak wrote:
> On 11/19/2014 07:16 AM, Derek Foreman wrote:
> 
>> I'm pretty sure the mouse may have already moved - exactly the same
>> reason as above, this handler is getting the drop co-ords but time has
>> passed since the drop.
> 
> You are right about that. I'm not clear on how input_get_position is
> implemented, did the client record the position of each input, or is
> this some sort of round-trip to the server? If the latter it probably
> should be done differently such as recording it in the motion handler.
> 
> I think you need to change all input cursors when dnd_add_item is
> executed for any reason. Any of them may have changed from a pointer to
> a hand. Imagine if there are two pointers and one is used to drop the
> data at the same location the other is pointing at. So there is no need
> to record the last input, you have to change them all.

Multi pointer.  Sweet.  Guess what, it's not just the cursor that's
messed up - the translucency of the dragged item may be wrong if an item
gets dropped beneath it, or picked up from beneath it.

> You have to not change the mouse cursor on move and enter events while
> waiting for the data. You must not lose the dragged flower until the
> actual flower appears.

I don't understand this requirement - if I don't change the mouse cursor
on enter events while waiting then the cursor will be wrong if a flower
is right at the edge of the window.

I need to make sure I don't change the mouse cursor of any mouse that's
actually dragging an object, I think...  But they should receive a leave
event pretty much immediately at drag start.  Except they don't - if
you're moving the mouse and pick up an item on the fly the cursor is wrong.

I guess because the drag start involves creating the surface to be
dragged, so motion can occur between the click and that actually
happening in the server.

> If there are multiple pointers, it actually looks like it is best if you
> don't change any of them while waiting for the drop data. This will
> reduce the number of transitions they go through. It also appears there
> is a need for stacking order of pointers, the drop one should be on the
> bottom?

I think pointer stacking order is probably a different issue and won't
be dealt with in the dnd example client?

Not sure at all how that should be handled, if at all.  Who's on top:
Last click?  Last enter?  Last motion?  And, ultimately, does anyone
care enough to define what "correct" pointer stacking order should be? :)

> To really remove any possibility of flicker the client also needs to
> enter pointer-lock mode (assuming it works as I want, which is to make
> no changes but to stop moving the cursor except in response to
> positioning commands from the client). This will stop the drop cursor
> image from moving away from the drop location if the user moves the
> mouse before the drop finishes. This may need some server support so the
> cursor stops moving at the time of the drop.

The drop cursor image is just the four way arrow, I don't think it's a
really big deal if it diverges a bit from where the dropped item is
about to appear?  The cursor sticking in place would probably be more
annoying...