[Users] [Bug 4465] New: Pref. "Enable coloration of message text" should respect GTK+ theme colors
Chris
claws at chris.oldnest.ca
Tue Mar 30 22:22:51 CEST 2021
Hi there,
On Tue, 30 Mar 2021 10:28:25 +0200
wwp <wwp at claws-mail.org> wrote:
> Simply because coloring text in message view is done according to
> semantic attributes that are not at all proposed by GTK theming, it's
> not even the role of GTK styles in fact which proposes few basic
> styles attributes (for foreground and background, and for each both:
> highlighted, selected, normal, etc.).
Thanks for the explanation. I must admit some confusion remains,
though...
I would expect that set of basic style attributes to include a
de-emphasis style (like you'd use for "greyed-out" options), and
hopefully also general color definitions like "text (red) =
<hex-code>". But as I say, I am no GTK expert... I was making a(n)
(semi-)educated guess, informed largely by the table of values defined
at the Solarized color scheme website here:
https://ethanschoonover.com/solarized/#the-values
(which I realize is in no way a GTK reference).
If there's no notion of de-emphasized text in GTK, does the engine
support deriving colors from the ones it *does* provide?
Because if we can ask GTK for, say, an 85/15 merge of the normal font
color with the background color, the resulting reduced-contrast font
color would make a "theme-safe" sane default for blockquotes.
> Is there a GTK text style for quotes level 1, 2 and 3? For signatures?
> There's probably one for URI, but for all different patch lines types?
To be fair, I believe the Claws defaults make no distinction among the
three quote levels as it is. Defaulting to GTK's de-emphasized text
style for all three levels of quote AND for signature would give a
result that's a bit plain but never unreadably broken (unless the user
chooses to apply an unreadably broken GTK theme, of course).
Even if we stop there and leave the inline patch handling with its
static pre-defined defaults, very nearly all users will see quoted
text, URIs, and signatures in their day-to-day email use. That change
alone would pretty effectively prevent the outcome "all I did was apply
a desktop color theme and Claws suddenly rendered half of my email
unreadable", which seems like a real improvement, no?
Then, *if* GTK justifies my optimism, and themes *do* define general
color-coding terms like "red", "green", and "magenta" for content text,
Claws could use those to set theme-appropriate defaults for the patch
line types and folder list highlight colors, thus neatly solving the
whole problem. (And if GTK doesn't provide that, why the heck not?! ...
If that's the case I may have to go pester those folks too.)
> You can see now that talking about GTK theming/style there is not
> relevant.
My counterpoint to this is that nothing was broken until I applied a
dark GTK theme to my DE, then suddenly a significant proportion of
content text in Claws Mail — and only Claws Mail — was unreadable.
(Specifically, all quoted text). Given that the problem arises at
precisely the intersection of Claws Mail with the GTK theme, I maintain
that talking about GTK theming here is absolutely relevant. It may well
be that I'm making overly optimistic assumptions, and that retrieving
sufficiently general attributes from the GTK theme isn't a viable
avenue to solve the problem, but... there *is* a problem, and the
problem falls squarely within the scope of "GTK themes, Claws Mail, and
the interaction between the two".
> For sure, you'd need to set those colors up to something
> that matches your theme if you want to use them, if default colors
> don't match your theme (although they probably do if you theme color
> is plain classic).
Currently, yes, that is what I had to do. I pasted in the hex codes
from the Solarized website and everything is lookin' fine now. I just
find it quite surprising and a little frustrating that basic notions
like "text (de-emphasized)" and "text (green)" are apparently beyond
GTK's capabilities. Isn't the whole point of the toolkit's theme
support supposed to be that the user *doesn't* have to set these things
manually, one by one, program by program?
Cheers!
-Chris
More information about the Users
mailing list