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

"Kip Rugger" <kr@nodomain.net> wrote in message
news:e0rsbi$ba$1@darkstar.ca...
> I'm not sure you understand the subtleties of the protocol.
>
> XdndFinished means the target no longer requires the data. This could be
> used to abort a transfer in progress. Or, if XdndFinished does not arrive
> after the transfer is complete, the source should time out -- it is an
> error that must be handled no matter how the data is transferred.

According to the XDND protocol:
"If the target receives XdndDrop and will accept it, it first uses
XConvertSelection() to retrieve the data using the given time stamp (if it
doesn't already have it cached). (7) It then uses the data in conjunction
with the last action and mouse position that was acknowledged via
XdndStatus. (Over a slow network, this makes the drop location consistent
with the visual feedback given to the user.) Once it is finished, it sends
XdndFinished.
If the target receives XdndDrop and will not accept it, it sends
XdndFinished and then treats it as XdndLeave."
I think it is stated that XdndFinished is sent when the transfer has been
finished.

>
> Once the transfer is initiated (that is XConvertSelection has been done
> by the target and the source has received the event) the selection owner
> is free to change. This means that you can initiate another data-transfer
> operation (with a drag) while a previous one is still in progress.
> Thus I can be listening to an MP3 (initiated by a drag to a player),
> I can be formatting and printing a document, and I can drag a file to
> a different directory -- the drags occur sequentially, but the data
> transfers overlap in time.

Yes, but in reality you didn't drag the actual data. You only dragged
urls - that is file names. Dragging an MP3 file on a player does not hold
the drag action all the time you play the file - in reality that drag was
over way before the file started to play.

Its an interesting experiment to see what I mean: Comment out the section\
that sends the XdndFinished event in tkdnd. Then, choose any kde/qt app
and drop something on tk. So, tkdnd won't send an XdndFinished. Leave it
as long as you want, and try to start another drag from the qt app.
Qt app will crashes 99% of the cases. Qt cannot handle overlaping
drags (which is also evident from the qt code which I have looked).

>
> The argument that something is "too difficult" to implement will mean
> different things to different people. Now if a correct implementation
> is "too difficult" for you because of experience or time considerations,
> that is not a valid reason to provide a poor implementation. There are
> plenty of experts in this group who can assist.

Yes, the time is limited. But appart from this, I also think that there are
no apps that can handle such drag operators. Is there an example under
kde for a drag/drop operation that does not pass a uri and pass the actual
data? (I do not mean text transfers of course.)

>
> If your real problem is that you need an example of a channel interface,
> I would recommend the "reflected channel" rchan that at one time was
> distributed as part of Critcl. It is short enough to be one of the many
> examples -- sorry, I don't have a current link. Basically writing to
> the reflected channel causes a read fileevent, that launches a script
> to pick up the data. This is simple stuff.
>
> Hope this helps :)

I wasn't aware about this. I had looked only memchan :-)

George
Received on Sun Apr 30 02:57:54 2006