[squeak-dev] Request for help: TextAnchor display broken in 3.9 and newer

hello list,


I have been spending an unreasonable amount of time trying to debug the
following code snippet:

(Workspace new contents:
   ((Character value: 1) asText addAttribute:
     (TextAnchor new anchoredMorph: Morph new) from: 1 to: 1))
openLabel: 'test'

it works fine in 3.8, not in newer images.


I could use some help...


thanks

Stef

On Wed, Dec 17, 2008 at 1:47 PM, Stéphane Rollandin
<[hidden email]> wrote:
> (Workspace new contents:
>  ((Character value: 1) asText addAttribute:
>    (TextAnchor new anchoredMorph: Morph new) from: 1 to: 1))
> openLabel: 'test'

Try using something like that:

        aText
                addAttribute: (TextDoIt evalString: codeToExecute)
                from: before
                to: after.
                                               

--
Damien Cassou
http://damiencassou.seasidehosting.st

> Try using something like that:
>
> aText
> addAttribute: (TextDoIt evalString: codeToExecute)
> from: before
> to: after.

the bug I'm struggling with is really specific to TextAnchor attributes.
other attributes seem to work ok AFAIK.

Stef

Stef,

Removing TextAnchor>>#emphasizeScanner will solve your problem*.  It  
appears that Lukas Renggli in 2006 overrode that method from  
TextAttribute.  This then caused a cycle in which it seems that text  
attributes were being parsed twice.  This can be seen by following the  
stack (reversed):

CompositionScanner calls #setStopConditions, calls #setFont, which  
calls #emphasizeScanner, which called TextAnchor's overridden method,  
which called #setFont, which started the process all over again.

This means that the "StopCondition" #embeddedObject, which is the true  
way to add the embedded morph, was never being called.   The override  
tried to do the work of the StopCondition itself, seemingly out of the  
chain of command and out of order.

I suppose this is something which should be fixed.  I am not sure of  
the purpose of Lukas's override... hopefully he can shine some light  
on its intended purpose.

HTH,
Thanks,
TimJ

* But is also unveils a rendering glitch.  Now that invisible  
characters are being printed as boxes, the Workspace now prints one of  
those empty boxes underneath your embedded morph.  This is probably  
because an embedded morph is represented in a Text object by the  
Character value 2.



On Dec 17, 2008, at 6:47 AM, Stéphane Rollandin wrote:

On Dec 18, 2008, at 12:09 PM, Tim Johnson wrote:

> Removing TextAnchor>>#emphasizeScanner

I'm sorry, I meant TextAnchor>>#emphasizeScanner:

Thanks,
TimJ

> I suppose this is something which should be fixed.  I am not sure of the
> purpose of Lukas's override... hopefully he can shine some light on its
> intended purpose.

Check out these two threads:

http://lists.squeakfoundation.org/pipermail/v3dot9/2006-January/000188.html
http://lists.squeakfoundation.org/pipermail/v3dot9/2006-February/000229.html

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

On Dec 18, 2008, at 12:18 PM, Lukas Renggli wrote:

Thanks, Lukas.  From what I can tell from these threads, your method  
override was not to fix anything, but rather was just put in place  
because the method was not present.  In removing your method, not only  
does Stéphane's code work, but also the BadgeMorph's text chat now  
works again* (this was the only code I could find in the image which  
actually used TextAnchor).  I would consider the BadgeMorph to be a  
true "proof of concept" so now that it works again maybe it is a sign  
that we should remove your change to TextAnchor.

I will go through the process of creating a Mantis report, creating  
test cases, making a changeset, ... I guess.  I don't know how to make  
a changeset that only says to remove a method.  Any guidance?

Thanks,
TimJ

* For the curious who want to test/repeat... open the Objects flap,  
drag out a Badge morph, enter your name if it asks, hit the button  
labelled "C".  Enter text in the top pane and hit return.  With  
TextAnchor>>#emphasizeScanner: in place, you will get two or three DNU  
windows.  Without TextAnchor>>#emphasizeScanner: in place, you will  
see a little avatar of yourself appear next to your message in the  
bottom page, and no DNUs.  Please don't try hitting the "T" on the  
BadgeMorph, though :)

> Thanks, Lukas.  From what I can tell from these threads, your method
> override was not to fix anything, but rather was just put in place because
> the method was not present.

As I write in <http://lists.squeakfoundation.org/pipermail/v3dot9/2006-February/000233.html>
this method was present in older images, I only re-added it.

> In removing your method, not only does
> Stéphane's code work, but also the BadgeMorph's text chat now works again*
> (this was the only code I could find in the image which actually used
> TextAnchor).  I would consider the BadgeMorph to be a true "proof of
> concept" so now that it works again maybe it is a sign that we should remove
> your change to TextAnchor.

I don't think so. All subclasses of TextAttribute implement
#emphasizeScanner:. There would be no point in having the
TextAttribute class, if it does not implement #emphasizeScanner:. The
#emphasizeScanner: method is like the #accept: method in the visitor
pattern. If it is not there, the object is simply ignored.

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

On Dec 18, 2008, at 4:38 PM, Lukas Renggli wrote:

>> Thanks, Lukas.  From what I can tell from these threads, your method
>> override was not to fix anything, but rather was just put in place  
>> because
>> the method was not present.
>
> As I write in <http://lists.squeakfoundation.org/pipermail/v3dot9/2006-February/000233.html 
> >
> this method was present in older images, I only re-added it.

Ah, this old method[1] from v3.2 that specifically says the method is  
not necessary:

!TextAnchor methodsFor: 'as yet unclassified' stamp: 'ar 12/17/2001  
01:19'!
emphasizeScanner: scanner
"Do nothing for emphasizing the scanner - if the anchor is valid a  
#embeddedObject will be encountered by the scanner and do the real  
thing"! !

...?  You certainly didn't "re-add" *that*.  What is the use in  
following a pattern if it breaks the code?

Thanks,
TimJ


[1] http://ftp.squeak.org/updates/4614TextAndFonts-ar.cs

> I don't think so. All subclasses of TextAttribute implement
> #emphasizeScanner:. There would be no point in having the
> TextAttribute class, if it does not implement #emphasizeScanner:. The
> #emphasizeScanner: method is like the #accept: method in the visitor
> pattern. If it is not there, the object is simply ignored.

Also, it appears that the point of the TextAnchor class is to hold the #anchoredMorph.  The
superclass, TextAttribute, specifically rejects #anchoredMorph.

- TimJ

I don't remember the details. As far as I remember is change was
necessary to add icons into the colums of OB. Nowadays OB has its own
ListMorph with custom drawing code so it probably doesen't matter
anyway.

On 12/19/08, [hidden email] <[hidden email]> wrote:

--
Lukas Renggli
http://www.lukas-renggli.ch

Tim, thanks a lot for this.

I tried many things (and I did notice that the anchored morph was
handled twice) but only succeeded in confusing myself completely :) I
never thought about removing that method ...

BTW, for an usage of anchored morphs, load the Colors package in
Squeakmap and do Color displayNamedColors


Stef

Lukas Renggli wrote:
> I don't think so. All subclasses of TextAttribute implement
> #emphasizeScanner:. There would be no point in having the
> TextAttribute class, if it does not implement #emphasizeScanner:. The
> #emphasizeScanner: method is like the #accept: method in the visitor
> pattern. If it is not there, the object is simply ignored.

Good point. I probably should have left it in for this reason. The
origin of this change is that TextAttribute only modifies text and that
the text must be drawn nonetheless. This makes it impossible to get the
spacing "right" when you try to place small glyphs as inline graphics at
relatively large font sizes (you really need an infinitely small empty
glyph for that) which is what made me change this to a stop condition
instead.

When I changed this I simply vectored the stop condition #embeddedObject
into #placeEmbeddedObject: but as you say, this may be incorrect from a
semantic perspective. It might be better to fix this by having the
embeddedObject stop condition call into #skipForEmbeddedObject:
with a comment explaining that we don't want to display anything here
because there will be a text attribute containing some graphics which is
supposed to define the width of the glyph.

Although ... I'm not certain this all worked correctly in the original
version - I think there were issues with line breaks and selection of
the graphics etc. Computing this as the width of that special character
makes it pretty straightforward to deal with all that. Or whatever :-)

In any case, calling #placeEmbeddedObject: twice is very clearly wrong.

Cheers,
   - Andreas

>
> * But is also unveils a rendering glitch.  Now that invisible characters
> are being printed as boxes, the Workspace now prints one of those empty
> boxes underneath your embedded morph.  This is probably because an
> embedded morph is represented in a Text object by the Character value 2.

here is a handy method wrapping all is needed for anchoring a morph,
returning a Text ready for display; the empty boxes are rendered
invisible by setting their color to transparent.


Morph>>asAnchoredText

   ^ (Character value: 1) asText
    addAttribute: (TextAnchor new anchoredMorph: self) from: 1 to: 1;
    addAttribute: (TextColor color: Color transparent) from: 1 to: 1.



Stef

Hi Stephen, you might also be interested in these fixes I applied to
get embedded Morphs into Text working, which is heavily used by Maui.
I didn't remove TextAnchor>>#compositionScanner:, maybe that would
have solved all of the problems; I doubt it.

There is still one bug... errr, "feature" left:  If a Morph is the
first "Character" of a line, it will be centered.  If you place a
space or any other character on that same line, it flows naturally as
a character.

 - Chris



On Fri, Dec 19, 2008 at 7:10 AM, Stéphane Rollandin
<[hidden email]> wrote:

Hi Stephen, you might also be interested in these fixes I applied to
get embedded Morphs into Text working, which is heavily used by Maui.
I didn't remove TextAnchor>>#compositionScanner:, maybe that would
have solved all of the problems; I doubt it.

There is still one bug... errr, "feature" left:  If a Morph is the
first "Character" of a line, it will be centered.  If you place a
space or any other character on that same line, it flows naturally as
a character.

 - Chris



On Fri, Dec 19, 2008 at 7:10 AM, Stéphane Rollandin
<[hidden email]> wrote:

Hi Stephen, you might also be interested in these fixes I applied to
get embedded Morphs into Text working, which is heavily used by Maui.
I didn't remove TextAnchor>>#compositionScanner:, maybe that would
have solved all of the problems; I doubt it.

There is still one bug... errr, "feature" left:  If a Morph is the
first "Character" of a line, it will be centered.  If you place a
space or any other character on that same line, it flows naturally as
a character.

 - Chris



On Fri, Dec 19, 2008 at 7:10 AM, Stéphane Rollandin
<[hidden email]> wrote:

thanks

however I have had Morphs embedded in a Text working for years (in a 3.8
image), so I think I don't need these changes. I remember having fixed
something for the case you describe (Morph as a first Character) but I
don't remember what it is. removing TextAnchor>>#compositionScanner:
(which is not present in 3.8) made it work for newer images too.

all my changes are visible in muO (author 'spfa'). by the way, I tried
to load both Maui and muO in a same fresh 3.9 image and I did not
succeed. too bad...

regards,

Stef

(Sorry about the multiple posts..)