GNOME Bugzilla – Bug 636868
font size setting is ignored
Last modified: 2011-03-15 19:16:27 UTC
When I change the 'font size' setting in the universal access panel, the gnome-shell appearance does not change. It may just be that the panel settings are not correctly hooked up. But manually changing the font with gsettings set org.gnome.desktop.interface font 'Sans 20' has no effect on the shell either.
(In reply to comment #0) > When I change the 'font size' setting in the universal access panel, the > gnome-shell appearance does not change. It may just be that the panel settings > are not correctly hooked up. No, unfortunately not. Font sizes are specified in CSS, generally using a fixed pixel size. Probably the right fix would be to interpret the setting as 1em and update the CSS to use relative sizes (for fonts and dependent settings, e.g. the panel height).
*** Bug 631767 has been marked as a duplicate of this bug. ***
Here is what Owen said about this: mclasen: mmm $ grep px gnome-shell.css | wc -l 347 mclasen: if we don't care if it looks great, but just want bigger fonts it's manageable $ grep px gnome-shell.css | grep font-size | wc -l 27 so we just need to take those 27 places and compute what pt size makes the px come out right at 96 dpi then we have to make sure that dpi is hooked up to GtkSettings correctly that's probably about an hour of work total
Created attachment 182518 [details] [review] Use points for font sizes Do a basic job of converting font sizes from pixels to points, so they will scale will the global GNOME scale factor. Some other sizes that are clearly related to the font sizes are changed to ems, but no comprehensive attempt is made to get rid of px units. === I think this is good enough to go in - things mostly look pretty good, especially if you just go to a modestly larger DPI value like 120. Bugs I know of beyond non-scaling images: - The arrow showing the current application filter isn't centered - I didn't try to handle the PANEL_ICON_SIZE constant in panel.js so the startup animation is likely broken (and I think we are assuming a fixed size in the image source for that) Most further work probably would be easier with CSS enhancements to allow loading our SVG image sources at something other than a fixed size and more flexible positioning (though we'd have to be careful about caching in that case.)
Just a minor nitpick: the patch removes PANEL_HEIGHT without replacing the references in overview.js and workspace.js
Created attachment 182574 [details] [review] Use points for font sizes New version removing all references to PANEL_HEIGHT
Comment on attachment 182574 [details] [review] Use points for font sizes Sorry, didn't noticed this was assigned to me. Seems to work (and makes things more readable on my laptop), but a few new px font-sizes have been added since you wrote the patch, so be sure to fix those too before committing.
Comment on attachment 182574 [details] [review] Use points for font sizes Pushed with addition point-size: ...px fixes
Not going to keep this open for the remaining px fixes. If someone is sufficiently inspired to work on making the UI fully resolution scalable they don't need a bug open as a reminder.
I've changed the the settings on my Eee to 78pt, which is in my opinion a good value for the small display. So I was very eager to see this patches! However, after the last commit [1] the panel lucks a bit ugly with a font size of 78pt [2], but changing the panel height like: #panel { /* ... */ height: 2.2em; } looks good imho [3]. Also, the 96pt setting (which I belive is the default, isn't?) doesnt look bad [4]. Can somebody with a better knowledge of the CSS unit system please review this small change? [1] http://git.gnome.org/browse/gnome-shell/commit/?id=e8eec2d357a5b4c6db312687c8987b0595e91bec [2] http://www.tux21b.org/public/screen-ui-eeepc-78pt.png [3] http://www.tux21b.org/public/screen-ui-eeepc-78pt-fixed.png [4] http://www.tux21b.org/public/screen-ui-eeepc-96pt-fixed.png
I believe the padding at 96dpi is correct currently and I don't think we should increase it just to make things look better at a small non-standard dpi. We'd take a patch that fixed the broken corners, but that might require more complicated size calculations.
Sure, I've just tried to find a value which doesn't look broken... Should I open a new ticket for the broken borders? You have closed this one a couple of minutes ago ;)