So as promised in another thread, here is my DnD Inspector:
Now don’t get too excited, it does what it says on the tin but I couldn’t spend a whole lot of time polishing it. The resizing is particularly terrible, on account of me spending a bit of time with the layout system, but just enough to get frustrated by it and give up. That said you really shouldn’t need to resize the windows too much.
It’s got two tabs, one for acting as a drag source with some contrived data, and another for receiving drops.The idea is, it’s an easy(er) way to test your app’s DnD functionality than having to write both sides of the equation yourself, or trying to muddle along testing against other apps which handle DnD in a fixed way.
(Note some test data is required, which I’m currently hosting on DropBox because it was too big for git – see the github repository for the link)
Anyhow, I want to bring up some stuff that I encounted that may be of interest / require clarification from the Haiku devs:
I noticed that ShowImage on BeOS R5 spews out a strangely-structured message relative to what’s in the BeBook spec (or even the original article accompanying the DragMe demo). In short, instead of the “be:types” field containing just the MIME types for non-file drops, with an optional B_FILE_MIME_TYPE at the end, it’s repeatedly interleaving the expected be:types with B_FILE_MIME_TYPE (partial screenshot here).
One’s initial thought might be “well maybe that’s how they indicated a particular format could also be dropped as a file?” - but that doesn’t jive because the “be:filetypes” is also present, with the expected structure.
I only mention this because Haiku R1 is supposed to be compatible with BeOS (right?), but in this case the way BeOS’s ShowImage does it seems bizarre - so I’m glad Haiku is adhering to the BeBook spec, which is also how I wrote my app.
on that note, the DragMe demo doesn’t really work in Haiku currently. The issue seems to be something with how it’s using TranslationKit, though I didn’t have time to go any deeper. The short version is, it never really writes any data (either via message or to the target file), despite seeming to do things correctly up to that point. Not a big issue since I had other apps to play with, but again, I’m only pointing it out because of potential compatibility issues with respect to TranslationKit / DnD in older Be apps / etc.
with the spec as it stands, there is apparently no feedback after a file gets written. A drags to B, B requests a file in some format, A writes to file, B never hears back after that. The BeBook spec has a parenthetical comment expressing some confusion on that point, and suggests maybe using a node monitor to watch for the file. Is that the official stance as well – use a node monitor? (If so, I should probably update my app to provide some feedback that way – currently it doesn’t do anything to confirm a file was written)
should a B_LINK_TARGET drop have any intrinsic meaning? I will need to spend some time going back over the documentation for other platforms, but IIRC that drop action usually doesn’t have any meaning between apps written by different people.
As of now my app just mentions (via printf) that the recipient chose to link, and doesn’t attempt to send the final payload after that. So it really just supports COPY, MOVE and TRASH. If somebody has a better idea how to handle that drop action, let me know!
That does not look very clean, maybe we should extend the protocol? Can that be done in a backwards-compatible way?
In Tracker it creates symbolic links instead of copying or moving files. I think that’s the main reason it was introduced, but let’s see if it can make sense in other contexts:
I could imagine that if you drag a picture into a word processor, it could either be copied (and bundled into the document) or linked (so that any update to the picture reflects in the document immediately). NeXT has a demo of something like that in their demo video ran by Steve Jobs, IIRC. Not that such things were already done in BeOS or Haiku, but it sounds like a possible interpretation.
Likewise, dragging a file to Terminal just inputs its path in the console. This could be considered a “link” (and any case where only the path to the file, not the contents itself, is used, would be similar).
Asuming the target of creating such a document is to send it to other people and not storing for yourself, that option is kinda… weird. Unless you later “print” to pdf and share that pdf itself.
Guess that the target application in this case should/may ask you what to do.
Yes, which is why it should clearly be a different drag protocol action and not the default behavior.
But it can make sense to automate document generation. For example you have a graph generated from a spreadsheet and you want your nice report document to include it automatically. This goes way further than just the drag and drop protocol however.
Good question. If a “file written” confirmation message were added, then new apps would be expecting it but older apps would never provide it…
I suppose one solution might be a DnD version/capabilities field. Lack of a be:dnd-version field would imply: original Be spec / 1.0, whereas an explicit version 1.1 could mean the presence of file write confirmations. Something like that?
… but then apps would still be responsible for handling the old scenario with no confirmation, so is that really an improvement over node monitoring? Dunno.
It’s not an immediate improvement, but after most apps are adjusted we can drop support for the old protocol. And it covers the case where the target is not actually a file, too. I can imagine a dropbox/google dirve/… client that would work like that, for example.
