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/20190704/1432d8a7/attachment.html>