[squeak-dev] Proposal: Morphs in Text

karl ramberg karlramberg at gmail.com
Wed Jul 3 20:35:56 UTC 2019


I did some more testing and found the drag and drop of morph on text in
windows practically non functional.
So I don't think you could break anything :-)

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/20190703/54b1f3de/attachment-0001.html>


More information about the Squeak-dev mailing list