> 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?

> Could we maybe decide whether the field xor its content should be dragged depending on whether shift/control is pressed?

Expecting the user the press a modifier *before* the drag is initiated seems strange. Modifiers should be accepted during the drag operation before the drop. For implementing such "unpacking" while it is dragged, one could add an unpacking block or message send to the TransferMorph.

> 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. Hmm... the environment is full of different applications. There is also this #dragTransferType, which encourages handling in the drop target. I don't think that's a good idea. A model should be able to specify the specialization of TransferMorph, too. Not just configure it. See PluggableListMorph >> #startDrag: for the current state of affairs. :-)

Best,
Marcel
Am 10.05.2020 21:36:51 schrieb Jakob Reschke <forums.jakob at resfarm.de>:
A modifier would be ok-ish for me. Would the default (without
modifier) be dragging the object or dragging the field? I'd say
dragging the field is a meta operation and should therefore require
the modifier, what do you think?

A nice solution would be if Morphic drag and drop learned that
multiple things can be dragged with a single movement - like Windows
drag and drop and probably all the other OS drag and drops can (for
example, plain text + formatted rich text + . Then one could drag both
the field and the value. Then as a drop receiver, I would still need
to dispatch what is being dragged and pick the right object, but I
would not have to know all kinds of wrappers that could appear in the
System and how to unpack them.

Strictly speaking, nobody forces me to accept the latest and greatest
invention of the IDE and instead I could insist on a drag from my own
set of tools for the domain. But developer convenience... :-D

Am So., 10. Mai 2020 um 13:26 Uhr schrieb Thiede, Christoph
:
>
> Hm, interesting observation. Could we maybe decide whether the field xor its content should be dragged depending on whether shift/control is pressed? Similar to the existing "shift to copy" mechanism when dragging methods.* What do you think? :-)
>
>
> (*Just that this mechanism is a bit buggy at the moment if you first drag something, secondly press shift and thirdly drop the object again. But that may be another story ...)
>
> Best,
> Christoph
> ________________________________
> Von: Squeak-dev im Auftrag von Jakob Reschke
> Gesendet: Samstag, 9. Mai 2020 12:27:52
> An: The general-purpose Squeak developers list
> Betreff: Re: [squeak-dev] Please try out | Inspector Refactoring =)
>
> The improvements work well, thank you. :-)
>
> I noticed a slight nuisance: you cannot drag an item from the
> Inspector to another morph to drag the actual object (the value).
> Instead, the field gets dragged. My current workaround is to explore
> the field and then drag the object from the explorer. Is there a nice
> way to improve on this without "unpacking" fields at every target
> location?
>
> Am Mo., 27. Apr. 2020 um 23:29 Uhr schrieb David T. Lewis :
> >
> > On Mon, Apr 27, 2020 at 10:35:11AM +0200, Marcel Taeumel wrote:
> > > Hi all!
> > >
> > > I just merged the inspector refactoring to Trunk. I'll stay tuned for issues. ;-)
> > >
> > > Note that existing inspectors get re-opened during the update but debuggers will not. So existing debuggers will experience complaining inspectors. Please forgive this inconvenience. Try to re-start the debugging session.
> > >
> > > Best,
> > > Marcel
> > > Am 26.04.2020 20:01:08 schrieb Thiede, Christoph :
> > > Yes, this sounds good :-)
> >
> > Thank you Christoph and Marcel!
> >
> > Dave
> >
> >
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200511/6cf2f47a/attachment.html>