dalehenrich
commented
3 weeks ago I didn't know about scale factor ... a scale factor of 0.7 gives me a usable project browser without having to resort to full screen mode ... and it (bosch/linux) compares favorably with a windows image (rebus/windows) that is not scaled:
in fact I have more usable screen real estate inside the bosch pharo window ...
I have yet to spend hours working in (bosch/linux) like I have in (rebus/windows) ...
I agree that that the JfP windows should scale with font size and the scroll bars should not cut off ... since that appears to be the way other pharo windows behave ...
I am still annoyed that even with scaling 1/5 of the window height is dedicated to the header and footer ... if the shortcut buttons (including the autocommit button at the bottom) could be put on the same line as the menus and the empty gray space between the code pane and the autocommit button was eliminate we'd get a pretty good chunk of the "wasted real estate" back ...
Now that I'm using the scaling "workaround(?)" I don't feel that this is a super high priority item ...
ericwinger
JadeiteBrowser>>#initializeWindow:currently opens browsers at a default initialExtent: of 1600@1000. If that extent is changed to 1200@1000, the resulting browser has the method pane cutoff as in the picture.Ideally, a browser's size wouldn't be initially fixed but would instead open based on the font size selected in Pharo. Pharo's browsers open this way.
Extra information:
SystemWindow>>initializemay hold some clues to how scaling and sizing are done. Not sure if some of these api's are available in Spec2 from which JfP windows are built.Scale factor may also be a factor. Not sure quite what it does.
Pharo settings browser font selection & scale factor: