Re: [ANN]: TkDND 2.0 alpha...

Georgios Petasis wrote:
> 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.
Received on Sun Apr 30 02:57:55 2006