<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000">
> <span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">A nice solution would be if Morphic drag and drop learned that </span><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">multiple things can be dragged with a single movement</span><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Seems related to the clipboard and maybe MIME type support?</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">> </span><span style="font-family: Calibri, Helvetica, sans-serif;font-size: 16px">Could we maybe decide whether the field xor its content should be dragged depending on whether shift/control is pressed?</span></div><div><span style="font-family: Calibri, Helvetica, sans-serif;font-size: 16px"><br></span></div><div><span style="font-family: Calibri, Helvetica, sans-serif;font-size: 16px">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.</span></div><div><span style="font-family: Calibri, Helvetica, sans-serif;font-size: 16px"><br></span></div><div><span style="font-family: Calibri, Helvetica, sans-serif;font-size: 16px">> </span><span style="font-family: Calibri, Helvetica, sans-serif;font-size: 16px">Similar to the existing "shift to copy" mechanism when dragging methods.</span></div><div><span style="font-family: Calibri, Helvetica, sans-serif;font-size: 16px"><br></span></div><div><span style="font-family: Calibri, Helvetica, sans-serif;font-size: 16px">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. :-)</span></div><div><span style="font-family: Calibri, Helvetica, sans-serif;font-size: 16px"><br></span></div><div><span style="font-family: Calibri, Helvetica, sans-serif;font-size: 16px">Best,</span></div><div><span style="font-family: Calibri, Helvetica, sans-serif;font-size: 16px">Marcel</span></div><div class="mb_sig"></div>
<blockquote class="history_container" type="cite" style="border-left-style: solid;border-width: 1px;margin-top: 20px;margin-left: 0px;padding-left: 10px;min-width: 500px">
<p style="color: #AAAAAA; margin-top: 10px;">Am 10.05.2020 21:36:51 schrieb Jakob Reschke <forums.jakob@resfarm.de>:</p><div style="font-family:Arial,Helvetica,sans-serif">A modifier would be ok-ish for me. Would the default (without<br>modifier) be dragging the object or dragging the field? I'd say<br>dragging the field is a meta operation and should therefore require<br>the modifier, what do you think?<br><br>A nice solution would be if Morphic drag and drop learned that<br>multiple things can be dragged with a single movement - like Windows<br>drag and drop and probably all the other OS drag and drops can (for<br>example, plain text + formatted rich text + . Then one could drag both<br>the field and the value. Then as a drop receiver, I would still need<br>to dispatch what is being dragged and pick the right object, but I<br>would not have to know all kinds of wrappers that could appear in the<br>System and how to unpack them.<br><br>Strictly speaking, nobody forces me to accept the latest and greatest<br>invention of the IDE and instead I could insist on a drag from my own<br>set of tools for the domain. But developer convenience... :-D<br><br>Am So., 10. Mai 2020 um 13:26 Uhr schrieb Thiede, Christoph<br><christoph.thiede@student.hpi.uni-potsdam.de>:<br>><br>> 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? :-)<br>><br>><br>> (*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 ...)<br>><br>> Best,<br>> Christoph<br>> ________________________________<br>> Von: Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von Jakob Reschke <forums.jakob@resfarm.de><br>> Gesendet: Samstag, 9. Mai 2020 12:27:52<br>> An: The general-purpose Squeak developers list<br>> Betreff: Re: [squeak-dev] Please try out | Inspector Refactoring =)<br>><br>> The improvements work well, thank you. :-)<br>><br>> I noticed a slight nuisance: you cannot drag an item from the<br>> Inspector to another morph to drag the actual object (the value).<br>> Instead, the field gets dragged. My current workaround is to explore<br>> the field and then drag the object from the explorer. Is there a nice<br>> way to improve on this without "unpacking" fields at every target<br>> location?<br>><br>> Am Mo., 27. Apr. 2020 um 23:29 Uhr schrieb David T. Lewis <lewis@mail.msen.com>:<br>> ><br>> > On Mon, Apr 27, 2020 at 10:35:11AM +0200, Marcel Taeumel wrote:<br>> > > Hi all!<br>> > ><br>> > > I just merged the inspector refactoring to Trunk. I'll stay tuned for issues. ;-)<br>> > ><br>> > > 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.<br>> > ><br>> > > Best,<br>> > > Marcel<br>> > > Am 26.04.2020 20:01:08 schrieb Thiede, Christoph <christoph.thiede@student.hpi.uni-potsdam.de>:<br>> > > Yes, this sounds good :-)<br>> ><br>> > Thank you Christoph and Marcel!<br>> ><br>> > Dave<br>> ><br>> ><br>><br>><br><br></christoph.thiede@student.hpi.uni-potsdam.de></lewis@mail.msen.com></forums.jakob@resfarm.de></squeak-dev-bounces@lists.squeakfoundation.org></christoph.thiede@student.hpi.uni-potsdam.de></div></blockquote></div>