GNOME Bugzilla – Bug 104913
Font doesn't return to normal size when choosing a theme that doesn't specify a font
Last modified: 2006-04-20 17:27:01 UTC
I guess this maybe isn't a bug so much as a side-effect of the current non-role of fonts in themes, but it's certainly a regression, so here goes... If I select a large print theme, choose to apply its big font, and then select the default theme again, the font stays big. This just feels rather unexpected, and it's not immediately obvious that the solution is to go and change your Fonts preferences (rather than restart all the affected apps which is what I did the first few times before it dawned on me!) In the pre theme-manager days this "just worked"; a theme that didn't specify a font size used the default font size instead, but I guess things have changed a bit since then... but maybe there's a case for having an "Apply default font" button for themes that don't specify a font, instead of just hiding the "Apply suggested font" button?
In order of my personal preference, three other possible solutions to this might be: - Add a Revert button to the dialog, that reverts the theme and fonts to the values they were set to when you opened the dialog. This way you can always get back to a sane state without having to visit any other dialogs. - Save current font settings as part of saving a custom theme. Then at least you'll have the option of getting a sane font back (by pressing the Apply Font button) when you choose one of your saved themes, if not when you choose a 'standard' theme. - Automatically apply default system font and size when selecting a theme that doesn't specify fonts. However, if you don't normally use sans/serif/monospaced as your fonts, this still won't give you the fonts you really wanted and you'll still have to visit the Fonts dialog afterwards.
Jody/Jrb, your comments here will help me to try out a feasible soultion ... Thanks.
Updating status_whiteboard field to reflect A11Y team's assessment of accessibility impact.
*** Bug 113048 has been marked as a duplicate of this bug. ***
I have changed the severity since it's an enhancement rather than a bug. Thanks.
Hi, A friendly ping to the maintainers for their comments on the above given proposals:) Thanks.
Changing severity, priority and version.
Hrmm, slightly disappointing that an accessibility feature regression has been lowered in priority... think we need some patches here to convince them otherwise guys :) I guess part of the problem is we still haven't really decided whether dialogs generally should have Undo, Revert or Default buttons, which could provide a solution here. Although even with one of those, behaviour would still be less efficient than 2.0.
> slightly disappointing that an accessibility feature regression ^^^^^^^^^^ Woops, didn't realise it was a regression. Increasing priority again :)
Cheers :) Just to clarify, functionally it's a regression from 2.0, but the 2.2 theme-manager was always designed to work this way AFAIK, hence some apparent confusion over whether it's a bug or an enhancement request...
the crux of the problem I believe is that the font specification was removed from the gtkrc files (since it overrides the Font capplet specification). That change occurred to make the fonts from the Themes consistent with what happenned in the Font capplet, it was bad for the user to find that, when using certain themes, the Font capplet "didn't work". but that leaves us with the problem that the themes which suggest fonts actually change the Font setting, i.e. if you go from the Theme capplet to the Font capplet you will see that the actual font size in use has been changed. That's consistent, but since this means that the only "default system font" there is has been changed, there's no clean way to revert. IOW, applying a suggested font changes your font pref and themes without suggested fonts don't have a way to revert. I am not sure this is the end of the world however, it's annoying, but realize that this is no more inconvenient that having to go to the Font capplet to set your font preferences in the first place (the original proposed solution which was deemed bad for low-vision users). To restate: at present if a user wants to apply a "large print" theme, s/he can do so with one click including the application of the large font. This is a convenience function without an Undo, which though perhaps not idea from a usability POV is still better than no convenience function at all. I am not ecstatic about it either, but it's worth keeping in mind that the current workarounds (e.g. don't apply the suggested font, or go to the FOnt capplet to revert) are pretty much what we'd have to do if the convenience feature weren't there. The existing compromise works for low-vision users since they mostly don't need to revert the font size back to "small/default" unless they turn on a screen magnifier or something like that.
This is "kinda sucky" but I really don't think it's a "stopper", lowering 'AP' priority to "AP3". Maybe usability folks or other folks feel strongly that it's broken, in which case the regular prio/severity field above might be upgraded.
Apologies for spam... marking as GNOMEVER2.3 so it appears on the official GNOME bug list :)
This is, by the way, not really a regression. Can we close this as WONTFIX? I don't see any way of addressing the issue without massive changes to the way we track the user's desktop settings.
Apologies for spam-- ensuring Sun a11y team are cc'ed on all current a11y bugs. Filter on "SUN A11Y SPAM" to ignore.
Still no change.
I don't see a way of addressing this issue unless we introduce some kind of cascading/tiered font configuration - as it stands, all we can do is 'replace' the font size(s) when selecting a LargePrint theme. This of course erases any memory of the previously-configured font sizes. But I don't see it as a major problem, frankly - if a user selects a 'LargePrint' theme and opts-in for the font size changes, I don't see the 'revert font size' behavior as anything but a convenience feature.
by the way - in the absence of new inspiration for a fix, I would vote closing as NOTABUG, on the basis of the logic that it's not a bug if "applying a font" setting replaces the previous font settings destructively. Alternatively, we could downgrade this to an RFE (severity==enhancement, priority==low), which IMO it is.
*** Bug 153249 has been marked as a duplicate of this bug. ***
Blah. I'm not thrilled by this, but I think Bill's last comment is basically right. I'd lean towards WONTFIX/CANTFIX, though. [The real right answer is comprehensive integration of a undo/redo framework, but if one ever gets written, I'm guessing this will get caught then.]
*** Bug 169108 has been marked as a duplicate of this bug. ***
*** Bug 324053 has been marked as a duplicate of this bug. ***
*** Bug 335527 has been marked as a duplicate of this bug. ***