Whilst checking my RotaryDialMorphs stuff in an update to 17183 image I noticed that the labels looked awful. Turns out that the default TextStyle was broken to just one font and so trying to choose a size to suit my dials could only find a 9pt one. Given that this then gets scaled down as part of some anti-aliasing it looks terribly small at the end.
The question is of course why the text style was so limited. After investigation it seems that the latest version of Preferences class> setSystemFontTo: was changed on 8/30/2016 such that it fairly carefully makes a broken style instead of what the prior version did. Since the changes here were made by marcel & TimF as part of the themes upgrade I’m loath to simply override them and force it back. It may be mixed in with other stuff that I don’t know about, so I’d rather not break it. As a temporary measure, reverting to Marcel’s 8/19/2016 version seems to be the solution. A side-weirdness just to make life interesting was that the first time I changed the default find using the font chooser the screen background suddenly reverted to the dark gray linen pattern. I haven’t been able to spot a code path that could explain that and it doesn’t seem to happen now so… haunted image? tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: PSM: Print and SMear |
> On 22-04-2017, at 10:51 AM, tim Rowledge <[hidden email]> wrote: > > A side-weirdness just to make life interesting was that the first time I changed the default find using the font chooser the screen background suddenly reverted to the dark gray linen pattern. I haven’t been able to spot a code path that could explain that and it doesn’t seem to happen now so… haunted image? I’ve tried this again in a recent image - I tried a 16963 update- and 'World menu’->’appearance’->’system fonts’-> ‘default text font’, then choose a font and apply. Whoosh, desktop pattern changes. Funny thing is this won’t repeat. And it doesn’t happen in a completely plain image, only one where I had loaded my.prefs some time previously; and yet not in a plain 16549 image where I loaded my.prefs and tried the font change. Curiouser and curiouserer. I can offer a sample image if anyone (like say, Marcel or TimF) is interested. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Useful Latin Phrases:- Quantum materiae materietur marmota monax si marmota monax materiam possit materiari? = How much wood would a woodchuck chuck if a woodchuck could chuck wood? |
You might want to look at something like: setSystemFontTo: aFont which when you change the system font does
an #apply of the current theme. I found that changing the font
from 12 point serif to 12 point sans serif made radical changes
in the size of open windows. On 4/23/17 12:26 AM, tim Rowledge
wrote:
On 22-04-2017, at 10:51 AM, tim Rowledge [hidden email] wrote: A side-weirdness just to make life interesting was that the first time I changed the default find using the font chooser the screen background suddenly reverted to the dark gray linen pattern. I haven’t been able to spot a code path that could explain that and it doesn’t seem to happen now so… haunted image?I’ve tried this again in a recent image - I tried a 16963 update- and 'World menu’->’appearance’->’system fonts’-> ‘default text font’, then choose a font and apply. Whoosh, desktop pattern changes. Funny thing is this won’t repeat. And it doesn’t happen in a completely plain image, only one where I had loaded my.prefs some time previously; and yet not in a plain 16549 image where I loaded my.prefs and tried the font change. Curiouser and curiouserer. I can offer a sample image if anyone (like say, Marcel or TimF) is interested. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Useful Latin Phrases:- Quantum materiae materietur marmota monax si marmota monax materiam possit materiari? = How much wood would a woodchuck chuck if a woodchuck could chuck wood? |
> On 23-04-2017, at 3:31 AM, Bob Arning <[hidden email]> wrote: > > You might want to look at something like: > > setSystemFontTo: aFont > "Establish the default text font and style" > > | aStyle newDefaultStyle | > aFont ifNil: [^ self]. > aStyle := aFont textStyle ifNil: [^ self]. > newDefaultStyle := aStyle copy. > newDefaultStyle defaultFontIndex: (aStyle fontIndexOf: aFont). > > UserInterfaceTheme current > set: #standardSystemFont to: aFont; > apply. > > TextStyle setDefault: newDefaultStyle. > Flaps replaceToolsFlap. > ScriptingSystem resetStandardPartsBin. > > which when you change the system font does an #apply of the current theme. Yeah, I looked at that and simply assumed the #apply meant ‘apply the font change’ rather than ‘do approximately half a billion loops through all the objects in the image’. Really - applying a theme change finds all the plausible theme clients (656 in my image) and then for each one scans every object in the image to see if it needs altering. Thats ~750,000 objects and touching every one of them 650 times. I suspect we can improve that a bit. Admittedly this isn’t something done terribly often so it’s hardly a major performance bottleneck in daily life but imagine trying it in a *big* image that results in page thrashing. At least we should consider using something like self classesThatWantToPratAroundWithThemesDo: [cl| cl allInstancesDo:[:inst| inst applyUserInterfaceTheme]] So the background thing becomes a little clearer; MorphicProject>applyUserInterfaceTheme checks to see if the world hasProperty: #hasCustomBackground - which in the ‘problem’ image it does not. Thus the #setWorldBackground: method goes through its somewhat convoluted checks and sets the background to the theme default. Since the #hasCustomBackground property is newly introduced as part of the theme stuff it is not too surprising that it wasn’t already set in an older image that got updated. I wouldn’t be too surprised if a similar change made for you r window size alterations. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim ...now touch these wires to your tongue! |
Well, no, I expect it's more the original
problem you were noting. Given that f _ TextStyle named: n. {f. f pointSizes}] ==> {{a TextStyle BitstreamVeraSans . #(9 12 13 15 24 36)} . {a TextStyle BitstreamVeraSans . #(6 9 11 17 26)}} and TTCFont>>textStyle ^ TextStyle actualTextStyles detect: [:aStyle | (aStyle fontArray collect: [:s | s name]) includes: self name] ifNone: [nil] selects *a* style with the same name, then trying to install the real BitstreamVeraSans may end up installing the one alternately known as ComicSansMS. This one has different point sizes from those proffered in the FontChooserTool, so the font you actually get is the smallest which is 6 point and hence a decision to resize all windows appropriately. Even if they really don't care what the default font is. Given the implementation of #textStyle, it's probably a very bad idea to share font names like this. On 4/23/17 1:03 PM, tim Rowledge wrote:
I wouldn’t be too surprised if a similar change made for you r window size alterations. |
Free forum by Nabble | Edit this page |