<body><div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000">
Maybe Karl refers to the default behavior of TextMorph or PluggableTextMorph?<div><br></div><div>If you subclass PluggableTextMorph, TextMorph, TextEditor etc. you can add any additional stuff such as through Morphic's generic event handling.</div><div><br></div><div>Best,<br>Marcel</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;">
<p style="color: #AAAAAA; margin-top: 10px;">Am 03.07.2019 22:58:21 schrieb Chris Muller <ma.chris.m@gmail.com>:</p><div style="font-family:Arial,Helvetica,sans-serif">Hi Karl, I'm not sure what or how you tested, but "drag and drop of<br>morph on text in windows" works fine when the appropriate handlers are<br>set up (#mouseEnter:, etc.).<br><br>You can see it in action if you're willing to load Maui into a trunk<br>image (from SqueakMap). It has a class MauiTextEditor, which is just<br>a subclass of PluggableTextMorph with the handlers.<br><br> MauiTextEditor new openInWorld<br><br>type some text,<br>grab any Morph and, while holding Shift,<br>drag it into the text window.<br><br>An outline of the proposed position is shown, when you let go, the<br>morph is dropped and embedded as a character. Works with clipboard, etc.<br><br> - Chris<br><br><br> - Chris<br><br>On Wed, Jul 3, 2019 at 3:36 PM karl ramberg <karlramberg@gmail.com> wrote:<br>><br>> I did some more testing and found the drag and drop of morph on text in windows practically non functional.<br>> So I don't think you could break anything :-)<br>><br>> Best,<br>> Karl<br>><br>><br>> On Wed, Jul 3, 2019 at 8:26 PM Rein, Patrick <patrick.rein@hpi.de> wrote:<br>>><br>>> Hi Karl,<br>>><br>>> I agree that the drag and drop handling of TextMorphs is somewhat complex by now. While looking into the issue I found two kinds of issues: some more general ones and one related to layouting.<br>>><br>>> ## General Occlusion Bug<br>>><br>>> I have to admit that I was not aware of the avoid occlusions feature. I dug into it a little and<br>>> found TextContainer and the class comment which explains the feature. Then I constructed<br>>> the following example:<br>>><br>>> o := Morph new.<br>>> tm := TextMorph new<br>>> contents: 'This is a very long text with a lot of characters<br>>> spanning multiple lines overall and throughout the<br>>> place in order to trigger the occlusion thing';<br>>> yourself.<br>>> m := RectangleMorph new.<br>>> m position: tm topLeft + (10@10).<br>>> tm occlusionsOnOff.<br>>> o addMorph: tm.<br>>> o addMorph: m.<br>>> o openInWorld.<br>>><br>>> I tried it in trunk and Squeak 3.8 and in both it results in errors in NewParagraph>>#adjustRightX as<br>>> it expects container to behave like a rectangle.<br>>><br>>> However, the root cause seems to be that #adjustRightX does not make sense when having a fixed<br>>> TextContainer as it describes the individual rectangles in which the text can be set. One solution is<br>>> to set `tm wrapFlag: true` before turning avoidOcclusions on (otherwise #wrapFlag triggers a relayout<br>>> without tm having an owner which does not work...).<br>>><br>>> To make this more robust I would propose:<br>>> 1.) When activating occlusion we also set the wrapFlag<br>>> 2.) We do not try to avoid occlusions as long as the morph does not have an owner yet.<br>>><br>>> ## Text Anchor Related<br>>><br>>> Maybe this is more what you were thinking about Karl: I found that when having the above example<br>>> plus an anchored morph which is layouted inline most things work fine. Except for the layout issue<br>>> you can see in the attachment (the first morph in the third line is the anchored morph, the second one<br>>> is the m from the example above). The second part of the third line does not adhere to the offset of the<br>>> first part of the line. @Karl: Did you refer to that? (Not sure how to fix this yet...)<br>>><br>>> Bests<br>>> Patrick<br>>> ________________________________________<br>>> From: Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.org> on behalf of karl ramberg <karlramberg@gmail.com><br>>> Sent: Monday, July 1, 2019 11:44:34 AM<br>>> To: Chris Muller<br>>> Cc: The general-purpose Squeak developers list<br>>> Subject: Re: [squeak-dev] Proposal: Morphs in Text<br>>><br>>> One big issue with the drag and drop is that it is often not clear which morph one drop into.<br>>> There are so many layers of morphs in a text window so it gets confusing to know which morph to actually<br>>> enable to accepting the drop.<br>>><br>>> But drag and drop are probably a separate issue from text anchors constructed from<br>>> code. Just don't break it to badly :-)<br>>><br>>><br>>> Best,<br>>> Karl<br>>><br>>><br>>><br>>> Best.<br>>> Karl<br>>><br>>><br>>><br>>> On Mon, Jul 1, 2019 at 2:19 AM Chris Muller <><mailto:ma.chris.m@gmail.com>> wrote:<br>>> > I'm a little late here.<br>>> > TextMorph does not really need TextAnchor I think.<br>>> > You can just drop morphs on the text and select avoid occlusions in the menu.<br>>> > What are the use of text anchors instead just dropped in morphs ?<br>>> > I filed in TextAnchorPlacement change set and it interferes somewhat with the avoid occlusions functions.<br>>><br>>> I was wondering about the 'avoid occlusions' but spent all my focus on<br>>> the alignment testing, thanks for testing that too!<br>>><br>>> We should not break that. I like this new alignment capability, but<br>>> classic DTP text-handling is one of Squeak's most impressive<br>>> capabilities. Hopefully an easy fix..?<br>>><br>>><br>>> - Chris<br>>><br><br></mailto:ma.chris.m@gmail.com></karlramberg@gmail.com></squeak-dev-bounces@lists.squeakfoundation.org></patrick.rein@hpi.de></karlramberg@gmail.com></div></blockquote>
</div></body>