From karl@ruf.uni-freiburg.de
Received: (qmail 19935 invoked from network); 3 Jan 1998 21:45:08 -0000
Received: from sun2.ruf.uni-freiburg.de (132.230.1.2)
by mail2.redhat.com with SMTP; 3 Jan 1998 21:45:08 -0000
Received: from ruf.uni-freiburg.de (karl@slip97.home.uni-freiburg.de [132.230.2.97])
by sun2.ruf.uni-freiburg.de (8.8.5/8.6.9) with ESMTP id WAA22101 for
<gtk-list@redhat.com>; Sat, 3 Jan 1998 22:45:03 +0100 (MET)
Sender: karl@ruf.uni-freiburg.de
Message-ID: <34AEACAC.78C9FF6@ruf.uni-freiburg.de>
Date: Sat, 03 Jan 1998 22:25:00 +0100
From: Robert Roebling <roebling@ruf.uni-freiburg.de>
X-Mailer: Mozilla 4.03 [en] (X11; I; Linux 2.0.29 i586)
MIME-Version: 1.0
To: GTK mailing list <gtk-list@redhat.com>
Subject: Drag and drop
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Good day,
if I want to drag and drop files the way, it's done
by a filemanager, which dnd-types do I have to use.
It would of course be possible to use the mime-type
"text/plain" and to list the files in the data section
as a string list, but is that the way that was planned
to be used for that purpose?
I found the (re)definitions of Offix types in gdk/gdktypes.h,
but they are not used anywhere. When using the original
offix protocol I used the DND_FILES type. I don't know
how to express that dnd-type with mime-type strings. Can
that be done or how can I implement a filemanager?
Thanks and regards,
Robert Roebling
From atai@ece.ucsd.edu
Received: (qmail 8751 invoked from network); 3 Jan 1998 22:32:21 -0000
Received: from mailbox1.ucsd.edu (132.239.1.53)
by mail2.redhat.com with SMTP; 3 Jan 1998 22:32:21 -0000
Received: from vision.ucsd.edu (vision.ucsd.edu [132.239.223.49])
by mailbox1.ucsd.edu (8.8.5/8.6.9) with ESMTP id OAA08061 for
<gtk-list@redhat.com>; Sat, 3 Jan 1998 14:32:20 -0800 (PST)
Received: (from atai@localhost)
by vision.ucsd.edu (8.8.5/SOEGW-PSEUDO-4.2-SunOS-8.6.x)
id OAA07536; Sat, 3 Jan 1998 14:32:17 -0800 (PST)
for gtk-list@redhat.com
From: atai@ece.ucsd.edu (Andy Tai)
Message-Id: <199801032232.OAA07536@vision.ucsd.edu>
Subject: drag and drop protocol: compatible with gtk?
To: gtk-list@redhat.com
Date: Sat, 3 Jan 1998 14:32:17 -0800 (PST)
X-Mailer: ELM [version 2.4 PL23]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
I saw the following announcement from comp.windows.x.announce:
----
From: jafl@cco.caltech.edu (John Lindal)
Subject: Drag-And-Drop protocol for X Windows
Newsgroups: comp.windows.x.announce
Date: 3 Jan 98 15:40:32 GMT
Organization: California Institute of Technology, Pasadena
Approved: k.keithley@opengroup.org
Message-ID: <199801031540.KAA02491@postman.opengroup.org>
Xref: soenews.ucsd.edu comp.windows.x.announce:194
With help from Arnt Gulbrandsen at Troll Tech and Elliot Lee from RedHat
Software, I have developed what we believe to be an efficient, complete,
safe, and easy to understand protocol for intra- and inter-application
Drag-And-Drop under X Windows. Arnt has implemented it in Troll Tech's Qt
widget library, I have implemented it in the JX application framework, and
we have proved inter-operability of the two implementations, thereby
allowing users to exchange data between any Qt program and any JX program.
We strongly urge other developers to consider supporting this protocol so
end users can get the maximum benefit from Drag-And-Drop. Both sample
source and a test program that can be used as both drag source and drop
target are available. The protocol is described at
http://www.cco.caltech.edu/~jafl/xdnd/
Sincerely,
John Lindal
----
Is this the same protocol implemented in gtk? Else, would it be benefital to
try to make them compatible?
--
Li-Cheng Tai (Andy Tai) e-mail: atai@ece.ucsd.edu
Free software: the software by the people, of the people and for the people,
worldwide. Develop! Share! Enhance! And enjoy!
From owt1@cornell.edu
Received: (qmail 28839 invoked from network); 3 Jan 1998 23:21:59 -0000
Received: from cu-dialup-1903.cit.cornell.edu (qmailr@132.236.155.29)
by mail2.redhat.com with SMTP; 3 Jan 1998 23:21:59 -0000
Received: (qmail 16610 invoked by uid 504); 3 Jan 1998 23:24:17 -0000
To: gtk-list@redhat.com
Subject: Re: [gtk-list] drag and drop protocol: compatible with gtk?
References: <199801032232.OAA07536@vision.ucsd.edu>
From: Owen Taylor <owt1@cornell.edu>
Date: 03 Jan 1998 18:24:17 -0500
In-Reply-To: atai@ece.ucsd.edu's message of Sat, 3 Jan 1998 14:32:17 -0800 (PST)
Message-ID: <lz90sxdtum.fsf@cu-dialup-1807.cit.cornell.edu>
Lines: 41
X-Mailer: Gnus v5.5/Emacs 20.2
X-Emacs: Emacs 20.2, MULE 3.0 (MOMIJINOGA)
MIME-Version: 1.0 (generated by SEMI MIME-Edit 0.98 - =?ISO-8859-4?Q?"D=F2?=
=?ISO-8859-4?Q?h=F2ji"?=)
Content-Type: text/plain; charset=US-ASCII
atai@ece.ucsd.edu (Andy Tai) writes:
> I saw the following announcement from comp.windows.x.announce:
> ----
[...]
> With help from Arnt Gulbrandsen at Troll Tech and Elliot Lee from RedHat
> Software, I have developed what we believe to be an efficient, complete,
> safe, and easy to understand protocol for intra- and inter-application
> Drag-And-Drop under X Windows. Arnt has implemented it in Troll Tech's Qt
> widget library, I have implemented it in the JX application framework, and
> we have proved inter-operability of the two implementations, thereby
> allowing users to exchange data between any Qt program and any JX program.
> We strongly urge other developers to consider supporting this protocol so
> end users can get the maximum benefit from Drag-And-Drop. Both sample
> source and a test program that can be used as both drag source and drop
> target are available. The protocol is described at
>
> http://www.cco.caltech.edu/~jafl/xdnd/
>
> Sincerely,
> John Lindal
> ----
> Is this the same protocol implemented in gtk? Else, would it be benefital to
> try to make them compatible?
What is implemented in GTK is a earlier version of this protocol.
It won't interoperate right now, but presumably the protocol in GTK
will be updated to conform. Looking at the web page, it is a definite
improvement over what is in GTK now, though I'm still not completely
satisfied with it. It does a pretty good job at being a nice simple,
lightweight protocol.
Personally, I'd like to use this opportunity to reorganize DND in GTK
so that we can later add Motif DND interoperability without changing
the the API. (And also clean up some of the mess in
gdk_event_translate.) I'll put out a proposal in the next day or two.
Owen
From agulbra@troll.no
Received: (qmail 13797 invoked from network); 4 Jan 1998 01:17:26 -0000
Received: from lupinella.troll.no (195.0.254.19)
by mail2.redhat.com with SMTP; 4 Jan 1998 01:17:26 -0000
Received: by troll.no id <79619-13799>; Sun, 4 Jan 1998 02:17:14 +0100
To: gtk-list@redhat.com
Subject: Re: [gtk-list] drag and drop protocol: compatible with gtk?
References: <199801032232.OAA07536@vision.ucsd.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
From: Arnt Gulbrandsen <agulbra@troll.no>
Date: 04 Jan 1998 02:17:11 +0100
In-Reply-To: atai@ece.ucsd.edu's message of "Sat, 3 Jan 1998 14:32:17 -0800 (PST)"
Message-ID: <m3btxtt4vc.fsf@lupinella.troll.no>
Lines: 15
atai@ece.ucsd.edu (Andy Tai)
> http://www.cco.caltech.edu/~jafl/xdnd/
...
> Is this the same protocol implemented in gtk?
As far as I know, the protocol used in gtk is a close cousin of the
one specified in this document. That said, I haven't seen any actual
specification of the one used in gtk.
> Else, would it be benefital to
> try to make them compatible?
IMHO, interoperability is the whole point of drag and drop :)
--Arnt
From sopwith@cuc.edu
Received: (qmail 15470 invoked from network); 4 Jan 1998 03:57:45 -0000
Received: from helix.cs.cuc.edu (HELO cuc.edu) (sopwith@207.222.40.128)
by mail2.redhat.com with SMTP; 4 Jan 1998 03:57:45 -0000
Received: from localhost (sopwith@localhost)
by cuc.edu (8.8.5/8.8.5) with SMTP id WAA20917
for <gtk-list@redhat.com>; Sat, 3 Jan 1998 22:57:39 -0500
Date: Sat, 3 Jan 1998 22:57:39 -0500 (EST)
From: Elliot Lee <sopwith@cuc.edu>
X-Sender: sopwith@helix.cs.cuc.edu
To: GTK mailing list <gtk-list@redhat.com>
Subject: Re: [gtk-list] Drag and drop
In-Reply-To: <34AEACAC.78C9FF6@ruf.uni-freiburg.de>
Message-ID: <Pine.LNX.3.95.980103224048.16926B-100000@helix.cs.cuc.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Sat, 3 Jan 1998, Robert Roebling wrote:
> if I want to drag and drop files the way, it's done
> by a filemanager, which dnd-types do I have to use.
> It would of course be possible to use the mime-type
> "text/plain" and to list the files in the data section
> as a string list, but is that the way that was planned
> to be used for that purpose?
Nope. text/plain means a text document, any type of text document.
> I found the (re)definitions of Offix types in gdk/gdktypes.h,
> but they are not used anywhere. When using the original
> offix protocol I used the DND_FILES type. I don't know
> how to express that dnd-type with mime-type strings. Can
> that be done or how can I implement a filemanager?
The OffiX stuff is a hangover from when there was OffiX support in Gtk.
First of all, the way to drag multiple files is to use
gtk_widget_dnd_drag_add() inside a drag_begin_request signal handler., not
by passing a list of files.
For each of those widgets that you add, it should be set up with
gtk_widget_dnd_drag_set(), and the type_accept_list should include the
type specific to each file. For example, if someone was dragging a .jpg
image from your file manager, you would specify type_accept_list to be
"url:image/jpeg", "image/jpeg" to specify that your file manager can offer
the drag target either the URL to or the content of the .jpg image.
You cannot assume that the person will always be dragging things from your
file manager to your file manager. For example, they may well be wanting
to drag this image to the GIMP to edit it, which is why you have to be
ready to offer the content as well as the filename/URL. (The
"url:typename" is just a convention I plan on using to allow
distinguishing between URL's and file contents - some programs can operate
only on one or the other).
Read header files and source code, it's good for you ;-) It's probably the
most helpful place at this point, along with asking on the list.
-- 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)
From sopwith@cuc.edu Thu May 11 19:23:54 2000
Received: (qmail 18895 invoked from network); 4 Jan 1998 04:05:28 -0000
Received: from helix.cs.cuc.edu (HELO cuc.edu) (sopwith@207.222.40.128)
by mail2.redhat.com with SMTP; 4 Jan 1998 04:05:28 -0000
Received: from localhost (sopwith@localhost)
by cuc.edu (8.8.5/8.8.5) with SMTP id XAA21185
for <gtk-list@redhat.com>; Sat, 3 Jan 1998 23:05:18 -0500
Date: Sat, 3 Jan 1998 23:05:17 -0500 (EST)
From: Elliot Lee <sopwith@cuc.edu>
X-Sender: sopwith@helix.cs.cuc.edu
To: gtk-list@redhat.com
Subject: Re: [gtk-list] Re: drag and drop protocol: compatible with gtk?
In-Reply-To: <lz90sxdtum.fsf@cu-dialup-1807.cit.cornell.edu>
Message-ID: <Pine.LNX.3.95.980103230100.16926C-100000@helix.cs.cuc.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On 3 Jan 1998, Owen Taylor wrote:
> What is implemented in GTK is a earlier version of this protocol.
> It won't interoperate right now, but presumably the protocol in GTK
> will be updated to conform.
Not likely, I hope.
> Looking at the web page, it is a definite improvement over what is in
> GTK now
How so? I.e. what's wrong with what is currently in Gtk, what improvements
do you see the JX protocol making, what changes do you think both
protocols need?
> though I'm still not completely satisfied with it. It does a pretty good
> job at being a nice simple, lightweight protocol.
The Gtk protocol does things the way I think they should be done. The JX
protocol has some nice things, but it also has some real shortcomings as I
see it, and I don't think it is wise to support it.
> Personally, I'd like to use this opportunity to reorganize DND in GTK so
> that we can later add Motif DND interoperability without changing the
> the API.
I'm pretty certain that we can put Motif in without changing the API as it
is, but yes, putting the DND stuff into a separate file (and perhaps
changing gdk_event_translate) might be nice.
-- 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)
From owt1@cornell.edu
Received: (qmail 30123 invoked from network); 4 Jan 1998 18:50:28 -0000
Received: from cu-dialup-2003.cit.cornell.edu (qmailr@132.236.155.125)
by mail2.redhat.com with SMTP; 4 Jan 1998 18:50:28 -0000
Received: (qmail 22612 invoked by uid 504); 4 Jan 1998 18:52:34 -0000
To: gtk-list@redhat.com
Subject: Re: [gtk-list] Re: drag and drop protocol: compatible with gtk?
References: <Pine.LNX.3.95.980103230100.16926C-100000@helix.cs.cuc.edu>
From: Owen Taylor <owt1@cornell.edu>
Date: 04 Jan 1998 13:52:33 -0500
In-Reply-To: Elliot Lee's message of Sat, 3 Jan 1998 23:05:17 -0500 (EST)
Message-ID: <lz67o0dqby.fsf@cu-dialup-1807.cit.cornell.edu>
Lines: 60
X-Mailer: Gnus v5.5/Emacs 20.2
X-Emacs: Emacs 20.2, MULE 3.0 (MOMIJINOGA)
MIME-Version: 1.0 (generated by SEMI MIME-Edit 0.98 - =?ISO-8859-4?Q?"D=F2?=
=?ISO-8859-4?Q?h=F2ji"?=)
Content-Type: text/plain; charset=US-ASCII
Elliot Lee <sopwith@cuc.edu> writes:
> On 3 Jan 1998, Owen Taylor wrote:
>
> > What is implemented in GTK is a earlier version of this protocol.
> > It won't interoperate right now, but presumably the protocol in GTK
> > will be updated to conform.
>
> Not likely, I hope.
Great! Just what we need, another incompatible DND protocol.
While I don't think JX compatibility is very important, compatability
with Qt's solution is crucial. (From Arnt Gulbrandsen's response, it
sounds a bit like they might by going with the JX solution)
> > Looking at the web page, it is a definite improvement over what is in
> > GTK now
>
> How so? I.e. what's wrong with what is currently in Gtk, what improvements
> do you see the JX protocol making, what changes do you think both
> protocols need?
I'll prepare a detailed critique of both protocols. Though it would
be a lot easier if there was an actual description of the GTK
protocol. The code leaves a number of unanswered questions, e.g:
When are XdeEnter events sent to the target app? (The code sends
them on every motion event, that doesn't leave the drop zone, but I suspect
that is a bug)
What is the function of the 'sendreply' flag for XdeEnter and XdeRequest?
etc.
> > though I'm still not completely satisfied with it. It does a pretty good
> > job at being a nice simple, lightweight protocol.
>
> The Gtk protocol does things the way I think they should be done. The JX
> protocol has some nice things, but it also has some real shortcomings as I
> see it, and I don't think it is wise to support it.
Perhaps not. But I can't see the point in using a GTK-specific protocol.
> > Personally, I'd like to use this opportunity to reorganize DND in GTK so
> > that we can later add Motif DND interoperability without changing the
> > the API.
>
> I'm pretty certain that we can put Motif in without changing the API as it
> is, but yes, putting the DND stuff into a separate file (and perhaps
> changing gdk_event_translate) might be nice.
A subset of Motif DND could possibly be shoe-horned into the current
API. (The fact that Motif uses selections presents a problem problems
both for data transfers during the drag and after the drop.)
But, I think things could be improved by presenting a more generic
interface to the program.
Regards,
Owen
From sopwith@cuc.edu
Received: (qmail 20999 invoked from network); 4 Jan 1998 20:29:59 -0000
Received: from helix.cs.cuc.edu (HELO cuc.edu) (sopwith@207.222.40.128)
by mail2.redhat.com with SMTP; 4 Jan 1998 20:29:59 -0000
Received: from localhost (sopwith@localhost)
by cuc.edu (8.8.5/8.8.5) with SMTP id PAA00235
for <gtk-list@redhat.com>; Sun, 4 Jan 1998 15:29:54 -0500
Date: Sun, 4 Jan 1998 15:29:54 -0500 (EST)
From: Elliot Lee <sopwith@cuc.edu>
X-Sender: sopwith@helix.cs.cuc.edu
To: gtk-list@redhat.com
Subject: Re: [gtk-list] Re: drag and drop protocol: compatible with gtk?
In-Reply-To: <lz67o0dqby.fsf@cu-dialup-1807.cit.cornell.edu>
Message-ID: <Pine.LNX.3.95.980104151736.31704B-100000@helix.cs.cuc.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On 4 Jan 1998, Owen Taylor wrote:
> Great! Just what we need, another incompatible DND protocol. While I
> don't think JX compatibility is very important, compatability with Qt's
> solution is crucial. (From Arnt Gulbrandsen's response, it sounds a bit
> like they might by going with the JX solution)
The JX post notes that it is implemented in both JX and Qt, although
probably that Qt version is not yet released.
> I'll prepare a detailed critique of both protocols. Though it would
> be a lot easier if there was an actual description of the GTK
> protocol. The code leaves a number of unanswered questions, e.g:
>
> When are XdeEnter events sent to the target app? (The code sends
> them on every motion event, that doesn't leave the drop zone, but I suspect
> that is a bug)
Well, it used to send them on every motion event, but that was a bug(tm)
and it should work fine in the latest gtk.
The XdeEnter event is sent either when the mouse pointer enters a new
window, or when it leaves the drop zone in the present window.
> What is the function of the 'sendreply' flag for XdeEnter and XdeRequest?
To theoretically allow use of the protocol for a clipboard protocol...
I.e. in a clipboard protocol you'd send an XdeRequest with "sendreply" set
to 1, whereas in the D&D protocol you send XdeEnter with "sendreply" set
to 1. It's not used in the current protocol version, though.
> > The Gtk protocol does things the way I think they should be done. The JX
> > protocol has some nice things, but it also has some real shortcomings as I
> > see it, and I don't think it is wise to support it.
>
> Perhaps not. But I can't see the point in using a GTK-specific protocol.
Yes, compatability is important, but we either use a protocol that fits
our needs and does it "right", or we go chasing after the mythical god of
compatibility. People have already tried that strategy by emulating
Microsoft instead of creating the best possible solution. They've failed.
> A subset of Motif DND could possibly be shoe-horned into the current
> API. (The fact that Motif uses selections presents a problem problems
> both for data transfers during the drag and after the drop.)
> But, I think things could be improved by presenting a more generic
> interface to the program.
Sounds cool, looking forward to it,
-- 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)
From atai@ece.ucsd.edu Thu May 11 19:23:54 2000
Received: (qmail 11394 invoked from network); 4 Jan 1998 22:40:47 -0000
Received: from mailbox1.ucsd.edu (132.239.1.53)
by mail2.redhat.com with SMTP; 4 Jan 1998 22:40:47 -0000
Received: from vision.ucsd.edu (vision.ucsd.edu [132.239.223.49])
by mailbox1.ucsd.edu (8.8.5/8.6.9) with ESMTP id OAA13541 for
<gtk-list@redhat.com>; Sun, 4 Jan 1998 14:40:39 -0800 (PST)
Received: (from atai@localhost)
by vision.ucsd.edu (8.8.5/SOEGW-PSEUDO-4.2-SunOS-8.6.x)
id OAA08516; Sun, 4 Jan 1998 14:40:37 -0800 (PST)
for gtk-list@redhat.com
From: atai@ece.ucsd.edu (Andy Tai)
Message-Id: <199801042240.OAA08516@vision.ucsd.edu>
Subject: Re: [gtk-list] Re: drag and drop protocol: compatible with gtk?
To: gtk-list@redhat.com
Date: Sun, 4 Jan 1998 14:40:37 -0800 (PST)
In-Reply-To: <Pine.LNX.3.95.980103230100.16926C-100000@helix.cs.cuc.edu>
from "Elliot Lee" at Jan 3, 98 11:05:17 pm
X-Mailer: ELM [version 2.4 PL23]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
>
> On 3 Jan 1998, Owen Taylor wrote:
>
>
> > What is implemented in GTK is a earlier version of this protocol.
> > It won't interoperate right now, but presumably the protocol in GTK
> > will be updated to conform.
>
> Not likely, I hope.
>
> > Looking at the web page, it is a definite improvement over what is in
> > GTK now
>
> How so? I.e. what's wrong with what is currently in Gtk, what improvements
> do you see the JX protocol making, what changes do you think both
> protocols need?
>
>
I am kind of surprised by Elliot's remarks. As Arnt, the author of Qt, already
mentioned, DND is mainly for interoperability. Betterness or worseness of the
protocol itself should be secondary.
If the author of the current gtk DND protocol insists on not changing it for
compatibility, would it be possible for gtk to recognize multiple DND protocols?
Maybe another DND can be added for interoperability with Qt (thus KDE), and JX,
and another for Motif, etc.
Hope Elliot won't mind the incorporation of Qt/JX DND into gtk, if someone
implements it.
> -- Elliot http://www.redhat.com/
--
Li-Cheng Tai (Andy Tai) e-mail: atai@ece.ucsd.edu
Free software: the software by the people, of the people and for the people,
worldwide. Develop! Share! Enhance! And enjoy!
From owt1@cornell.edu
Received: (qmail 5746 invoked from network); 14 Jan 1998 02:32:54 -0000
Received: from cu-dialup-0804.cit.cornell.edu (qmailr@132.236.155.50)
by mail2.redhat.com with SMTP; 14 Jan 1998 02:32:54 -0000
Received: (qmail 1419 invoked by uid 504); 14 Jan 1998 02:35:14 -0000
To: Elliot Lee <sopwith@cuc.edu>
Cc: gtk-list@redhat.com, gnome-hackers@nuclecu.unam.mx
Subject: Re: Gtk Drag & Drop changes
References: <Pine.LNX.3.95.980113144612.8152D-100000@helix.cs.cuc.edu>
From: Owen Taylor <owt1@cornell.edu>
Date: 13 Jan 1998 21:35:13 -0500
In-Reply-To: Elliot Lee's message of Tue, 13 Jan 1998 15:38:09 -0500 (EST)
Message-ID: <lzu3b7hjfi.fsf@cu-dialup-0804.cit.cornell.edu>
Lines: 245
X-Mailer: Gnus v5.5/Emacs 20.2
X-Emacs: Emacs 20.2, MULE 3.0 (MOMIJINOGA)
MIME-Version: 1.0 (generated by SEMI MIME-Edit 0.98 - =?ISO-8859-4?Q?"D=F2?=
=?ISO-8859-4?Q?h=F2ji"?=)
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
[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.htm=
l
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.
=3D=3D=3D=3D=3D=3D=3D=3D=3D
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 =3D atom for drag type (!)
Property type =3D 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=3Dcancel, 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.
=3D=3D=3D=3D=3D=3D
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
From sopwith@cuc.edu
Received: (qmail 16723 invoked from network); 14 Jan 1998 03:21:42 -0000
Received: from helix.cs.cuc.edu (HELO cuc.edu) (sopwith@207.222.40.128)
by mail2.redhat.com with SMTP; 14 Jan 1998 03:21:42 -0000
Received: from localhost (sopwith@localhost)
by cuc.edu (8.8.5/8.8.5) with SMTP id WAA02228;
Tue, 13 Jan 1998 22:21:40 -0500
Date: Tue, 13 Jan 1998 22:21:40 -0500 (EST)
From: Elliot Lee <sopwith@cuc.edu>
X-Sender: sopwith@helix.cs.cuc.edu
To: Owen Taylor <owt1@cornell.edu>
cc: gtk-list@redhat.com
Subject: Re: Gtk Drag & Drop changes
In-Reply-To: <lzu3b7hjfi.fsf@cu-dialup-0804.cit.cornell.edu>
Message-ID: <Pine.LNX.3.95.980113214528.31213C-100000@helix.cs.cuc.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
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)
From otaylor@cu-dialup-1801.cit.cornell.edu
Received: (qmail 1613 invoked from network); 14 Jan 1998 05:18:48 -0000
Received: from cu-dialup-1801.cit.cornell.edu (qmailr@132.236.236.85)
by mail2.redhat.com with SMTP; 14 Jan 1998 05:18:48 -0000
Received: (qmail 4562 invoked from smtpd); 14 Jan 1998 05:21:08 -0000
Received: from localhost (HELO cu-dialup-1801.cit.cornell.edu) (otaylor@127.0.0.1)
by localhost with SMTP; 14 Jan 1998 05:21:08 -0000
From: Owen Taylor <owt1@cornell.edu>
To: Elliot Lee <sopwith@cuc.edu>
cc: gtk-list@redhat.com
Subject: Re: Gtk Drag & Drop changes
In-reply-to: Your message of "Tue, 13 Jan 1998 22:21:40 EST."
<Pine.LNX.3.95.980113214528.31213C-100000@helix.cs.cuc.edu>
Date: Wed, 14 Jan 1998 00:21:00 -0500
Sender: otaylor@cu-dialup-1801.cit.cornell.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.
ftp://ftp.red-bean.com/pub/teak/, if anybody is interested. (It is
in the Motif FAQ). But "sketchy overview" was more my opinion than
"good one" when I looked at it. The Lesstif chapter is _much_ better.
> > 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.
That would work.
> > * 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.
Nope. There are multiple selections. A normal X Button-2 "paste"
is a request for the PRIMARY selection. A real paste is a request
for the CLIPBOARD selection. A drop would be a request for
a different selection. (Xdnd uses XdndSelection). (Selections
are identified by atoms).
> > 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.
> > 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...
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).
> > * 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.
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.)
> 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...
Yes. There is some rudimentary support in there now. For example
gdk_atom_name is implemented as:
gdk_error_warnings = 0;
t = XGetAtomName (gdk_display, atom);
gdk_error_warnings = 1;
if (gdk_error_code == -1)
{
return NULL;
}
else
{
...
}
There are a lot of places in GDK where this (or something better)
should be used, but isn't.
> > 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.
It's not a big deal as long as the applications are robust. If
they aren't then explicit confirmation makes things easier
on the user. But I think the scenario above and variants are
a more compelling reason.
> > * 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.
If we do this, then we probably should change the selection interface
as well so that target names are always specified as mime types.
(Caching the atoms while we're at it would also be nice)
> > * 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.
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.)
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.
Motif actually implements changing the drag icon to indicate to
the user what operation is going to take place.
> > * 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.
Probably - I tried to be complete in this list, rather than listing
exactly what I thought should be put in or not.
> > * 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
???
Not sure what you meant to say. But it isn't worth worrying about too
much, probably. The rest of GTK is pretty casual about time
anyways. (Problem is that once mouse events are translated into
i.e., button events, the timestamp is gone).
> > - 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).
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.
> > - 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).
Sort of. The code I mentioned a while ago is still broken:
/* Handle all that dropzone stuff - thanks John ;-) */
if(dnd_drag_target != None
&& IS_IN_ZONE(dnd_drag_oldpos.x, dnd_drag_oldpos.y)
&& !IS_IN_ZONE(xevent->xmotion.x_root,
xevent->xmotion.y_root))
{
/* We were in the drop zone and moved out */
dnd_drag_target = None;
gdk_dnd_drag_leave(curwin);
}
else
{
/* We were outside drop zone but in the window
- have to send enter events */
gdk_dnd_drag_enter(curwin);
dnd_drag_curwin = curwin;
dnd_drag_dropzone.x = dnd_drag_dropzone.y = 0;
dnd_drag_target = None;
}
This breaks in the case where we go from IN_ZONE to IN_ZONE. If
you are done working on DND for now. I suppose I could try
to fix this, the LeaveNotify and anything else I find. But I'll
just be guessing as to your intentions for the protocol.
> > - 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.
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).
> > - 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.
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.
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.)
> > - 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()
It might be nice to have a better default cursor as well...
Regards,
Owen
From sopwith@cuc.edu
Received: (qmail 23083 invoked from network); 14 Jan 1998 06:27:17 -0000
Received: from helix.cs.cuc.edu (HELO cuc.edu) (sopwith@207.222.40.128)
by mail2.redhat.com with SMTP; 14 Jan 1998 06:27:17 -0000
Received: from localhost (sopwith@localhost)
by cuc.edu (8.8.5/8.8.5) with SMTP id BAA11836;
Wed, 14 Jan 1998 01:27:15 -0500
Date: Wed, 14 Jan 1998 01:27:14 -0500 (EST)
From: Elliot Lee <sopwith@cuc.edu>
X-Sender: sopwith@helix.cs.cuc.edu
To: Owen Taylor <owt1@cornell.edu>
cc: gtk-list@redhat.com
Subject: Re: Gtk Drag & Drop changes
In-Reply-To: <199801140518.AAA08021@cuc.edu>
Message-ID: <Pine.LNX.3.95.980114011758.11279A-100000@helix.cs.cuc.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
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)