Proposal: Morphs in Text

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@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 <[hidden email]> on behalf of karl ramberg <[hidden email]>
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 <[hidden email]<mailto:[hidden email]>> 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

Hi Karl, I'm not sure what or how you tested, but "drag and drop of
morph on text in windows" works fine when the appropriate handlers are
set up (#mouseEnter:, etc.).

You can see it in action if you're willing to load Maui into a trunk
image (from SqueakMap).  It has a class MauiTextEditor, which is just
a subclass of PluggableTextMorph with the handlers.

    MauiTextEditor new openInWorld

type some text,
grab any Morph and, while holding Shift,
drag it into the text window.

An outline of the proposed position is shown, when you let go, the
morph is dropped and embedded as a character.  Works with clipboard, etc.

 - Chris


 - Chris

On Wed, Jul 3, 2019 at 3:36 PM karl ramberg <[hidden email]> wrote:
>
> 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 <[hidden email]> 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@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 <[hidden email]> on behalf of karl ramberg <[hidden email]>
>> 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 <[hidden email]<mailto:[hidden email]>> 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
>>

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@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 <[hidden email]> on behalf of karl ramberg <[hidden email]>
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 <[hidden email]<mailto:[hidden email]>> 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

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 <[hidden email]> 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 <[hidden email]> 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@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 <[hidden email]> on behalf of karl ramberg <[hidden email]>
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 <[hidden email]<mailto:[hidden email]>> 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