GNOME Bugzilla – Bug 734601
"use system colours" with Raleigh theme leads to black text on black background
Last modified: 2014-08-16 16:54:32 UTC
We've had various bug reports from non-GNOME users in Debian that are basically of the form "gnome-terminal doesn't work under XFCE" or "gnome-terminal doesn't draw any text under LXDE". On further investigation, it turns out that it does draw text in their environments, but that text is invisible, because it's black on a black background. The underlying bug is that if "use system colours" is enabled (as it is by default) and the theme is Raleigh (as it is by default in Gtk < 3.13 when gnome-settings-daemon is not running), gnome-terminal asks the theme "how should I draw a TerminalScreen widget?" and the answer it gets is "black text on a black background". Gtk 3.13 mitigates this by changing the default theme from Raleigh to Adwaita, but the Debian 8 freeze is fairly close to the 3.14 release date, so we might end up shipping 3.12 rather than 3.14 (I don't know what the GNOME team's plans are); also, if I understand correctly, Raleigh is still available under 3.13, just non-default. Some of the possible resolutions of Bug #721932 would also mitigate this by making "use system colours" not the default. I've written a patch which hard-codes black-on-white as a fallback if the theme's foreground and background colours both come out as black. Swapping the hard-coded fallback to white-on-black would be fine if Bug #721932 is going to be fixed (and I'd consider backporting a default colour scheme change from 3.14 into Debian, if desired), but it seems good for the terminal's appearance in non-GNOME environments to remain consistent with its normal GNOME appearance, whatever that happens to be.
Created attachment 283071 [details] [review] Don't allow the theme to set black-on-black Gtk 3.12's Raleigh theme (the default in non-GNOME environments) is rather minimal, and in particular results in the TerminalScreen widget being drawn in black-on-black whenever an application does not select other colours via ANSI escapes, which is rather hopeless for usability. Hard-code black-on-white (matching Adwaita) as a fallback. This affects users who meet all of these conditions: * run a desktop environment that does not set the Gtk theme via Xsettings (as gnome-settings-daemon does) * have not configured the Adwaita theme (or some other reasonably complete Gtk theme) in ~/.config/gtk-3.0/settings.ini * have left the "Use colors from system theme" preference enabled, as it is by default
So, isn't this a Raleigh bug then? I don't see any point working around in gnome-terminal rather than fixing the theme.
If someone can propose a change for Raleigh that would fix this, I'd be happy to backport that to Debian's Gtk 3.12 instead. As much as I'd like that change to be "replace Raleigh as the default with Adwaita" as was done in 3.13.x, that doesn't seem viable in the 3.12 stable-branch, where it would lead to a circular dependency between Gtk and gnome-themes-standard.
(In reply to comment #3) > If someone can propose a change for Raleigh that would fix this, I'd be happy > to backport that to Debian's Gtk 3.12 instead. You could at least file a bug against Raleigh (or reassign this one to them), thanks! :) As long as it's about backporting to Debian, I don't mind if you apply your patch to their gnome-terminal if that's the fastest and simplest way to quickly work around the issue. It's just that I personally don't find your approach suitable for mainstream inclusion.
(In reply to comment #1) > This affects users who meet all of these conditions: > > * run a desktop environment that does not set the Gtk theme via Xsettings > (as gnome-settings-daemon does) > * have not configured the Adwaita theme (or some other reasonably > complete Gtk theme) in ~/.config/gtk-3.0/settings.ini > * have left the "Use colors from system theme" preference enabled, > as it is by default IOW, configurations that are NOT supported. This is really a theme bug.