After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 788690 - HighContrastInverse theme is not selectable anywhere in GNOME (frontend)
HighContrastInverse theme is not selectable anywhere in GNOME (frontend)
Status: RESOLVED FIXED
Product: gnome-tweak-tool
Classification: Applications
Component: general
3.26.x
Other Linux
: Normal normal
: ---
Assigned To: GNOME Tweak Tool maintainer(s)
GNOME Tweak Tool maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2017-10-08 22:15 UTC by Daniel Boles
Modified: 2017-11-05 13:35 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Daniel Boles 2017-10-08 22:15:45 UTC
This may end up in a totally different product, but it seems best to start here.


There's a popular idea that HighContrastInverse has been dropped, but that was only the GTK+ 2 theme.

In GTK+ 3, HighContrastInverse is generated from the same SASS as HC and is nearly totally identical, aside from the obvious of colours being inverted.

It's a nice theme, which provides high contrast but with the perk of not dazzling the user with pure white at all times - something I appreciate. More importantly than my sense of aesthetics - I'm sure the availability of a very dark theme is important for some users with specific sight requirements. For both reasons, I've tried to give it extra attention with my recent bugfixes.


Yet GNOME does not seem to provide any way to get to HCI. It doesn't show in Tweaks, either because it's a variant or it has no GTK+ 2 folder. And because its variant name is Inverse, the global dark theme setting doesn't switch to it.

An accessible theme should be... accessible. As in, capable of choosing it without needing to navigate the maze of dconf, or use an environment variable, the Inspector, custom theme with import from GResource, etc.


My first thought was to implement this as the :dark variant of HighContrast, and I'm curious why it wasn't that way already?

Anyway, it's pretty clear we don't want to go that route: the global dark theme setting is going away, to be replaced by a proper first-class theme. But for that to work for HCI, it'll presumably need its own directory to be installed.

So, it seems like something needs to be done either way to make HCI more easy for a user to select, without having to be aware of all the underlying settings.
Comment 1 Matthias Clasen 2017-10-09 02:54:24 UTC
When I discussed this theme with Jakub, we felt it was more of a separate theme than a dark variant.
Comment 2 Daniel Boles 2017-10-09 10:10:23 UTC
I guess that distinction won't matter much soon, if variants are going to become first-class themes, as is my understanding.

It seems to be gnome-themes-standard that installs theme folders in /usr/share/themes, not GTK+. Could we install a placeholder to make Tweaks show this and maybe just make GTK+ 2 use some other theme (that wouldn't clash *too* badly)?
Comment 3 Matthias Clasen 2017-10-26 05:04:37 UTC
not a gtk bug
Comment 4 Daniel Boles 2017-11-05 11:15:00 UTC
Given that Tweaks just stopped requiring a GTK+ 2 theme folder, I guess this is not really gnome-themes-standard's problem anymore.

More to the point, Tweaks just added in Adwaita and HighContrast (light) as hard-coded options. Shouldn't we also add HighContrastInverse to that list? At least for as long as it's conceptually considered a distinct theme, i.e. not the dark variant of HC (which it pretty clearly is, in practice).
Comment 5 Jeremy Bicha 2017-11-05 12:52:04 UTC
I reassigned this to gnome-tweak-tool and am closing this bug since this is now fixed in gnome-tweak-tool in master and the gnome-3-26 branch. I may do a gnome-tweak-tool 3.26.4 release later.
Comment 6 Daniel Boles 2017-11-05 13:35:10 UTC
Thanks a lot!