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

[Jan D.]

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