[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 21:50:04 +0100

The problem is more figuring out where the mouse is, i.e. menu bar, scroll
bar or tool bar.

Wait.... you're doing it in elisp, right?  That's the problem.
You first need to export the C code that does it.

Yes, I kind of suspected that.

matter.  It may not be a complex thing, but all these events must
interract so that if a drop starts with [menu-bar dnd], then enters
a window, i.e. [dnd], and then exits via a [scroll-bar dnd], the global
data needed for the drop must be synchronized so that it is
correctly updated.

I must admit that I don't understand what you mean by a drop "starting"
somewhere and "exiting" somewhere else. My understand of a drop is "release
the mouse button" which is instantaneous.

Or are you talking about the drag part and saying that Emacs should somehow
highlight the object to which the drop is going to apply ?

Drag and drop is no where near instantaneous as for example copy-paste is. I'll outline it here, restricted to XDND, but other protocols are similar.
The way it works is the the target (Emacs) puts a property on the window
that tells other apps that it can do drag and drop, XDND style.
When a user drags something from a file manager for example (the source),
the source keeps track on which application that is under the mouse.

When the mouse enters an application that can do XDND, it sends an
XdndEnter message (i.e. drop starting). The target does not reply to this,
but when it gets this message, it can see what types the source offers
for the drop data.

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.

If the mouse is the moved out of the target, the source sends
a XdndLeave message, and the target forgets the whole thing.

If the mouse button is released, the target sends XdndDrop, and this
is the "release button" you talk about.  At this point, the target
can retreive the data, and do with it what it wants.  The target
sends XdndFinish to the source, and the drop ends.

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.  Possibly we want to do private on
the menu bar and tool bar, not accept the drop in the read only buffer,
then send private again when entering the ordinary buffer, and then
send the action the target suggests (move, copy) when entering the
dired buffer so that dired acts like a file manager.

So there is a lot of talk going on, and Emacs needs to determine what
to send in the XdndStatus messages, based on where the pointer is,
what kind of buffer we are over, and take into account the user
preferences (i.e. insert the file name in abuffer instead of opening it).

And remember, XDND is said to be a simple dnd protocol :-).

I don't feel comfortable with accepting a drop and then signal an error. I think this goes a bit against the "spirit" of drag and drop in a small
way.  The reason why the source of the drop gives a list of types and
a suggested action (copy, move etc.) at the start of the drop is just
so that the target can decide if to accept the drop or not.

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.

        Jan D.

reply via email to

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