Re: Drag and drop protocol in Gtk?

[Owen Taylor <owt1 cornell edu>]

Miguel de Icaza <miguel@nuclecu.unam.mx> writes:

> Hello guys,
> 
>    I took a quick look at the comparission of the Xdnd and Xde drag
> and drop protocols (follow the link at http://www.gnome.org/devel/arch/dnd.html)
> and I am not quite sure that the current Xde protocol provides any
> real advantage over the Xdnd protocol.

I spent a fair bit of time thinking about this this afternoon,
and I'm basically in agreement. However, from my perspective, Xdnd
has a couple of fairly big holes.

> 
>    From the gnome web page:
> 
> > The differences between Xde and Xdnd are: 
> > 
> > 	  Better handling of copy/move/link operations (i.e. you can
> >         know what type you are copying/moving/linking) 
> >
> > 	  Fuller ICCCM compliance 
> > 
> > 	  Integrates the "drop is finished" notification into the
> >         protocol instead of using the X selection protocol, reducing overhead
> > 	  and allowing the user greater flexibility for data transfer. 

 
> Point (1) is apparently addressed by the Xdnd protocol in a nice way
> (http://www.cco.caltech.edu/~jafl/xdnd/dragging_files.html).

This is one of the most unsatisfactory points of Xdnd. (And the one
place Xde is a little bit better). Operation specification in Xdnd can
only be done if you don't need to transfer a file type as well. Plus
its a pretty clumsy way of doing things - the source and target need
to cooperate in choosing the operation, and the source needs to be
able to say which operation the user has chosen. (By pressing
modifiers keys, perhaps.) This doesn't work out very well with
the url/xxx scheme.

I think the Xdnd could support this pretty easily. Basically, 
the source would give a list of possible operations and a
recommended operation to the target, and the target would select
which one it wanted in its XdndStatus message. The source then
would echo that back in the XdndDrop message. There is plenty
of unused room in the flags.

This is a compatible subset of the way Motif handles things and
is quite simple. I've proposed it to John Lindal, but he didn't
leap on it... 
 
> The reason for Point (2) is not very well documented, but as far as I
> can see (from the discussion Owen and Elliot had), using the X
> selection code for achieving this goal seems to be better, and thus it
> should be more ICCCM compliant :-)

I don't think Xde is any more compliant. Neither Xdnd or Xde really
complies with the way the ICCCM suggests naming targets, but they 
are identical in that. And the way they do it has some real advantages.
 
> Point (3) about the overhead of the drag and drop protocol:  I do not
> really think that this extra "overhead" [1] is worth being
> incompatible with Qt/KDE and the JX protocol.  

I don't think the overhead is worth worrying about at all. The
other part of point 3 is just wrong. Xde provides _no_ finished
confirmation, and that can easily lead to lost or corrupted data.

But this is the other place where Xdnd has problems. Version 1 of the
protocol solves the corrupted data problem by sending timestamp data
along with the messages. But there is no way of supplying a interface
to the application, that is simple, and safe as far as I can see:

With, for instance, the Motif DND protocol, you can simply block
anything from happening in the source application until the
drop finishes. If this isn't considered satisfactory, then it would
be easy to provide an _optional__ more complicated interface.

If things can continue happening during the drop, then the source
application has to keep a copy of the data around until the
target asks for it. But if there is not a "finished" confirmation,
you have to keep the data around forever...

When you don't have destructive operations (current Xdnd), then the
problem isn't that big. You can just store one set of data, and if a
second drag forces you to discard that data, you can just reject the
requests for it, and no harm is done. If the operation is destructive,
than the data has vanished, and you may have a very unhappy user.

So you are forced to keep a history of drags, without being able
to know when to delete them. (You probably can safely just keep
3-4) But this is a memory waste, and also has makes things very
hard on the application programmer. (The toolkit can't store
the data, because it isn't known until the target makes the request
which form of data it will request) 

Even if you are just keeping a single history (sufficient for current
DND), it still isn't nice for the programmer.

So I think if those two simple changes were made (operation
negotation, and a XdndFinished) then Xdnd would really be the
way to go. Its not impossible that we could get a new version
of Xdnd that included these two. 

If not, I'd be almost tempted just to bite the bullet and implement
Motif DND. It's a bear, and stuffed with things we don't need - but I
think those could be ignored, and it is, at least, not lacking
anything essential. But that is definitely not going to happen for Gtk
1.0.

> I am worried about the DND state on Gtk as apparently nobody has
> done any extensive testing on it and the 1.0 release date is
> approaching.  I would like to see Gtk 1.0 ship with the Xdnd protocol
> instead of the currently incompatible Xde protocol.

I'm not sure what will be in 1.0 - I'm hoping to get any necessary API
changes done by then, but I'm not sure implementing Xdnd before next
Thursday is all that practical. I don't think it is horrible important
if the DND in 1.0 is final and rock-solid - simply because the GIMP
does not yet use DND, and that is the main point of the release.

But I'll do what I can.

Regards,
                                        Owen