Open LinqLover opened 1 year ago
Sounds like this is something we should fix but I'm afraid it won't happen this week. I'm now sure we can automate image updates completely, but maybe some of it can be automated.
No hurry because there is a workaround. :)
Description of the bug
The provided
Squeak64-6.0
image is configured with a non-default display scale configuration. If you open the image in headful mode on a "normal" (i.e., non-high-DPI monitor), the scale factor will automatically be corrected during the first world cycle before the command line argument script is executed (seeDisplayScreen class>>#checkForNewScreenScaleFactor
and senders). However, in headless mode, this does not happen (presumably becauseprimitiveScreenScaleFactor
fails without a display andDisplayScreen>>#platformScaleFactor:
early exits without updating/resetting theuiScaleFactor
).Affected images:
Only
Squeak64-6.0
seems to be affected by the configuration drift.Squeak32-6.0
is fine, 5.3 and older are fine, Trunk images are fine.Consequences of the bug
This non-default configuration involves multiple problems:
When the image is started in headful mode, the scale factor will be corrected automatically, but this involves an automatic change to the size of the host window, too (see
UserInterfaceTheme>>#scaleMorphicWorldBy:
). Not only may all this "flickering" confuse users who are debugging a smalltalkCI build, but also some X Servers for Linux cannot tolerate theprimitiveHostWindowSizeSet
invocation: My VcXsrv server for WSL 1, Windows 21H1, reproducibly crashes when the VM attempts to change the size of the host window. One might argue that this is not a direct debt of smalltalkCI, though. Still, it hinders users of WSL1 from debugging these smalltalkCI builds. :-)VcXsrv crash
Origin of the bug
I suppose that the non-default configuration is the result of manually installing the image on a Mac in headful mode:
Possible solutions
The image can be fixed by reopening the image in headful mode on a normal-DPI screen in Windows and re-saving it. I dare to claim that the issue would not have occured if the image would have been set up in a completely automated process by a CI. :-)
As a workaround, I have added the following preTesting script to my
.smalltalk.ston
file:I think that the right solution to fix the issue would be to recreate/correct the image as described above and update the release.
tl;dr: @fniephaus Could you update the
Squeak64-6.0
image with a regular 100%uiScaleFactor
? If there is any chance I can help you with this, please let me know :)/cc @marceltaeumel FYI of the mentioned scaling behavior in Squeak. While I am sure that the smalltalkCI image should indeed use a standard scaling factor, is it intended behavior that the
uiScaleFactor
is not reset when the image is started in headless mode?