[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 17:05:23 +0100

Also, I don't think it is worth doing, it is too complex for very little
user benefit.

Looking at it from my armchair, it doesn't look that complex ;-)
You basically need to do a bunch of keymap lookups rather than a bunch of alist lookups. And you need to create an event, which might indeed be more
work, I don't know.

The problem is more figuring out where the mouse is, i.e. menu bar, scroll
bar or tool bar.  Right now, I just see if the position corresponds to
a window and if not, it is somewhere in those three, the details does not 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.

Better then to accept the drop and put it in the kill ring
if we can't insert it into a buffer.

That's up to the command bound to the event. All that I wanted to point out by my original remark is that it's OK to accept the drop even if the buffer is read-only: we can then signal an error (and/or do whatever else we feel like). Or in more general terms, it's OK to accept a drop before knowing whether the action can be carried through. All we need to figure out really
is *which* type of drop to use.

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.

Also, many programs (all GTK for example) have a visual indicator to
show if the drop can be made or not where the mouse is.  If Emacs just
accepts everything and then signals an error would be bad user interface
IMHO.  Better then to show the user that he can't drop here, or that he
can, but the results have to be manually extracted from the kill ring.

        Jan D.

reply via email to

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