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 n
Hi,
On 19 November 2014 22:41, 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 abou
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
On 18/11/14 05:08 PM, Bill Spitzak wrote:
> I think the dnd client needs to handle normal mouse enter events and set
> the cursor. If the server is not sending an enter right after the drop
> then this is a bug, right?
When dnd_drop_handler triggers (which could be before the enter event
every tim
I think the dnd client needs to handle normal mouse enter events and set
the cursor. If the server is not sending an enter right after the drop
then this is a bug, right?
On 11/18/2014 02:24 PM, Derek Foreman wrote:
When ending a drag in the window the cursor will be wrong until the mouse
is m
When ending a drag in the window the cursor will be wrong until the mouse
is moved again. This is because the item being dragged isn't added
until after the enter event.
This patch stores the input device that last entered the window, and
sets its mouse cursor as new items are dropped.
Closes on
