Improving SqueakToolsHelp class>>#fontSizeSummary reveals problems in Text & styles

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Improving SqueakToolsHelp class>>#fontSizeSummary reveals problems in Text & styles

timrowledge
I wanted to make the help page for the font summary show the actual fonts; it seems an appropriate thing to do. Some ... interesting ... issues came up whilst looking into it.

Changing TextStyle class>>#fontSizeSummaryContents wasn't too hard. It's easy enough to stick in TextFontReferences that point to a relevant font and the resulting text can be displayed easily enough. It seems a bit strange the TextStyle>>knownTextStyles returns a list of symbols rather than the actual styles, but whatever.

That's where it stopped being simple. Upon opening a help browser the fonts were all flattened out to the default font of the default style. It turns out that in the building of the pluggable text morph the text font gets overwritten, although initially in the code it might look otherwise. See MorphicToolBuilder>>#buildPluggableText: and note where it says 'aSpec font ifNotNil:[:f| widget font: f]'. Since the spec #font method (PluggableTextSpec>>#font) returns the default font unless some other has been set, we will normally get the preferences set default font - Deja Vu san 9 in my image. This font is then blasted over the text with #beAllFont: which actually does a great deal of manipulating of the text's runs and produces a rather obese collection of runs all with the same values, rather than consolidating into a single run (modulo having other types of text attribute involved of course). Looking at how the TextMorph>>#beAllFont: and Text>>#addAttribute: works is quite interesting too, since we get into a rather complex and ripe for improved implementation subsystem where I see mis-use of #isKindOf: etc. in places where some double-dispatching would be much nicer.

Changing any of this seems like more change than we really want just before a release so it will have to wait and the font summary help page can't really be improved much until then. To make things a bit more irritating it is quite possible to generate the multi-font text and paste it into a text morph and see the desired effect!

And yet again the supposedly randomly chosen sigline summarises the entire thing rather well. "Random" my ass....

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
This is all a lot simpler and a lot more complicated than you could possibly imagine



Reply | Threaded
Open this post in threaded view
|

Re: Improving SqueakToolsHelp class>>#fontSizeSummary reveals problems in Text & styles

Karl Ramberg
I guess this is a case where we have traded direct access to change the look and feel. for the flexibility of a tool builder.
The HelpBrowser is a great idea but needs a good bit of care to make it a good, flexible, and useful tool inĀ 
the same vein the other Squeak tools.
Right now I hardly ever go to the HelpBrowser to look for answers, I search the web.
It would be cool if the HelpBrower would be so helpful I changed that.

Best,
Karl




On Mon, Jul 23, 2018 at 12:53 AM tim Rowledge <[hidden email]> wrote:
I wanted to make the help page for the font summary show the actual fonts; it seems an appropriate thing to do. Some ... interesting ... issues came up whilst looking into it.

Changing TextStyle class>>#fontSizeSummaryContents wasn't too hard. It's easy enough to stick in TextFontReferences that point to a relevant font and the resulting text can be displayed easily enough. It seems a bit strange the TextStyle>>knownTextStyles returns a list of symbols rather than the actual styles, but whatever.

That's where it stopped being simple. Upon opening a help browser the fonts were all flattened out to the default font of the default style. It turns out that in the building of the pluggable text morph the text font gets overwritten, although initially in the code it might look otherwise. See MorphicToolBuilder>>#buildPluggableText: and note where it says 'aSpec font ifNotNil:[:f| widget font: f]'. Since the spec #font method (PluggableTextSpec>>#font) returns the default font unless some other has been set, we will normally get the preferences set default font - Deja Vu san 9 in my image. This font is then blasted over the text with #beAllFont: which actually does a great deal of manipulating of the text's runs and produces a rather obese collection of runs all with the same values, rather than consolidating into a single run (modulo having other types of text attribute involved of course). Looking at how the TextMorph>>#beAllFont: and Text>>#addAttribute: works is quite interesting too, since we get into a rather complex and ripe for improved implementation subsystem where I see mis-use of #isKindOf: etc. in places where some double-dispatching would be much nicer.

Changing any of this seems like more change than we really want just before a release so it will have to wait and the font summary help page can't really be improved much until then. To make things a bit more irritating it is quite possible to generate the multi-font text and paste it into a text morph and see the desired effect!

And yet again the supposedly randomly chosen sigline summarises the entire thing rather well. "Random" my ass....

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
This is all a lot simpler and a lot more complicated than you could possibly imagine