GNOME Bugzilla – Bug 168977
Most of the accessibility icon themes should be hidden in the theme manager
Last modified: 2005-06-08 08:53:49 UTC
gnome-themes installs a large number of accessibility icon themes: HighContrast HighContrastInverse HighContrastLargePrint HighContrastLargePrintInverse LargePrint LowContrast LowContrastLargePrint (about half of the available icon themes on my system) It would be nice if this could be reduced, to simplify things in the theme manager. Having different icon theme names for different icon sizes doesn't make sense, since a the icon sizes come from the GTK theme, and icon themes can store multiple sizes of each icon. So having both normal and LargePrint theme variants is redundant. I realise that removing the themes outright is out of the question, since it would cause problems for people who have those themes selected. Hiding the said themes would be a good compromise so that users don't accidentally select them. Once the patch on bug 168348 is applied, this should be possible by adding a line "Hidden=true" to those icon themes' index.theme files (adding the line right now won't break anything, but won't have a noticable effect at the moment). The themes that could do with hiding are: LargePrint (-> gnome) HighContrastLargePrint (-> HighContrast) HighContrastLargePrintInverse (-> HighContrastInverse) LowContrastLargePrint (-> LowContrast)
Created attachment 38187 [details] [review] Patch to solve the problem
The patch is for not showing LargePrint, HighContrastLargePrint, HighContrastLargePrintInverse and LowContrastLargePrint icon themes.
The patch will be effective only when patch for bug #168348 is applied.
Cc'ing Bill for comments on this one... IIRC it was pretty hard to work to get to the compromise in the first place of showing only the high contrast themes in the main theme manager dialog (unless you throw the gnome-themes compile time switch that shows them all), but showing all of them in the details dialog.
I agree - it's very important to keep these icon themes in the details dialog. The patch would prevent users who need them from accessing the icon themes. I think this is NOTABUG.
I do agree that it would be nice to be able to get rid of the large print variations from all the lists, though, and just have a "Large Print" checkbox somewhere (preferably in the theme capplet, but maybe just the font capplet) that allowed you to switch between regular and large print for any theme... but we've had all those discussions before, and the control center maintainers were pretty resistant at the time.
I am referring to the icon themes only. Not the "meta themes" displayed in the main dialog. The change I suggested would only affect what is displayed in the "icons" page of the "theme details" dialog. For example, the HighContrast and HighContrastLargePrint "meta themes" should share the same icon theme. So one of the HighContrast and HighContrastLargePrint icon themes could be deprecated and hidden from the theme manager dialog.
Understood... was really just commenting that the proposed fix probably isn't really getting to the root of the problem. You're quite right though... the large print themes do just use all of the regular theme's icons, so right now a user will see no difference if they switch between the regular and large print versions of the same theme in the Icons tab. And if we ever do want them different, different-sized icons in the same icon theme would be a better way to do it, rather than installing a separate large print icon theme. So I'd be happy to accept the patch if Bill agrees (post 2.10 of course).
Well, I'd say the root problem is that these redundant themes exist :) I can't see why you'd want the LargePrint themes to have visually distinct icons. If we have larger versions of the icons, we may as well make them available to the normal print users too, in case an app asks for an icon of that size. Of course, removing them outright would cause problems -- people using those themes would revert to the default theme on upgrade (and people using the a11y themes are more likely to have problems with such a theme change than other users). The alternative is to deprecate those icon themes. They'd essentially be empty, but marked as hidden, and inheriting from the non-deprecated theme (any icons remaining in the deprecated theme would be moved). This would keep existing users happy, while removing some cruft from the user interface.
I'd vote for removing the redundant icon themes, as long as the 'meta themes' still work (i.e. point to the same member of the formerly-redundant pair). If a user has configured a 'custom theme' which uses a mix and match of Large icon themes and other stuff for the window or widget themes, then I think it may be OK to have a little fixup on upgrade. However, I think that if we did this, it would make the most sense to provide a "size" radiobutton group in the icon theme page-tab, so that a user could select any icon theme and have it sized to their needs. This is I think what the user really wants, i.e. it's nicer to make 'size' and 'icon set' two axes instead of one, while putting them both in the 'icon theme' page tab.
I think removing the icon themes outright would cause upgrade problems. From a quick look at the theme control panel code and what is stored in gconf, it seems that while you can select a "meta theme" the control panel actually writes three keys (selected GTK theme, icon theme and metacity theme). When you start the theme control panel, it checks to see if the selected themes correspond to any meta theme and selects that theme if it exists (otherwise it adds a "Custom theme" entry). So removing the theme and updating the meta-theme would not actually migrate users to the non-deprecated theme (they'd need to reselect their theme to update). That's why I've only been suggesting that the themes get hidden, rather than removed. On the subject of letting users pick an arbitrary icon size for a theme, that would also be quite useful. I'm not sure how it would be implemented with the current theming APIs, so it might be worth finding what's needed before the next GTK freeze (this is getting off track from the original bug report though).
Ok, I've applied the 'hidden' patch to HEAD for now, but will leave this bug open until bug #168348 is resolved.
This seems to be working in 2.11 now. If I look at the icons tab of the "Theme Details" dialog, the only a11y themes that are listed are: HighContrast HighContrastInverse LowContrast So I guess the patch is working, so I am marking the bug fixed.