Re: Drag and drop patch for X, please review.

[Jan D.]

> > To simplify for the target.  It may also be that there are several
> > pointer devices (indeed, on my laptop, I can use three mice at the 
> > same
> > time), and the target can not know which one is used.
>
> I've seen and used multiple mice, but they always all applied to the 
> one and
> only on-screen-cursor.  So from an Xclient point of view, there's 
> really only
> one input device (which is composed of several mice).

It is not a strict requirement.  There can be multiple pointer devices.
In some accessibility functions you can simulate the mouse actions
with arrow keys.

> > XdndStatus tells the source if the drop is accepted, and the above 
> > mentioned
> > rectangle.  The source uses the accept/reject status to change the
> > icon that is being dragged so the user can visually see if drop is
> > accepted or rejected where the mouse is now.
>
> Talk about stupid design: the user is obviously looking at the target 
> while
> dragging, so any indication should happen there rather than at the 
> source.

The icon I am talking about is the one the user drags, i.e. it is
where the pointer is.
It is actually recommended that the target does some visible indication
also, such as highlight the window border.  Most apps doesn't do that.  
The
target can not have control over any visible indication at the pointer,
first the source has grabbed the pointer, secondly the drop starts
at the source, so what the dragged icon looks like is not known by
the target.

> It would also eliminate this need for constant XdndStatus 
> communication.
> I'm obviously missing something.

The status messages are mostly a way for the target to change the state,
i.e. change reject/accept and/or change the rectangle where it does not
want more position messages.

> > Also, if the mouse button is released and the last XdndStatus said 
> > reject,
> > the source usually does a bit of animation so the dragged icon is 
> > "snapped
> > back" to where the drag started.
>
> But that could be triggered by a XdndReject response to XdndDrop, so it
> does not justify XdndStatus.

In the XdndFinished message the target tells the source if the drop
was successful or not.  But the XdndStatus messages are needed anyway
to inform the source if it should send a XdndDrop at all.  The
XdndFinished is only to be sent after a XdndDrop message.

> > If we don't send any XdndStatus, the source will conclude that the
> > target can not accept any drop whatsoever, and never send the XdndDrop
> > message.  A dummy is no good, we at least needs to set accept/reject
> > correctly.
>
> Seems like `accept' would be a good dummy, if needed.

Then we are back to saying accept and then later perhaps signal
an error.  I do not like that.  If we know we are going to raise an
error, we should not accept the drop in the first place.

        Jan D.