P.S. Is the change set I need to file in still the one from the mail of
Patrick Rein, Jun 28, 2019 at 2:40 PM?



On 8/22/19, H. Hirzel <hannes.hirzel at gmail.com> wrote:
> 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
>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>------------------------------------------------------------------------
>>
>>
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Question_which_changeSet_for_TextMorph_Screenshot_2019-08-22.png
Type: image/png
Size: 54401 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20190822/12c12408/attachment-0001.png>