[squeak-dev] Proposal: Morphs in Text

H. Hirzel hannes.hirzel at gmail.com
Thu Aug 22 15:49:03 UTC 2019


Hello

what happened to Patrick's  proposals?

"
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.
"

Kind regards
Hannes

On 7/7/19, Patrick Rein <patrick.rein at hpi.uni-potsdam.de> wrote:
> 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).
>
> Bests
> Patrick
>
> ⁣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
>>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
>>>>>
>>>>>
>>>
>>>
>>>
>>
>>
>>------------------------------------------------------------------------
>
>
>


More information about the Squeak-dev mailing list