[ANN]: TkDND 2.0 alpha...
Georgios Petasis
to a scheduled power shortage), I am posting some details about the
forthcoming release of the TkDND version 2.0 series.
1) TkDND v 2.0 wil lbe incompatible with 1.x versions. Perhaps
a compatibility layer will be added to support the most common
use cases of the 1.x series.
2) TkDND won't support user-defined drag and drop format, as
1.x supported. I think that this was a feature never used by somebody.
3) The current implementation, support only drops from other applications
to Tk windows. Of course, full drag support is planned.
4) Motif drag and drop handling won't be supported.
Now, what the new API look like:
Drop target widgets:
--------------------------------
A drop target widget can be defined as:
tkdnd::drop_target register .drop_target <type-list>
<type-list> can contain cross-platform types, like "DND_Text" and
"DND_Files",
or platform-dependent types like CF_HDROP or text/files.
A new feature is that types can also have wildcards, like in "string match".
For example, the type "*" will accept all types!
Since a widget is registered as a drop target, 4 events can be delivered
to the widget during drop operations: <<DropEnter>>,
<<DropPosition>>, <<DropLeave>> and <<Drop(:*)?>>.
You can register a widget to receive these events, by using bind:
set cmd {handle_event %E %W %X %Y %ST %TT %A %a %CST %CTT %T %t %B %D}
bind .drop_target <<DropEnter>> $cmd
bind .drop_target <<DropPosition>> $cmd
bind .drop_target <<DropLeave>> $cmd
The <<Drop>> event, can be more complex: a widget can register a generic
<<Drop>> event that will be called when any drop event occurs. But it can
also register a more "specific" drop event, associated with a type:
bind .drop_target <<Drop>> $cmd
bind .drop_target <<Drop:DND_Files>> $cmd
In such a case, if a file is dropped on the widget, the event
<<Drop:DND_Files>> will be called. For all other drops
(like texts), the "generic" <<Drop>> will be called.
All event bindings, if defined, are expected to return the drop
action (one of copy, move, link, ask, private & refuse_drop).
Also, bindings can have various pieces of information, like
Event (%E) Widget (%W) X (%X) Y (%Y) Source_Types (%ST)
Target_Types (%TT) Source_Actions (%A) Action (%a)
Common_Source_Types (%CST)
Common_Target_Types (%CTT)
Types (%T) Drop_Type (%t)
Pressed_Keys/Buttons (%B) and Data (%D)
How does this new interface sounds?
George
(The new version will be available as soon as my server will be up again,
which is expected to happen by tonight.)
Georgios Petasis
series
was added. So, if you don't use %x & %y in your scripts,
and the tkdnd utilities for droping on canvas items, you have a good chance
the old code will work :-)
George
"Georgios Petasis" <pet...@iit.demokritos.gr> wrote in message
news:e0lrrp$2442$1...@ulysses.noc.ntua.gr...
Georgios Petasis
http://www.ellogon.org/petasis/index.php?option=com_docman&task=doc_download&gid=47&Itemid=37
This includes the sources & binaries for linux (fedora core 5) and windows.
George
"Georgios Petasis" <pet...@iit.demokritos.gr> wrote in message
news:e0mdmo$ak7$1...@ulysses.noc.ntua.gr...
Kip Rugger
[snip]
>
>All event bindings, if defined, are expected to return the drop
>action (one of copy, move, link, ask, private & refuse_drop).
>Also, bindings can have various pieces of information, like
>Event (%E) Widget (%W) X (%X) Y (%Y) Source_Types (%ST)
>Target_Types (%TT) Source_Actions (%A) Action (%a)
>Common_Source_Types (%CST)
>Common_Target_Types (%CTT)
>Types (%T) Drop_Type (%t)
>Pressed_Keys/Buttons (%B) and Data (%D)
>
>How does this new interface sounds?
I generally like it :)
I do have some concern with %D, which is apparently the same as in
version 1. It effectively models the data transfer as a single,
atomic operation.
If you think of DnD as a method for transmitting a uri (or anything
else that is, say, about 30 bytes long), then %D is the natural
interface -- no argument there.
But %D can be huge. Consider dragging a word-processing document to a
printer, or the like. Here you really want to handle the operation
with the channel machinery.
In the X world, the data transfer is effected by the Selection
mechanism, and using the INCR mode you can get something that is very
similar to file I/O. The natural implementation here would be to
implement a channel driver (Tcl_CreateChannel) that knows how to
handle selections, and provide DnD options both to use such channels
and to make them explicitly available at the script level. Such a
channel driver should be fairly simple, given that Tcl_CreateChannel
and Tk_GetSelection already exist. And it could be used by itself as
another form of interprocess communication.
This would allow a drop site to respond visually (or otherwise) to a
drop *during* the data transfer, giving valuable visual clues
about its progress. The %D interface only allows such a response
*after* the data has been fully transferred, making it difficult to
depict the operation visually (at the drop site), or to provide a
method to cancel an operation in progress if it is stalled.
Georgios Petasis
1) The uses do not justify the efford put into it. We are talking about
a very complex scheme, where the control of the transfer must be passed
to the caller (outside of tkdnd). This is dangerous, as there are a lot of
things
that can go wrong.
2) When the transfer is over, you have to deliver an event to the
drag source, to notify that you have finished getting the data, or that
you are not interested any more in the drop. How is this to be handled?
You must rely on the user to call a function? In 99% of the cases they
won't.
And I know many cases (like Qt) that will wait forever to receive this
message. If it does not gets received and you start another drag from Qt,
you get a crash of the Qt app. (Actually, Qt uses global variables to store
the various pieces of information, which can crash Qt applications
if you mix drag and drop operations.)
Actually, with tkdnd I aim now to get the most common cases right.
This is why I have dropped image transfer and I haven't yet decided
on user specified types (where the data will be passed as a binary array).
Of course, if there is a patch, I will be happy to incorporate it into
tkdnd.
George
"Kip Rugger" <k...@nodomain.net> wrote in message
news:e0p3ue$bb$1...@darkstar.ca...
vince....@gmail.com
> I expect to be many problems with such an approach:
>
> 1) The uses do not justify the efford put into it. We are talking about
> a very complex scheme, where the control of the transfer must be passed
> to the caller (outside of tkdnd). This is dangerous, as there are a lot of
> things
> that can go wrong.
>
> 2) When the transfer is over, you have to deliver an event to the
> drag source, to notify that you have finished getting the data, or that
> you are not interested any more in the drop. How is this to be handled?
> You must rely on the user to call a function? In 99% of the cases they
> won't.
But isn't this roughly the model that MacOS X uses?: the source
_promises_ some data, and then the drop site has to request it. It is
only at that point that the source actually provides the data. Of
course things can go wrong, and that's what error conditions are for.
("drop cancelled/failed/...", etc).
To me, any API that forces all the data to be provided up front is not
appropriate for a general drag-n-drop mechanism.
Certainly for many common cases it is easy to provide the data up front
(and that should be supported), but equally for many other common cases
it is quite hopeless to provide all the data up front.
Vince.
Georgios Petasis
<vince....@gmail.com> wrote in message
news:1144007842.7...@z34g2000cwc.googlegroups.com...
What are these cases? The only one I know of is under windows, when
dragging files from compressed folders (or from winzip). It would be
interested
to know more cases.
George
Georgios Petasis
the types CF_UNICODETEXT, CF_TEXT & CF_HDROP).
(these types simply mean unicode text & file names).
So, the current implementation of TkDND 2.0 can be used for
drag/drop text &files under windows and for drop text/files
under unix. Still drag support under unix is missing.
And also due to the small compatibility layer, some applications
using TkDND 1.x will also work (tested with TkDND 1.x demos).
The new version (tkdnd2.0alpha2.zip) can be found at:
http://www.ellogon.org/petasis/index.php?option=com_docman&task=doc_download&gid=48&Itemid=37
http://www.ellogon.org/petasis/index.php?option=com_docman&task=cat_view&gid=31&Itemid=37
George
"Georgios Petasis" <pet...@iit.demokritos.gr> wrote in message
news:e0lrrp$2442$1...@ulysses.noc.ntua.gr...
Ramon Ribó
Another case to review would be to drag an email from Outlook. I did
not manage to make it work with current tkdnd.
Ramon Ribó
En Mon, 03 Apr 2006 00:00:55 +0200, Georgios Petasis
<pet...@iit.demokritos.gr> escribió:
--
Compass Ing. y Sistemas Dr. Ramon Ribo
http://www.compassis.com ram...@compassis.com
c/ Tuset, 8 7-2 tel. +34 93 218 19 89
08006 Barcelona, Spain fax. +34 93 396 97 46
Georgios Petasis
outlook express? If you install the latest TkDND 2.0 alpha 2, and
you run the dndSpy.tcl (from the TkDND 1.x demos directory),
then you can drop an e-mail from outlook express to Tk.
I tried it and it worked for me. Outlook express seems to be
using the regular types CF_UNICODETEXT & CF_TEXT (among
others), which are supported by TkDND 2.x.
George
"Ramon Ribó" <ram...@compassis.com> wrote in message
news:op.s7e9e...@akenatonv.www2.compassis.com...
Georgios Petasis
These, are stored in a different format, not recognised by TkDND.
George
"Georgios Petasis" <pet...@iit.demokritos.gr> wrote in message
news:e0qpi2$1a0i$1...@ulysses.noc.ntua.gr...
Ramon Ribó
And will tkdnd V 2 permmit them? At the end, you can leave the decoding
and parsing of the message to the caller of the library.
Ramon Ribó
En Mon, 03 Apr 2006 13:38:52 +0200, Georgios Petasis
vince....@gmail.com
Georgios Petasis wrote:
> <vince....@gmail.com> wrote in message
> > Certainly for many common cases it is easy to provide the data up front
> > (and that should be supported), but equally for many other common cases
> > it is quite hopeless to provide all the data up front.
>
> dragging files from compressed folders (or from winzip). It would be
> interested
> to know more cases.
Here are a few other examples:
With 'tclvfs', one can easily create a listing in Tcl of remote
resources of all sorts of kinds (webdav, contents of zip, ftp, etc).
One wants to be able to drag those out of Tcl into the native
filesystem, and not just on Windows.
With an image browser, one would want to be able to drag a thumbnail of
an image which refers to a multi-megabyte RAW image on disk (which
would be what is actually dropped on success.
With a database browser, again one wants to be able to drag things out
into the filesystem, with the actual database query on happening on
drop success.
etc.
In all of the above cases it would be helpful to see a progress bar as
part of the successful drop, just as you would typically see with a
non-Tk application which implemented the above kinds of operations.
cheers,
Vince.
Georgios Petasis
a directory and tkdnd will store a set of files in the directory. This type
is supported
by outlook express and a set of *.eml files is stored in the directory.
Actually,
TkDND reads the data from the memory in binary format, and stores the files
in the directory you specify, under file names that outlook specifies. What
you get
back is the list of file names saved.
George
"Ramon Ribó" <ram...@compassis.com> wrote in message
news:op.s7frr...@akenatonv.www2.compassis.com...
Georgios Petasis
news:1144076804.6...@v46g2000cwv.googlegroups.com...
>
> Georgios Petasis wrote:
>> <vince....@gmail.com> wrote in message
>> > Certainly for many common cases it is easy to provide the data up front
>> > (and that should be supported), but equally for many other common cases
>> > it is quite hopeless to provide all the data up front.
>>
>> What are these cases? The only one I know of is under windows, when
>> dragging files from compressed folders (or from winzip). It would be
>> interested
>> to know more cases.
>
> Here are a few other examples:
>
> With 'tclvfs', one can easily create a listing in Tcl of remote
> resources of all sorts of kinds (webdav, contents of zip, ftp, etc).
> One wants to be able to drag those out of Tcl into the native
> filesystem, and not just on Windows.
Alternative: Extract the file(s) from the zip (or anywhere alse on Tcl vfs)
into a temporary directory, and pass the file names to the drag action.
The target application will access the files and when everything is done,
you erase them. Actually, this is exactly what happens if you extract
files from a compressed folder under windows.
>
> With an image browser, one would want to be able to drag a thumbnail of
> an image which refers to a multi-megabyte RAW image on disk (which
> would be what is actually dropped on success.
Again I see a file name passing.
>
> With a database browser, again one wants to be able to drag things out
> into the filesystem, with the actual database query on happening on
> drop success.
Perhaps this is the only case that can be of interest. However, in most
cases
somebody that starts a drag operation want's to drop the data somewhere.
I assume a little wait want matter...
>
> etc.
>
> In all of the above cases it would be helpful to see a progress bar as
> part of the successful drop, just as you would typically see with a
> non-Tk application which implemented the above kinds of operations.
>
> cheers,
>
> Vince.
>
While in general I agree that it would be nice to have such an advanced
feature
in tkdnd (which of course is beyond my available time to code it), I don't
think
that there are other applications that can handle such cases. What is the
point
in providing all these, if you cannot drop the data in other apps? For now,
I think
its more realistic to support actions that are most common.
I was examining today the drag/drop of outlook express e-mails. Initially,
I explored the possibility of creating a virtual file to the data, so I
looked
at the memchan extension. The code I had to write was much more larger
than the whole tkdnd. It is very complex to write all these functions
to cover all the possible operations a user can do on a file. And, some are
impossible,
such as the size of the file...
So, I gave up, and I simply wrote in C in binary the contents of the file
onto the disk, and returned the disk filename. It was much more easier to
implement. And finally, the result is the same: you get the e-mails from
tk...
George
Kevin Walzer
under X11 but would like to use it in the Aqua environment.
--
Kevin Walzer
iReveal: File Search Tool
http://www.wordtech-software.com
Kip Rugger
>
>
>I expect to be many problems with such an approach:
>
>1) The uses do not justify the efford put into it. We are talking about
>a very complex scheme, where the control of the transfer must be passed
>to the caller (outside of tkdnd). This is dangerous, as there are a lot of
>things
>that can go wrong.
>
>2) When the transfer is over, you have to deliver an event to the
>drag source, to notify that you have finished getting the data, or that
>you are not interested any more in the drop. How is this to be handled?
>You must rely on the user to call a function? In 99% of the cases they
>won't.
>And I know many cases (like Qt) that will wait forever to receive this
>message. If it does not gets received and you start another drag from Qt,
>you get a crash of the Qt app. (Actually, Qt uses global variables to store
>the various pieces of information, which can crash Qt applications
>if you mix drag and drop operations.)
>
>Actually, with tkdnd I aim now to get the most common cases right.
>This is why I have dropped image transfer and I haven't yet decided
>on user specified types (where the data will be passed as a binary array).
>Of course, if there is a patch, I will be happy to incorporate it into
>tkdnd.
>
>George
>
I'm not sure you understand the subtleties of the protocol.
XdndFinished means the target no longer requires the data. This could be
used to abort a transfer in progress. Or, if XdndFinished does not arrive
after the transfer is complete, the source should time out -- it is an
error that must be handled no matter how the data is transferred.
Once the transfer is initiated (that is XConvertSelection has been done
by the target and the source has received the event) the selection owner
is free to change. This means that you can initiate another data-transfer
operation (with a drag) while a previous one is still in progress.
Thus I can be listening to an MP3 (initiated by a drag to a player),
I can be formatting and printing a document, and I can drag a file to
a different directory -- the drags occur sequentially, but the data
transfers overlap in time.
The argument that something is "too difficult" to implement will mean
different things to different people. Now if a correct implementation
is "too difficult" for you because of experience or time considerations,
that is not a valid reason to provide a poor implementation. There are
plenty of experts in this group who can assist.
If your real problem is that you need an example of a channel interface,
I would recommend the "reflected channel" rchan that at one time was
distributed as part of Critcl. It is short enough to be one of the many
examples -- sorry, I don't have a current link. Basically writing to
the reflected channel causes a read fileevent, that launches a script
to pick up the data. This is simple stuff.
Hope this helps :)
Georgios Petasis
anything for this platform.
George
"Kevin Walzer" <s...@wordtech-software.com> wrote in message
news:4431755D...@wordtech-software.com...
Georgios Petasis
> I'm not sure you understand the subtleties of the protocol.
>
> XdndFinished means the target no longer requires the data. This could be
> used to abort a transfer in progress. Or, if XdndFinished does not arrive
> after the transfer is complete, the source should time out -- it is an
> error that must be handled no matter how the data is transferred.
According to the XDND protocol:
"If the target receives XdndDrop and will accept it, it first uses
XConvertSelection() to retrieve the data using the given time stamp (if it
doesn't already have it cached). (7) It then uses the data in conjunction
with the last action and mouse position that was acknowledged via
XdndStatus. (Over a slow network, this makes the drop location consistent
with the visual feedback given to the user.) Once it is finished, it sends
XdndFinished.
If the target receives XdndDrop and will not accept it, it sends
XdndFinished and then treats it as XdndLeave."
I think it is stated that XdndFinished is sent when the transfer has been
finished.
>
> Once the transfer is initiated (that is XConvertSelection has been done
> by the target and the source has received the event) the selection owner
> is free to change. This means that you can initiate another data-transfer
> operation (with a drag) while a previous one is still in progress.
> Thus I can be listening to an MP3 (initiated by a drag to a player),
> I can be formatting and printing a document, and I can drag a file to
> a different directory -- the drags occur sequentially, but the data
> transfers overlap in time.
Yes, but in reality you didn't drag the actual data. You only dragged
urls - that is file names. Dragging an MP3 file on a player does not hold
the drag action all the time you play the file - in reality that drag was
over way before the file started to play.
Its an interesting experiment to see what I mean: Comment out the section\
that sends the XdndFinished event in tkdnd. Then, choose any kde/qt app
and drop something on tk. So, tkdnd won't send an XdndFinished. Leave it
as long as you want, and try to start another drag from the qt app.
Qt app will crashes 99% of the cases. Qt cannot handle overlaping
drags (which is also evident from the qt code which I have looked).
>
> The argument that something is "too difficult" to implement will mean
> different things to different people. Now if a correct implementation
> is "too difficult" for you because of experience or time considerations,
> that is not a valid reason to provide a poor implementation. There are
> plenty of experts in this group who can assist.
Yes, the time is limited. But appart from this, I also think that there are
no apps that can handle such drag operators. Is there an example under
kde for a drag/drop operation that does not pass a uri and pass the actual
data? (I do not mean text transfers of course.)
>
> If your real problem is that you need an example of a channel interface,
> I would recommend the "reflected channel" rchan that at one time was
> distributed as part of Critcl. It is short enough to be one of the many
> examples -- sorry, I don't have a current link. Basically writing to
> the reflected channel causes a read fileevent, that launches a script
> to pick up the data. This is simple stuff.
>
> Hope this helps :)
I wasn't aware about this. I had looked only memchan :-)
George
vince....@gmail.com
> Alternative: Extract the file(s) from the zip (or anywhere alse on Tcl vfs)
> into a temporary directory, and pass the file names to the drag action.
> The target application will access the files and when everything is done,
> you erase them. Actually, this is exactly what happens if you extract
> files from a compressed folder under windows.
That's not an exact alternative and is not what happens if you drag
files from a compressed folder under windows. In that case, again, the
extraction only happens _after_ the drop is successful, not before. The
alternative you provide is therefore different in that to instigate the
drag, you may need to wait a significant amount of time while those
megabytes (or more) are copied. This is _not_ what the user expects --
the user expects a potential delay when they trigger the drop, not when
they consider the drag, which they may well decide to cancel.
> > With a database browser, again one wants to be able to drag things out
> > into the filesystem, with the actual database query on happening on
> > drop success.
>
> Perhaps this is the only case that can be of interest. However, in most
> cases
> somebody that starts a drag operation want's to drop the data somewhere.
> I assume a little wait want matter...
It won't matter if you want to surprise the user with a non-standard ui
behaviour.
> While in general I agree that it would be nice to have such an advanced
> feature
> in tkdnd (which of course is beyond my available time to code it), I don't
> think
> that there are other applications that can handle such cases. What is the
> point
> in providing all these, if you cannot drop the data in other apps?
But that's exactly how Windows compressed file browsers, Winzip and
other such things work. They promise a file, but only create it when
the drop is successful. So I DO think there are other applications that
can handle such cases -- almost every application on Windows that is
happy to accept a drop from winzip or the compressed-file-browser!
> I think its more realistic to support actions that are most common.
While I agree it is good to make the most common actions first to be
supported, the above examples are hardly rare. I myself don't see
what's so complex about supporting an API in which one end can
"promise" something first (giving just some information about it), and
only provide it later. That's the default API on MacOS X, as I
understand things, and isn't so different to the API you described.
cheers,
Vince.
Georgios Petasis
A small update that adds support for dropping e-mail messages from Outlook
and files from compressed folders under windows. The new version can be
found
at:
http://www.ellogon.org/petasis/index.php?option=com_docman&task=doc_download&gid=49&Itemid=37
http://www.ellogon.org/petasis/index.php?option=com_docman&task=cat_view&gid=31&Itemid=37
Regards,
George
"Georgios Petasis" <pet...@iit.demokritos.gr> wrote in message
news:e0lrrp$2442$1...@ulysses.noc.ntua.gr...
Ramon Ribó
That is nice but, in order to avoid file system access, wouldn't it
be possible to return a list of lists or a dict with the file names and
the contents?
Ramon Ribó
En Mon, 03 Apr 2006 17:49:57 +0200, Georgios Petasis
George Petasis
to drag some e-mails from outlook express. It was a surprise
to see that it was not supported :-)
George