<body><div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000">
<span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px">> Isn't it incredible?! 3.8 was the first release we stopped including this, so little surprise that we broke it, but I do hope we you get this fixed up again so that a cool demo like this at </span><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px">> least </span><b style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px">could</b><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px"> be done in 5.3 if we wanted.</span><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px">We should write more tests. :-) Such examples are nice to learn from. Yet, they cannot replace automated testing. There have been several bugs in the recent past despite objects (or games or apps) being in the release image to reveal them.</span></div></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px">Best,</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px;line-height: 19.5px">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;">
<p style="color: #AAAAAA; margin-top: 10px;">Am 03.07.2019 21:32:15 schrieb Chris Muller <asqueaker@gmail.com>:</p><div style="font-family:Arial,Helvetica,sans-serif">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"><div dir="ltr"><div dir="ltr">Hi Patrick,</div><div dir="ltr"><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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></blockquote><div><br></div><div>Squeak <b>3.7</b> was the last release we included "The Worlds of Squeak" demo project that showed off its capabilities, including its powerful text-handling. One of my favorite demos to show people was typing into that upper-left bubble (under "Squeak Rulez") and watch:</div><div><br></div><div> - text being inserted flowing into the next morphs!</div><div> - even along that spline!</div><div> - and into that lower box with an embedded Morph that demonstrating occlusion avoidance!</div><div><br></div><div><div><img src="cid:ii_jxnmiknj1" alt="dtp-level-text-handling.png" width="548" height="431"></img><br></div></div><div><br></div><div>Selecting that yellow ellipse in the lower-right box and dragging it around forces the text to reformat around the shape of the ellipse (e.g., not even just a simple rectangle!).</div><div><br></div><div>Isn't it incredible?! 3.8 was the first release we stopped including this, so little surprise that we broke it, but I do hope we you get this fixed up again so that a cool demo like this at least <b>could</b> be done in 5.3 if we wanted.</div><div><br></div><div>Best,</div><div> Chris</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<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 <<a href="mailto:squeak-dev-bounces@lists.squeakfoundation.org" target="_blank">squeak-dev-bounces@lists.squeakfoundation.org</a>> on behalf of karl ramberg <<a href="mailto:karlramberg@gmail.com" target="_blank">karlramberg@gmail.com</a>><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 <<a href="mailto:ma.chris.m@gmail.com" target="_blank">ma.chris.m@gmail.com</a><mailto:<a href="mailto:ma.chris.m@gmail.com" target="_blank">ma.chris.m@gmail.com</a>>> 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>
</blockquote></div></div>
</div></blockquote>
</div></body>