> There are cases where the target actually supports multiple formats/types and lets the user choose. Like the paste as plain text vs rich text example.

I think that I have lazy (or deferred) evaluation in mind. The drag source puts a passenger into the transfer morph and adds some rules on how to convert that passenger into other objects. The drop target then chooses the kind of representation, triggering conversion transparently. Yes, MIME types can serve as a common protocol between source and target. Hmm...on second thought ... it does not matter whether this conversion is deferred or not.

The inspector would store its field behind a special MIME type like "application/inspector-field" as well as "object/generic" (?) and maybe even "text/plain". The last option would free the target from having to decide whether to call #asString or #printString on "object/generic". :-)
Am 11.05.2020 14:08:00 schrieb Jakob Reschke <forums.jakob at resfarm.de>:
Marcel Taeumel <marcel.taeumel at hpi.de [mailto:marcel.taeumel at hpi.de]> schrieb am Mo., 11. Mai 2020, 08:41:

> A nice solution would be if Morphic drag and drop learned that multiple things can be dragged with a single movement

Seems related to the clipboard and maybe MIME type support?

Exactly. IIRC under Windows that is actually the same mechanism about the different content types.


> Similar to the existing "shift to copy" mechanism when dragging methods.

I don't think such things should be implemented in the drop target (morph or model). The TransferMorph should transparently provide the object-to-drop depending on some modifiers.

There are cases where the target actually supports multiple formats/types and lets the user choose. Like the paste as plain text vs rich text example.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200511/fee34ced/attachment.html>