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

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

"Kip Rugger" <kr@nodomain.net> wrote in message
news:e0p3ue$bb$1@darkstar.ca...
> Georgios Petasis <petasis@iit.demokritos.gr> wrote:
> [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.
>
Received on Sun Apr 30 02:56:29 2006