[squeak-dev] Proposal: Morphs in Text
asqueaker at gmail.com
Wed Jul 3 19:31:26 UTC 2019
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.
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
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
> 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
> > 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...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 62635 bytes
Desc: not available
More information about the Squeak-dev