[squeak-dev] Proposal: Morphs in Text

karl ramberg karlramberg at gmail.com
Sat Jul 6 17:55:16 UTC 2019


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 supposed
to go on.

Best,
Karl


On Thu, Jul 4, 2019 at 10:33 PM Bob Arning <arning315 at comcast.net> wrote:

> 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> 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> 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> 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 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>> 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/20190706/1510a22a/attachment.html>


More information about the Squeak-dev mailing list