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

<vince.darley@gmail.com> wrote in message
news:1144007842.714153.138480@z34g2000cwc.googlegroups.com...
> 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.
>

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
Received on Sun Apr 30 02:56:31 2006