For the records, I have understood why this doesn’t and potentially can’t work.
It has nothing to do with any mutex or transaction, by the way.
When a file is dropped in-app, i.e. from one window to another (this also applies to the Desktop), the Tracker looks for the current selection in the source window and if the selection is empty it returns doing nothing.
Worse still it does not even check if the selection matches with the refs and just picks up the selected file from the source window ignoring the actual refs in the message.
This can be easily witnessed by manually changing the selection in the Tracker’s source window before dragging the “file” from DropIt! from fileA to fileB for example. You will end up with an unintended file being moved.
I am not sure if this could be considered a bug, in the end DropIt! wants to implement a quite uncommon and extreme use case. Nevertheless, I may be able to work this around by preprocessing the message and turning it into a “foreign drag” in Tracker’s term but looks a bit tricky.
All the more reason to get Haiku devs’ advice here.
EDIT: I may have changed my mind and would actually consider this as a design flaw. This unintended behaviour can be triggered at any time even without DropIt! in the middle.
It’s easy to reproduce it. Take two Tracker windows side by side pointing to folderA and folderB, respectively.
While dragging whatever element from windowA to windowB, close the former with the shortcut CMD-W. Now that it’s gone, keep dragging and drop the file onto the destination window and the Tracker will… do nothing.
EDIT2: Another scenario is as follows. If the selection is changed “in-flight” with the arrow keys the new currently selected element is moved to the destination. Bummer!
It looks like something that could be improved in Tracker.
Even if DropIt! tries to do things that were not possible before, one nice thing about Haiku is that, being developed by a single team, interface changes like this can be done more easily than in a composite system. On Linux you would have to maybe change some FreeDesktop spec, and then get it implemented in every file management app. In Haiku, you don’t have that type of problem.
I don’t know Tracker and its drag messages well enough to say if there’s a reason it was implemented this way, and if the reason still applies. Maybe changing how Tracker behaves will cause subtle breakage elsewhere. But we can surely find a protocol that makes everyone happy?
However, if this is done with two different applications the first problem still remains. You can’t drag from an application that is closed. Perhaps we need to add a new “drag canceled” state for this.
Hmm, It would be much better if those items dissapeared with the closing of the app that initiated the drag. Unless you in such a case take over the items and keep them. (would also be an option)
But I’m going to read the source of DropIt and how tracker does it now to give you a more comprehensive answer
It depends, if the Drag message is part of a negotiated drag and drop maybe, but I would avoid having the items disappear even with a warning.
The recipient should be responsible of checking this situation regardless of DropIt.
Even more so that the Negotiation and Data messages do not go through DropIt!, they will be regularly exchanged between the two applications.
If it’s not negotiated, for example a colour being dropped, it does not matter if the sender quits in the meantime.
