I think it's not really broken - adjustRightX is only used when wrapFlag 
is false, which is probably not the originally intended use for 
TextContainers. You could add a method or two to TextContainer to see if 
it would work when not wrappping.

On 7/4/19 4:00 PM, karl ramberg wrote:
>
>
> On Thu, Jul 4, 2019 at 8:50 PM karl ramberg <karlramberg at gmail.com 
> <mailto:karlramberg at gmail.com>> wrote:
>
>     The code in NewParagraph>>adjustRightX is broken.
>     It seem to expect a container that is a Rectangle and not a
>     TextContainer.
>     This method must be made to work with TextContainer.
>
>     NewParagraph>>adjustRightX
>     | shrink |
>     shrink := container right - maxRightX.
>     lines do: [:line | line paddingWidth: (line paddingWidth - shrink)].
>     container := container withRight: maxRightX + self caretWidth.
>
>     Best,
>     Karl
>
>
> NewParagraph seems to sometimes have Rectangle as container  and 
> sometimes a TextContainer.
> I'm not sure what to do about that...
>
> Best,
> Karl
>
>
>
>     On Wed, Jul 3, 2019 at 8:26 PM Rein, Patrick <Patrick.Rein at hpi.de
>     <mailto:Patrick.Rein at hpi.de>> wrote:
>
>         Hi Karl,
>
>         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.
>
>         ## General Occlusion Bug
>
>         I have to admit that I was not aware of the avoid occlusions
>         feature. I dug into it a little and
>         found TextContainer and the class comment which explains the
>         feature. Then I constructed
>         the following example:
>
>         o := Morph new.
>         tm := TextMorph new
>                 contents: 'This is a very long text with a lot of
>         characters
>         spanning multiple lines overall and throughout the
>         place in order to trigger the occlusion thing';
>                 yourself.
>         m := RectangleMorph new.
>         m position: tm topLeft + (10 at 10).
>         tm occlusionsOnOff.
>         o addMorph: tm.
>         o addMorph: m.
>         o openInWorld.
>
>         I tried it in trunk and Squeak 3.8 and in both it results in
>         errors in NewParagraph>>#adjustRightX as
>         it expects container to behave like a rectangle.
>
>         However, the root cause seems to be that #adjustRightX does
>         not make sense when having a fixed
>         TextContainer as it describes the individual rectangles in
>         which the text can be set. One solution is
>         to set `tm wrapFlag: true` before turning avoidOcclusions on
>         (otherwise #wrapFlag triggers a relayout
>         without tm having an owner which does not work...).
>
>         To make this more robust I would propose:
>         1.) When activating occlusion we also set the wrapFlag
>         2.) We do not try to avoid occlusions as long as the morph
>         does not have an owner yet.
>
>         ## Text Anchor Related
>
>         Maybe this is more what you were thinking about Karl: I found
>         that when having the above example
>         plus an anchored morph which is layouted inline most things
>         work fine. Except for the layout issue
>         you can see in the attachment (the first morph in the third
>         line is the anchored morph, the second one
>         is the m from the example above). The second part of the third
>         line does not adhere to the offset of the
>         first part of the line. @Karl: Did you refer to that? (Not
>         sure how to fix this yet...)
>
>         Bests
>         Patrick
>         ________________________________________
>         From: Squeak-dev
>         <squeak-dev-bounces at lists.squeakfoundation.org
>         <mailto:squeak-dev-bounces at lists.squeakfoundation.org>> on
>         behalf of karl ramberg <karlramberg at gmail.com
>         <mailto:karlramberg at gmail.com>>
>         Sent: Monday, July 1, 2019 11:44:34 AM
>         To: Chris Muller
>         Cc: The general-purpose Squeak developers list
>         Subject: Re: [squeak-dev] Proposal: Morphs in Text
>
>         One big issue with the drag and drop is that it is often not
>         clear which morph one drop into.
>         There are so many layers of morphs in a text window so it gets
>         confusing to know which morph to actually
>         enable to accepting the drop.
>
>         But drag and drop are probably a separate issue from text
>         anchors constructed from
>         code. Just don't break it to badly  :-)
>
>
>         Best,
>         Karl
>
>
>
>         Best.
>         Karl
>
>
>
>         On Mon, Jul 1, 2019 at 2:19 AM Chris Muller
>         <ma.chris.m at gmail.com
>         <mailto:ma.chris.m at gmail.com><mailto:ma.chris.m at gmail.com
>         <mailto:ma.chris.m at gmail.com>>> wrote:
>         > I'm a little late here.
>         > TextMorph does not really need TextAnchor I think.
>         > You can just drop morphs on the text and select avoid
>         occlusions in the menu.
>         > What are the use of text anchors instead just dropped in
>         morphs ?
>         > I filed in TextAnchorPlacement change set and it interferes
>         somewhat with the avoid occlusions functions.
>
>         I was wondering about the 'avoid occlusions' but spent all my
>         focus on
>         the alignment testing, thanks for testing that too!
>
>         We should not break that.  I like this new alignment
>         capability, but
>         classic DTP text-handling is one of Squeak's most impressive
>         capabilities.  Hopefully an easy fix..?
>
>
>          - Chris
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20190704/3b3c2bc8/attachment.html>