Re: Gtk Drag & Drop changes

[Elliot Lee <sopwith cuc edu>]

On 13 Jan 1998, Owen Taylor wrote:

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

ftp://ftp.red-bean.com/ has a good one on official Motif, somewhere. It's
the one I read, anyways.

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

What we can do is just require that _XDE_TYPELIST be set, even if it is
zero-length.

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

I see that as an advantage. From what I understand, using
XConvertSelection (or whatever Gtk wrapper you have) would make it
impossible to differentiate between a paste and a drop.

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

With this scheme, you can store the same data in different formats on the
window, and when a drop target asks for it, it's already there.

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

I discussed this with Marc & Mike & Carsten (the RHAD Labs team) and
probably what we will want to do is not use INCR at all, just define
different possible methods of transfer, and let the applications negotiate
them. X is not meant to be high performance data transfer anyways - if
you're transferring a huge file, negotiate a direct connect...

> * 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) 

You *always* assume that if the application says that it will accept the
drop, and no X errors ensue from sending the drop event, that the drop
happened. This is to eliminate a round trips.

BTW Gtk needs to handle X errors a lot better. Would be nice to have a
stack of error handlers to push and pop on, or perhaps support for a
try/catch type of thing...

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

You know that it happened, so you can do your animation.

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

Well, when in Rome, do as the Romans do. We can find some MIME type ->
ICCCM crap name converter for use with Motif etc.

I also am somewhat ambivalent to follow a standard that doesn't give us
the flexibility we need...

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

Right, but that lets you specify move/copy/link - what's the problem?

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

I don't see how it suffers, especially seeing as the operation is chosen
by the target side (it returns that destructive vs. non-destructive in its
reply message). If the source wishes to delete the original data source
after the target has used it, that's its own business - the flags field is
just so that the destination can "force" the source to delete it (or not),
e.g. if you're dragging to a trash can you want to delete it no matter
what the user specifies, whereas if you're dragging from the "undelete"
area of the trash can, you may not want to remove it from the trash can no
matter what.

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

We can add it easily, that's what the protocol_version field is for.
(Actually, it's easier than that. Just set a property _XDE_DROPHELP)

Honestly, I think this is bloat.

> (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) 

ESC=cancel can be done without changing the protocol, it's just a matter
of implementing it. 

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

This needs to be looked into a bit, but I'm pretty sure that almost all
events of
time

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

Hmm, yea, I'm inclined to agree with these more or less. We'll get to the
details later on.

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

Our API allows for this theoretically, already. I just didn't support it
for drags from Gtk apps, yet. (It is supported for drops to Gtk apps).

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

It's possible, I just didn't feel like coding it. The support for it is
there for drags, though (I think).

> Maybe, maybe not. I refuse to spend my idle moments on it.

Hehe.

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

I know there is a race condition somewhere, this might be it. Take a stab
at it before 1.0, please...

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

Hmm, yes, also need to define a standard gdk_event_free thing that happens
after all event handlers are called.

> - Some places use LONG_MAX. That should be G_MAXLONG

This can be fixed right away...

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

I've looked for it. There isn't any way AFAIK, but perhaps the other Xlib
experts out there can find one.

> - 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?)

We can do this, this is the "drop sites" feature mentioned above.

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

No, we need to implement a way for the application to tell Gdk what cursor
to use whenever a drag starts up. It shouldn't be hard either, just modify
your drag_begin signal handler to do a
gdk_set_dnd_default_cursor_to_this()

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

Well, yes. A wrapper to do this semi-automatically probably can go into
gnome...

*sigh* I've probably left something out,
-- Elliot					http://www.redhat.com/
"They don't let my code go into shipping products," Gates said. "They
 haven't done that for eight years." (at the 1997 PDC)