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:24 2006