GNOME Bugzilla – Bug 684311
Please restore HighContrastInverse & LowContrast themes for 3.6
Last modified: 2012-09-24 22:36:15 UTC
Ubuntu 12.10 is shipping most of GNOME 3.6 but we're sticking with gnome-control-center 3.4 partly because we're waiting until 13.04 for the ibus transition. GNOME Control Center 3.4 still needs the HighContrastInverse & LowContrast themes. Those were dropped without announcement or freeze exception over 2 weeks after the Feature Freeze (Aug 20). https://live.gnome.org/ThreePointFive As far as I'm aware, keeping those themes in gnome-themes-standard until 3.7 shouldn't hurt anything except making the tarball a little bigger.
(In reply to comment #0) > Ubuntu 12.10 is shipping most of GNOME 3.6 but we're sticking with > gnome-control-center 3.4 partly because we're waiting until 13.04 for the ibus > transition. > > GNOME Control Center 3.4 still needs the HighContrastInverse & LowContrast > themes. Those were dropped without announcement or freeze exception over 2 > weeks after the Feature Freeze (Aug 20). > https://live.gnome.org/ThreePointFive This is not completely correct; they were removed because of this 3.5 feature [1], in particular in preparation for bug 676814 which is on the list of bugs targeting such a feature. > As far as I'm aware, keeping those themes in gnome-themes-standard until 3.7 > shouldn't hurt anything except making the tarball a little bigger. Except that the LowContrast theme have been completely broken for a long time, and the HighContrastInverse theme doesn't include any icons. My take on this is if you want to support mixed versions of core GNOME components (such as 3.4 control center with 3.6 Shell and 3.6 gnome-themes-standard), you will also need to adjust/patch them so they make sense together. I think you should patch gnome-control-center to remove those items from the combobox, or ship those themes in a separate package if you really want. [1] https://live.gnome.org/ThreePointFive/Features/LightnessBrightnessContrastEffects
> or ship those themes in a separate package if you really want. That would be my recommendation as well.
I don't see how removing the ability to easily set the LowContrast and HighContrast themes in System Settings means that the themes actually need to be dropped. The bigger problem isn't that Ubuntu shouldn't be mixing GNOME components from different cycles (which is a problem! and I've been pushing hard on the Ubuntu side since 3.1 for us to ship as much of the latest GNOME as we can), but that GNOME developers need to respect their own freezes. It seems clear to me that this was a feature freeze break because it suddenly requires Ubuntu packagers to do extra patching if we want gnome-themes-standard 3.5.92 when 3.5.91 works just fine. Even the HighContrastInverse theme works just as well now as it did for GNOME 3.4. After "the Freeze" is not the time to be doing removal of old, unused code, especially if it's only just now getting deprecated.
(In reply to comment #3) > I don't see how removing the ability to easily set the LowContrast and > HighContrast themes in System Settings means that the themes actually need to > be dropped. What's the point of shipping a theme the user has no way to set then? (gsettings or the tweak tool are not good answers here IMO). > The bigger problem isn't that Ubuntu shouldn't be mixing GNOME components from > different cycles (which is a problem! and I've been pushing hard on the Ubuntu > side since 3.1 for us to ship as much of the latest GNOME as we can), but that > GNOME developers need to respect their own freezes. How would things change for Ubuntu wrt. this bug if these themes were removed in 3.5.90 or 3.5.91? > It seems clear to me that this was a feature freeze break because it suddenly > requires Ubuntu packagers to do extra patching if we want gnome-themes-standard > 3.5.92 when 3.5.91 works just fine. Even the HighContrastInverse theme works > just as well now as it did for GNOME 3.4. After "the Freeze" is not the time to > be doing removal of old, unused code, especially if it's only just now getting > deprecated. It only requires Ubuntu packagers to do such an extra patching work because you're using a different version of gnome-control-center... I think having two ways of setting a inverse high contrast or low contrast theming, one of which (gsettings) is undocumented/unsupported, is bad from the user perspective, and I don't want to have people filing bugs about deprecated or unmaintained features in this fast-changing module.
> How would things change for Ubuntu wrt. this bug if these themes were removed > in 3.5.90 or 3.5.91? Dropping those themes in 3.5.90 or earlier would have been ok because it wouldn't have broken the Freeze. > It only requires Ubuntu packagers to do such an extra patching work because > you're using a different version of gnome-control-center... > > I think having two ways of setting a inverse high contrast or low contrast > theming, one of which (gsettings) is undocumented/unsupported, is bad from the > user perspective, and I don't want to have people filing bugs about deprecated > or unmaintained features in this fast-changing module. Well, if you don't really want to support setting those themes in gsettings or Tweak Tool, then just close those bugs if they are filed. FTR, I'm not happy about us not using gnome-control-center 3.6 by default either but the main blocker was the risky ibus transition.
(In reply to comment #5) > > How would things change for Ubuntu wrt. this bug if these themes were removed > > in 3.5.90 or 3.5.91? > > Dropping those themes in 3.5.90 or earlier would have been ok because it > wouldn't have broken the Freeze. I'm not of the opinion that constituted a freeze break, but my question was more practical, i.e. I still don't see how doing that in 3.5.90 or earlier would have changed anything for you wrt. this specific bug (except the timing of when the patching on your side needs to be applied). > Well, if you don't really want to support setting those themes in gsettings or > Tweak Tool, then just close those bugs if they are filed. Yeah, or avoid shipping those themes in the first place :) > FTR, I'm not happy about us not using gnome-control-center 3.6 by default > either but the main blocker was the risky ibus transition. I understand, and I am sorry that this removal caused or will cause extra work for you, but I don't think it's a smart choice to put them back in gnome-themes-standard at this point.
> I'm not of the opinion that constituted a freeze break, but my question was > more practical, i.e. I still don't see how doing that in 3.5.90 or earlier > would have changed anything for you wrt. this specific bug (except the timing > of when the patching on your side needs to be applied). We are only 48 hours away from Ubuntu's Beta 2 Freeze. How is dropping a feature after FeatureFreeze not a freeze break? Bugfixes don't require packagers or distributions to scramble to find a workaround; feature freeze breaks can have that effect.
(In reply to comment #7) > We are only 48 hours away from Ubuntu's Beta 2 Freeze. > > How is dropping a feature after FeatureFreeze not a freeze break? Bugfixes > don't require packagers or distributions to scramble to find a workaround; > feature freeze breaks can have that effect. Because the feature was actually removed when the control center panel was changed. I'm of the opinion that the fact those themes used to live in gnome-themes-standard is not much more than an implementation detail - and yes, it was a mistake not to remove them at the time the control center panel was changed (also, I had the OK of a release-team member before removing them). Please let me know if I can provide further assistance with the control center or anything else wrt. splitting those themes in a separate package, but I am going to close this as WONTFIX.
While the new features in clutter/gnome-shell/gnome-control-centre are great, the removed themes are used in Gnome-panel (fallback mode?), XFCE, LXDE, Gtk apps under KDE, Compiz (e.g. Unity), Pure Metacity (Ubuntu Installer). All of those != gnome-shell environments were benefiting from those themes (even with the bugs they had). Please consider reintroducing these themes as a separate tarball, or not installing them by default. 2012 is the year of Gnome accessibility, dropping a11y themes doesn't seem like a step forward as a GNOME project movement. Please don't look at this as an item on the Gnome Shell road map, please consider a11y on more general terms. There are very little a11y themes available out there. And many people rely on those you used to provide.
> dropping a11y themes doesn't seem like a step forward as a GNOME project movement Dropping low-quality, buggy themes and polishing the one that is still there is in fact a major step forward. Instead of 3 unusably bad a11y themes, we now have one that is more than decent.
(In reply to comment #9) > While the new features in clutter/gnome-shell/gnome-control-centre are great, > the removed themes are used in Gnome-panel (fallback mode?), XFCE, LXDE, Gtk > apps under KDE, Compiz (e.g. Unity), Pure Metacity (Ubuntu Installer). All of > those != gnome-shell environments were benefiting from those themes (even with > the bugs they had). > > Please consider reintroducing these themes as a separate tarball, or not > installing them by default. > > 2012 is the year of Gnome accessibility, dropping a11y themes doesn't seem like > a step forward as a GNOME project movement. Please don't look at this as an > item on the Gnome Shell road map, please consider a11y on more general terms. > There are very little a11y themes available out there. And many people rely on > those you used to provide. Please don't spread FUD like that...to be clear, we're not just "dropping a11y themes". We put a lot of effort in the HighContrast theme and icons, and removing the HighContrastInverse and LowContrast themes is actually part of the plan to improve the general quality of a11y support, as explained in the feature page mentioned in comment #1. As for your concerns: - fallback mode has no guaranteed feature parity with the standard experience - if people that use other desktop environments are still interested in using those themes as a compatibility layer, despite their low quality, they can step up and offer to maintain them in a separate module or separate tarball. I don't see the point of me maintaining a set of themes that it's not possible for the user to choose in GNOME If it helps, the best I can do is offer to release them standalone, in the state they were before they were removed, in a one-off tarball.
I am, frankly, completely offended by the insinuation that we don't care about a11y or universal access. I have personally championed this issue for many years. We have made improvements all over the stack - from the toolkit to the system settings. And this very cycle Cosimo and I spent a *significant* amount of time revamping and improving the high contrast theme. We did not continue this effort to include the low and inverse themes precisely for the reason that they were to be made obsolete by the compositor effects. I personally had a discussion with the a11y team on this very matter. They strongly preferred the use of the compositor effects to the low quality static themes. The fact that this comes as a surprise is strange considering it has been part of the roadmap all cycle: https://live.gnome.org/ThreePointFive/Features/LightnessBrightnessContrastEffects We do not consider *fallback* mode to be maintained at feature parity with the standard GNOME 3 experience. It is a fallback when things are broken. It has been that from the start. If you are advertising it in your product as something other than a fallback you should reconsider that. To the purpose of this module (gnome-themes-standard), it was named as such because it is not intended to be used as a meta-module for themes. It is to hold the *standard* themes used by GNOME 3. It makes no sense to continue to host themes that are unused and unmaintained. All of those non GNOME 3 environments that would like to maintain the themes should probably take the code and maintain the themes then. It is up to them to decide whether they care about universal access or not. What should not be in doubt is that GNOME 3.6 will have dramatically improved accessibility.
Thank you for addressing my concerns. Sorry for sounding aggressive. Your work is highly appreciated.