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 lecteur@zogotounga.net 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.
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:
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
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
On Dec 18, 2008, at 12:18 PM, Lukas Renggli wrote:
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
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
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
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, tjohnson@iwu.edu tjohnson@iwu.edu 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.
Also, it appears that the point of the TextAnchor class is to hold the #anchoredMorph. The superclass, TextAttribute, specifically rejects #anchoredMorph.
- TimJ
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
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
- 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 lecteur@zogotounga.net wrote:
- 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
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
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 lecteur@zogotounga.net wrote:
- 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 lecteur@zogotounga.net wrote:
- 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
(Sorry about the multiple posts..)
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Chris Muller -
Damien Cassou -
Lukas Renggli -
Stéphane Rollandin -
Tim Johnson -
tjohnson＠iwu.edu