I’m writing an app that needs to both be a source of, and target for, drag and drop operations. I have the “simple” (single BMessage) mode working, but I need to be able to test negotiated DnD as well. So far the only app I’ve found that does it, is an old BeOS (R4!) DnD demo, located here
Does anybody know offhand any other apps that have implemented negotiated (multi-BMessage) DnD? Probably the more complex the data, the better, because I want to make sure I handle it robustly (such as giving the user an option of using different formats, etc)
Yes, I’ve looked at both of those already. Thank you nonetheless. And I checked out the 3DMov app source, but unless I’m missing something, it looks like it only supports simple, non-negotiated DnD (no two-way communication between the drop target / drag source).
re: the point of it - like any protocol, it takes two to tango. It’s hard to know if you’re doing one half of a two-way communication without a known-correct “other side” to check things against. (imagine writing an IRC client with no servers to test against - obviously the DnD protocol is far simpler than that, but the idea is the same).
Now if I were only worried about DnD within my own app, you’d be right, the implementation would be entirely up to me. But the protocol is meant for two different apps which don’t have any special knowledge of each other, negotiating to transfer data in a common format.
Since I see a need for it, I think I’m going to write a little DnD conformance test application. That way anybody who wants to use the fancier DnD protocol will have something to test against. Perhaps that will encourage wider adoption someday.
But that’s the whole point of negotiated DnD right? … two applications that you have control over, that you wrote, negotiating a DnD… they won’t necessarily even work with other apps that support negotiated DnD since you have no garantee the target app can handle what you are DnDing. You don’t even need to negotiate a DnD for other simple cases.
Also there’s nothing “improper” about simple DnD… it just sets up the use case that 90% of applicaitons will use. I’d also say there isn’t a “proper” way to use negotiated DnD, just write your two applications to do as it says in the BeBook and it should work… otherwise bug report.
Probably the reason there is no demo, is it would be relatively complex to exercise the whole negotiated DnD API… so it would end up being a complex application instead of a straightforward demo.
But that’s exactly what I DON’T have. I am creating just one app, and I want it to work seamlessly with future apps, written by other people, that I will forever remain blissfully unaware of. That’s the whole point of the protocol, or any protocol: it’s a structured way for 2 parties to communicate precisely so that they don’t have to write their respective apps with any knowledge of each other.
I mean no offense, but it seems perhaps you don’t really grasp the purpose of negotiated DnD. The information is out there if you really want to know, or perhaps I can try to explain it another time. All the other window systems (Win32, Cocoa, X11/Motif/GTK, etc) support some variation of it, and it’s actually the “simple” (single, one-way message with no feedback) that’s the odd-man-out in the world of windowing system DnD.
Anyway, my original question stands if anybody knows of specific apps supporting it. I discovered that ShowImage supports acting as a negotiated DnD source (once you select part of an image), though it lacks the drag-to-trash erasing functionality of the original BeOS version.
I thought I implemented negotiated DnD in Scintilla, but now looking at it, in reality it is some kind of Frankenstein of simple and negotiated. I do intend to implement it though, so if your app will support text/plain data you would be able to test against it.
I’ve started a quick and dirty drag source/drop validator, should be ready in a few days. Will toss it on GitHub for whoever wants to maintain it after that
Could you please log a bug for that? What does the BeOS ShowImage do with the selection, erase that part of the image with transparency? I would never have even thought to try that. It might be tricky to get working though.
We had support for a lot more stuff in ShowImage (drag and dropping parts of the image for very crude editing), but we converted it into a true viewer and removed all of this. We need a dedicated paint-like simple editor.
However I see Microsoft is still fialing at UI design. In Windows 7, they “improved” Paint by adding more features to it, vector like drawing, etc. No one likes that, so they made a separate Capture tool with very simple editing support. And in Windows 10 they now supercharged the Capture tool so it is pretty much on-par features with the old Paint…
But I agree with PulkoMandy, it’s a silly feature in an image viewer, and pretty gimmicky even in a dedicated image editor. I only discovered it because I wanted to see how fully implemented DnD was in the BeOS applications.
And as jjpx suggested, here are some built-in Haiku apps which turned up DnD functionality by searching the source code:
debugger - source view
mail - content view (attachment, URL, mailto)
people - picture view (to/from)
resedit (bitmap view)
showimage - selected area
soundrecorder
I’m halfway done with the inspector app, today/tomorrow will be working on the ‘drop’ tab. Here’s the ‘source’ tab in action: https://webmshare.com/play/5oQ5K .
Question relevant to this inspector app I’m working on: what determines where a given BMessage is routed?
I ask because the final B_MIME_DATA reply I’m receiving, doesn’t go where I’d expect - it’s being routed to my BApplication, instead of the window/thread that sent the message it’s replying to. Is there something about that type of message that can only be sent to an app, and never a window?
It’s not a problem per se, I can route it where I ultimately need it. Mainly I just want to verify that I’m not doing something wrong to cause that.
