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 618888 - support for accessibility theming
support for accessibility theming
Status: RESOLVED DUPLICATE of bug 740447
Product: gnome-shell
Classification: Core
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
: 673417 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2010-05-17 15:54 UTC by Dan Winship
Modified: 2014-11-29 17:17 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Dan Winship 2010-05-17 15:54:36 UTC
In theory, we can support accessibility themes by loading additional CSS files. However:

    - We need to write the relevant CSS
    - We need to figure out how that CSS gets loaded automatically
    - We will most likely need to do some work to support large font themes
      without the layout breaking horribly
Comment 1 Alejandro Piñeiro Iglesias (IRC: infapi00) 2011-06-13 17:30:28 UTC
During these days, desktop-devel-list held a really long thread (sorry, I couldn't read all those mails, most of them were really diffuse). But it seems that Owen Taylor tried to summarize the situation, and propose some solutions:

https://mail.gnome.org/archives/gnome-shell-list/2011-June/msg00164.html

And, as far as I understand that mail, it seems that themes would be a official non-supported feature, managed via extensions.

How this conclusion affects accessibility themes (so this bug)? Will accessibility themes be a extension that users would require to install from this hypothetical extension website?

BTW. We listed this bug on the accessibility 3.2 nice to haves:

https://live.gnome.org/Accessibility/ThreePointTwo/NiceToHaves#GNOME_Shell

But, as far as I see, there isn't any plan to really work on that. Right?
Comment 2 Dan Winship 2011-06-13 18:36:35 UTC
We've been calling them "accessibility themes" out of habit, because that was how they worked in GNOME 2.x, but the GNOME Shell high/low/reverse contrast support would not actually be a "theme" in the sense that was being discussed on gnome-shell-list. It would be maintained as part of the shell.

And there is not currently anyone working on this.
Comment 3 Joanmarie Diggs (IRC: joanie) 2012-05-09 23:37:23 UTC
*** Bug 673417 has been marked as a duplicate of this bug. ***
Comment 4 Joanmarie Diggs (IRC: joanie) 2012-05-10 13:06:22 UTC
(from bug 673417 comment #12)
 
> Themes is just a possible technical solution to the problem I have. I need a
> good readable desktop. If this will be achieved by themes, fine with me.
> Another technical solution would be to allow the user to select foreground and
> background colour of the shell. Maybe there are other possible solutions.
Comment 5 W. Martin Borgert 2012-05-11 23:59:03 UTC
There is an related point, but I should probably file a separate bug about this: Currently, the shell and other windows look totally different (shell: white on black, other windows: black on white). This inconsistent look reminds me of the good old times with Athena, Openlook and Motif GUIs. Shall I file another bug for the inconsistency problem?
Comment 6 Owen Taylor 2012-05-12 00:00:08 UTC
(In reply to comment #5)
> There is an related point, but I should probably file a separate bug about
> this: Currently, the shell and other windows look totally different (shell:
> white on black, other windows: black on white). This inconsistent look reminds
> me of the good old times with Athena, Openlook and Motif GUIs. Shall I file
> another bug for the inconsistency problem?

No - this is as designed by the GNOME design team and artists.
Comment 7 W. Martin Borgert 2012-05-12 00:21:27 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > There is an related point, but I should probably file a separate bug about
> > this: Currently, the shell and other windows look totally different (shell:
> > white on black, other windows: black on white). This inconsistent look reminds
> > me of the good old times with Athena, Openlook and Motif GUIs. Shall I file
> > another bug for the inconsistency problem?
>
> No - this is as designed by the GNOME design team and artists.

Uh, the inconsistent look between shell and other applications is on purpose? Could you point me to a design document or some explication why it should be that way? Other then nostalgia for the good old Athena+Openlook+Motif times :~)
Comment 8 Owen Taylor 2012-05-12 00:52:47 UTC
(In reply to comment #7)

> Uh, the inconsistent look between shell and other applications is on purpose?
> Could you point me to a design document or some explication why it should be
> that way? Other then nostalgia for the good old Athena+Openlook+Motif times :~)

The idea is not iconsistent appearances, but coordinated but different appearances. There are basically three different UI looks within GNOME

 - System (GNOME Shell)
 - Normal application
 - Content viewer application (Videos, Photos, etc) - we use a light-on-dark appearance to avoid distracting from the content

In terms of System versus application it's like the inside of a book and the cover of a book - you expect common visual elements, but it will have different colors, different font size, etc.

You can disagree with the premise or you can disagree with the implementation, but the premise is not something that we consider a bug, and the bugs in the implementation - the design of coordinated looks - is something that would have to be addressed in separate bugs for particular issues with detailed suggestions.
Comment 9 W. Martin Borgert 2012-05-12 09:57:45 UTC
(In reply to comment #8)
> You can disagree with the premise or you can disagree with the implementation,
> but the premise is not something that we consider a bug, and the bugs in the
> implementation - the design of coordinated looks - is something that would have
> to be addressed in separate bugs for particular issues with detailed
> suggestions.

Owen, many thanks for the explanation! While I'm not yet sure whether or not I agree with the general idea, I believe I at least understand it now :~)

My problem is, that the white-on-black text in both shell and "dark theme" is hard to read for me. It would be nice to have at least a switch to allow for a readable black-on-white theme (like the default look GNOME2, which is maybe not so fashionable, but readable for my old eyes) for both shell and all applications.
Comment 10 Jasper St. Pierre (not reading bugmail) 2012-05-12 15:53:26 UTC
That's going to be covered by the magnifier (with an Invert Lightness feature), or with a separate accessibility theme.
Comment 11 W. Martin Borgert 2012-05-12 18:03:55 UTC
(In reply to comment #10)
> That's going to be covered by the magnifier (with an Invert Lightness feature),

I'm not sure whether the problem of the hard-to-read white on black text is related to a magnifier. Or I did not yet understand the meaning of a magnifier in the GNOME3 context. Inverting is probably not useful, because it would invert the black on white text as well, right?

> or with a separate accessibility theme.

Are there already plans to include such a theme for a specific release, e.g. 3.6?
Comment 12 Florian Müllner 2014-11-29 17:17:56 UTC

*** This bug has been marked as a duplicate of bug 740447 ***