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

[Jan D.]

2004-01-20 kl. 22.12 skrev Stefan Monnier:

> > Later when the mouse moves, the source sends XdndPosition messages,
> > which among other things, contains the suggested action the source
> > wants to do. The target replies with XdndStatus messages.  The answer
> > contains among other things, the action the target wants to perform 
> > (copy,
> > move, private) and if it is acceptable to drop where the mouse is 
> > currently.
>
> Why does the source app send XdndPosition (rather than the target app
> keeping track of mouse movements) ?  Is suh an XdndPosition message 
> sent
> every time the mouse moves within the target's window ?
> What is the purpose of the XdndStatus message?  I.e. how does the 
> source
> use this information?  I can see its usefulness once the drop actually
> takes place, but during dragging I can't think of anything useful the
> source could do with it.

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.
Also if for example, a press on a shift key while dragging means move,
and unshifted means copy, the source must inform
the target that the action has changed.  There is an optimization
where the target in the XdndStatus message tells the source not to
send XdndPosition when the mouse is inside a given rectangle.  But
the target must be prepared to accept XdndPositions anyway, the source
is free to ignore the given rectangle (which indeed GTK does,  Qt honors
the rectangle).

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.  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.

> > So if the mouse travels from the menu bar, to the tool bar, to a read
> > only buffer, to an ordinary buffer, and then to a dired buffer, and 
> > then
> > we do the drop, Emacs must send XdndStatus messages back to the source
> > with different actions in them.
>
> What happens if it just always sends some dummy XdndStatus message 
> instead?
> What happens if it waits for the button-release before sending any 
> XdndStatus?

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.  The target does not get any button release info, the mouse
is grabbed by the source.  The only indication the target gets about
button release is the XdndDrop message, or an XdndLeave message if the
drop was rejected by the last XdndStatus message.

> > > Obviously, if there's no binding for the drop event at the drop 
> > > location,
> > > you should not accept the drop action.  So view-mode could explicily
> > > unbind the drop event, for example.
>
> > As can be seen above, we need to know this before the drop occurs.
>
> That's OK: we can lookup keymaps during the drag to figure out whether
> dnd-drop is bound at the location under the mouse.

That is true.

        Jan D.