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

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