Re: Gtk Drag & Drop changes

[Owen Taylor <owt1 cornell edu>]

[I'm cc'ing this to gtk-list, since I think that is the right
forum for discussing changes to GTK. It may not be of general
interest, but I suspect some people there will want to see it.]

I'll include the comments I've been promising on DND as well as a
specific response to Elliot's message. I started off trying to write
something that would be coherent to a DND non-expert, but that proved
to be just to much work.

In lieu of that, here is a short web bibliography on DND.

* http://www.premier.sco.com/guide/MotifProgGuide/en_US/Drag_and_Drop.html

 Includes a thorough description of Motif's bells-and-whistles variant
 of DND from a user's point of view (useful), and from the point of view
 of the Motif programmer (less so). Doesn't describe the protocol.

* http://www.cco.caltech.edu/~jafl/xdnd/

 Description of John Lindal's Xdnd protocol.

* ftp://ftp.gimp.org/gtk/gtk+-0.99.2

 "Description" of the Xde protocol ;-)

* http://www.igpm.rwth-aachen.de/~albrecht/hungry.html

 "Inside Lesstif" book. By far the best description of Motif DND
 available, though still incomplete in regards to the Pre-register
 variant.

=========

Two major problems with Xde:

* There is no way of telling whether an application supports the Xde
protocol or not. (Except for seeing if it responds to messages).  This
makes it impossible to properly support this protocol on the drag end
along with other protocols. (Xdnd sets a Xdnd aware property on the
window, and Motif does something similar.)

* Data is not transferred via the selection, but by setting
a property on the source window.

  Property name = atom for drag type (!)
  Property type = XA_PRIMARY         (!!!!!!!)

If nothing else, using the selection would keep this type of
odd choice from being made. But more also,

  Using the selection gives the possibility of using INCR style
  transfers (required by the ICCCM). Otherwise it may be
  impossible to transfer large amounts of data across a server 
  with little memory.

  Using the selection can facilitate code reuse, since toolkits
  should already have a good implementation of selections.

  And since Motif and Xdnd use the selection, if we _have_ to
  have our own protocol, it would make things easier to organize
  if it used the selection as well.


Problems with Xdnd _and_ Xde:

* There is no way of telling if a drag operation finished
successfully. (In Xdnd, the target justs asks for the selection.
One could assume that if the selection transfer finished successfully,
then that was the end of the drop. But it might make sense to
ask for multiple targets. For Xde, the situation is even worse.
The source just has to keep the data in the window property
until things are deleted)

This means:

  If a destructive operation is being performed (Possible with
  Xde, maybe possible with Xdnd) data could be lost since there
  is no confirmation of success/failure.

  Feedback animation isn't possible. (Motif has snapback for
  failure (nice) and melting for success (for me, highly 
  disturbing, for some reason)

In Motif, success/failure is represented by requesting special
targets.

* Data types are represented by MIME types, _interned as X atoms_.
While this makes sense in some ways, interning arbitrary strings
as atoms is certainly against the spirit of the ICCCM. The alternate
approach is to use the standard ICCCM targets, suitably enhanced.
(Motif does this, so a translation table would be necessary
when taking the first approach.)

I like the MIME types better than the ICCCM approach, really,
_except_ for the fact that we need to use the ICCCM approach
when doing selections, clipboard cut-and-paste, and Motif DND.

* The methods of specifying the operation are weak in both 
protocols. (By comparison, the operation move/copy/link is
negotatiated separately in Motif dnd.)

  Xde by default copies, but can specify linking by using
  a target URL:text/plain, etc. (And then passing the URL
  as the contents of the URL). The target application can
  also request that the operation should be destructive by
  setting a flag.

  Xdnd copies, but can also specify "mime types"
  url/url (target decides?) url/copy url/move and url/delete.
  (No other mime type is specified for these)

Both of the above approaches suffer badly from the fact that
the operation is usually partially chosen from the _source_ side.
(I.e., in Motif, it is specified by holding down modifier keys
while dragging - and therefore the user can change the operation
during the drag, necessitating a special client message.)

Of the two approaches above, Xde's is probably marginally better.
(More flexible). Neither is very good.

* For Motif DND, the user can request help by pressing F1 over
a drop site while dragging. This isn't possible for either
Xdnd or Xde. (But something better, tooltips for drag sites
probably is, at least for Xdnd which can continue optionally continue
sending motion events to the target while over a drop site.
(Motif also has ESC=cancel, which might be useful, if root
window drags were in effect, probably not otherwise - easier
just to move off a drop-site)

* The client messages don't pass timestamps for the triggering
mouse events. This probably will lead to some race conditions
under high load.

Some of the above notions are more in the line of "It's not
Motif" which may actually be good. The Motif standard is highly
complex, and some of the features are of dubious utility.  But I
think that the confirmation problem especially, and also the
"operation-specification" issue _are_ important.

I'd be interested to hear what problems you (that is Elliot) had
with the Xdnd spec. My own impression is that it Xde a bit better
in operation-specification, and might also be somewhat more
efficient in server traffic. Otherwise I don't see the big
advantages of it. (That would justify us going to a GTK specific
protocol.) But since I haven't seen a specification for Xde,
perhaps I'm missing some things.

======

And finally, we get to the actual reply...

Elliot Lee <sopwith@cuc.edu> writes:

> I've been pondering some issues with Drag & Drop. While it works pretty
> well (I've just fixed a race condition in it), it's not perfect.
>
> Here are some ideas I'd like to put forward:
> 
> 	- It needs to be moved from gdk into gtk, simply because 
> 	we will have to provide saner gtk wrappers anyways, and because
> 	D&D needs to know more about widgets than it does about
> 	GdkWindows...

I've been arguing this for a while. Some portions anyways. 

 - Setting/receiving data needs to be in GTK. (because selections are
   there.)

 - Event handling for the drag should probably be in GTK - I don't
   think complex event handling belongs in event_translate.

 - I'd be inclined to leave deciphering client messages in GDK if
   possible. (Question is, can we define generic events that
   communicate all the information that the code in GTK needs)
   Although we already have support for passing client messages
   to applications, I see this as low-level GDK type stuff.
  
> 	- The various operations and signal calls need to be abstracted
> 	from the protocol, so we can add new protocols (i.e. Motif) fairly
> 	easily

Yep. Forming the abstractions is the hard part. (If everybody used
selections for the drop protocol, things would be a bit easier...) I
won't make this message even longer by proposing anything right
now. Some thought will have to be given to just what capabilities an
application can have:

 - Can an application decide whether to accept or reject a drag based
   on the dynamic contents of the drag. (All the protocols support this, 
   but it makes the API considerably more complicated)

 - Should we support full Motif style operation selection, or just
   use something simpler, and map that onto a portion of the Motif
   protocol.

 - Will we support drop sites that are only a portion of the widget?
   Multiple drop sites per widget?
   
etc.

> 	- (Not likely, but a nice puzzler for your idle moments)
> 	Any ways we can integrate OffiX support without totally
> 	destroying the sanity of the framework?

Maybe, maybe not. I refuse to spend my idle moments on it.
 
> I'm planning to do these immediately *after* the gtk+ 1.0 release. Any
> comments or ideas on other improvements that are needed?

A few things I noted while reviewing the code:

- The Code for LeaveNotify in gdk_event_translate looks like it
was copied verbatim from EnterNotify, making it completely reversed
from what it should be.

- The data in the Response event needs to be correctly handled
in gdk_event_copy, etc. 

- Some places use LONG_MAX. That should be G_MAXLONG

- We need to find a better way of identifying windows than querying 
the tree on each motion event. (I'll take a look at that further)

And some general future improvements:

- The current code needs a window for the drop zone. (The protocol does
not.) One should be able to drop on pixmaps, etc. without windows.
The dropzone should be on a per-widget basis. (Do we need multiple
dropzones per widget?)

- As a stopgap-measure/fallback for shaped window dragging, we
need to create some pixmap cursors for DND. The default cursor
font cursors are completely inadequate. 

- The client probably should have a way to specify the shaped pixmap
(and B&W pixmap for the cursor?) for the drag. I think having the drag
icon mirror the source makes DND considerably more intuitive.
(Translucent dragging like MacOS 8 would be the ultimate thing to
have, but probably is impossible on X, excluding high-end graphics
hardware.)

Regards,
                                        Owen