[squeak-dev] Proposal: Morphs in Text

Patrick Rein patrick.rein at hpi.uni-potsdam.de
Sun Jul 7 19:20:36 UTC 2019

To quote my earlier proposal:

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. 

adjustX adjusts the Paragraph bounds to the rightmost character. This does not make sense for TextContainers as they dictate the rightmost point for layouting. (Even if you make that work, there are other such constraints (I tried it :))). Thus when having a TextContainer the wrapFlag should always be set to true. 

At the same time it is right that pre-formatted text should also work with occlusion ideally. but this goes beyond the initial bug we are trying to fix here (at least that was my impression). 


⁣BlueMail for Android herunterladen ​

Am 6. Juli 2019, 19:55, um 19:55, karl ramberg <karlramberg at gmail.com> schrieb:
>I looked at the code and I'm really not sure what to do.
>I don't think understand what is going on in the code, and what is
>to go on.
>On Thu, Jul 4, 2019 at 10:33 PM Bob Arning <arning315 at comcast.net>
>> I think it's not really broken - adjustRightX is only used when
>> 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>
>>> The code in NewParagraph>>adjustRightX is broken.
>>> It seem to expect a container that is a Rectangle and not a
>>> 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
>> 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>
>>>> 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
>>>> 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
>>>> Then I constructed
>>>> the following example:
>>>> o := Morph new.
>>>> tm := TextMorph new
>>>>         contents: 'This is a very long text with a lot of
>>>> 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
>>>> NewParagraph>>#adjustRightX as
>>>> it expects container to behave like a rectangle.
>>>> However, the root cause seems to be that #adjustRightX does not
>>>> sense when having a fixed
>>>> TextContainer as it describes the individual rectangles in which
>>>> text can be set. One solution is
>>>> to set `tm wrapFlag: true` before turning avoidOcclusions on
>>>> #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
>>>> an owner yet.
>>>> ## Text Anchor Related
>>>> Maybe this is more what you were thinking about Karl: I found that
>>>> having the above example
>>>> plus an anchored morph which is layouted inline most things work
>>>> Except for the layout issue
>>>> you can see in the attachment (the first morph in the third line is
>>>> anchored morph, the second one
>>>> is the m from the example above). The second part of the third line
>>>> not adhere to the offset of the
>>>> first part of the line. @Karl: Did you refer to that? (Not sure how
>>>> fix this yet...)
>>>> Bests
>>>> Patrick
>>>> ________________________________________
>>>> From: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> on
>>>> behalf of karl ramberg <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
>>>> morph one drop into.
>>>> There are so many layers of morphs in a text window so it gets
>>>> 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>> 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
>>>> the menu.
>>>> > What are the use of text anchors instead just dropped in morphs ?
>>>> > I filed in TextAnchorPlacement change set and it interferes
>>>> with the avoid occlusions functions.
>>>> I was wondering about the 'avoid occlusions' but spent all my focus
>>>> the alignment testing, thanks for testing that too!
>>>> We should not break that.  I like this new alignment capability,
>>>> classic DTP text-handling is one of Squeak's most impressive
>>>> capabilities.  Hopefully an easy fix..?
>>>>  - Chris

More information about the Squeak-dev mailing list