[squeak-dev] Proposal: Morphs in Text
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.
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.
>> | shrink |
>> shrink := container right - maxRightX.
>> lines do: [:line | line paddingWidth: (line paddingWidth - shrink)].
>> container := container withRight: maxRightX + self caretWidth.
> NewParagraph seems to sometimes have Rectangle as container and sometimes
> a TextContainer.
> I'm not sure what to do about that...
>> 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';
>>> 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...)
>>> 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 :-)
>>> 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...
More information about the Squeak-dev