[squeak-dev] Improving SqueakToolsHelp class>>#fontSizeSummary reveals problems in Text & styles

karl ramberg karlramberg at gmail.com
Mon Jul 23 19:21:04 UTC 2018


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 <tim at rowledge.org> 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; tim at rowledge.org; http://www.rowledge.org/tim
> This is all a lot simpler and a lot more complicated than you could
> possibly imagine
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20180723/6ccbbc2c/attachment.html>


More information about the Squeak-dev mailing list