Hi Patrick,

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

Squeak *3.7* was the last release we included "The Worlds of Squeak" demo
project that showed off its capabilities, including its powerful
text-handling.  One of my favorite demos to show people was typing into
that upper-left bubble (under "Squeak Rulez") and watch:

    - text being inserted flowing into the next morphs!
    - even along that spline!
    - and into that lower box with an embedded Morph that demonstrating
occlusion avoidance!

[image: dtp-level-text-handling.png]

Selecting that yellow ellipse in the lower-right box and dragging it around
forces the text to reformat around the shape of the ellipse (e.g., not even
just a simple rectangle!).

Isn't it incredible?!  3.8 was the first release we stopped including this,
so little surprise that we broke it, but I do hope we you get this fixed up
again so that a cool demo like this at least *could* be done in 5.3 if we
wanted.

Best,
  Chris




>
> 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/20190703/861e8795/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dtp-level-text-handling.png
Type: image/png
Size: 62635 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20190703/861e8795/attachment.png>