[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Jan D.
Subject: Re: Drag and drop patch for X, please review.
Date: Tue, 20 Jan 2004 22:27:58 +0100

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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]