Re: Gtk Drag & Drop changes

[Elliot Lee <sopwith cuc edu>]

On Wed, 14 Jan 1998, Owen Taylor wrote:

> > >   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.
> 
> OK, but setting the type to PRIMARY is a bit odd. But if you use
> selections, you don't have to store the data in all the types.  You just
> write code that supplies the data in the various types, set up your
> handlers and let the selection code handle the rest. 

You are not *forced* to store the data in all the types. You are given the
*option*.

I chose XA_PRIMARY because it was the first on the list. I don't think it
matters - in this case, it is just an arbitrary value.

> > 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...
> 
> And modify your protocol to do so while your at it... With selections,
> it just works. (Probably a bit slowly, but I suspect not by more
> than a factor of 2 or so).
> User grabs some text and drags it to another application. After the
> drop event, but before the data is transferred, user quickly grabs
> some different text and drags it to a different application. Window
> property is replaced, target 1 gets the wrong data.
> 
> Yes, the protocol may work most of the time, but it would be nice
> if it was robust against these type of things. An extra message
> isn't all that bad, considering the number that were sent during
> the drag.
> 
> (Speaking of that, the XDE protocol suffers from event-bombing
> in the case of fast source-server connection, slow source-client
> connection, since for motion outside the drag zone, XDE_ENTER
> events are continually sent but not echoed.)

No, because you wait until you get another XDE_REQUEST before you send any
more XDE_ENTER events.

> Say we have a File manager where dropping text onto the "Perl" icon
> means "run the script". User grabs some text in an editor, holding
> down the Ctrl key to force a move, and drops it on the "Perl" icon.
> Script runs, text vanishes.
>
> Now you might argue that this is the right Unixy behavior here.
> (User really wanted to run the script once and never see it again.)

If the user actually presses the Ctrl key in order to specify a "Move",
they get what they asked for exactly. Default behaviour is another thing -
obviously the default behaviour for dragging something to a
non-destructive object should be to keep original data.

> But in general, I don't think this is a friendly way of doing things. 
> The target needs to have some way of specifying whether a "Move" 
> operation is possible. One could come up with examples where it makes
> even less sense. 

I don't see why we need to specify if a "Move" is possible...

> Motif actually implements changing the drag icon to indicate to
> the user what operation is going to take place.
> > 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).
> 
> But only at the time of the _XDE_DROP message. The application can't
> decide earlier and relay that information back to the source (So
> it can change the drop icon) - though the protocol allows it.

Yes it can. It decides when it receives the XDE_ENTER message, and sends
back XDE_REQUEST with the "I will accept the drop" field set to false.

> Sort of. The code I mentioned a while ago is still broken:

I don't doubt it ;-)

> This breaks in the case where we go from IN_ZONE to IN_ZONE.

Oh, in this case, if the mouse pointer stays inside the current drop zone,
then nothing needs to happen.

> > Hmm, yes, also need to define a standard gdk_event_free thing that happens
> > after all event handlers are called.
> 
> Actually, there is already is a gdk_event_free that happpens after
> all event handlers are called. Literally. (But only since about
> a month ago).

Cool.

> Motif has a bit of an advantage in that the protocol only deals with the 
> toplevel windows. That way you can get away with a single
> XQueryPointer. (Which you are probably doing already, if you are
> using MotionHints). But perhaps there isn't a better way for arbitrary
> windows.

OffiX

> But the fact we are doing all these server calls makes overhead for
> confirmation pretty small overhead indeed. (Though it could still be
> argued that it reduces complexity to omit it.)
> > 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()
> 
> It might be nice to have a better default cursor as well...

Agreed, but that can be set from the gtkrc or what have you instead of in
gdk, most likely.

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