style->black and style->white

[Bill Haneman <bill haneman sun com>]

Hi:

If you run one of the "inverse" themes (i.e. HighContrastInverse or
HighContrastLargePrintInverse) from gnome-themes, you will notice that
readability is negatively affected by the fact that gtk+ tends to draw
"black" borders and lines (and in some case "white" lines as well) when
it outlines widgets, draws bevels, and the like.  This is especially
troublesome with things like drop-down menus, button borders, WM borders
in most Metacity themes... since you end up with black outlines around
widgets/windows that are already black.

I see two main solutions to this problem that would work for the
existing GTK+ and Metacity themes (uglier hacks are of course also
possible);

1) make gtk+ use fg/bg colors from gtkstyle when drawing these lines and
bevels, or

2) add API to our RC files and xsettings so that the style->black and
style->white colors can be respecified.  ("black" and "white" are
already style-dependent, but there appears to be no themeable API for
setting these values).

I think #2 is less likely to conflict with existing themes; basically
only "atypical" themes like the inverse ones and low-contrast ones would
want to redefine "black" and "white" anyhow.  It would also allow
applications that want to draw in "white" and "black" to do so in an
accessibility-compatible way (i.e. black is always black unless you are
running a "special" theme which requires it to be something else).  This
would for instance help sort out the problem of "theming" print
previews, where application designers reasonably want "black" text on
"white" paper regardless of the "theme" colors, but accessibility
requirements seem to conflict; apps can use "black" and "white" from the
GtkStyle and know that they will get "true black" and "true white"
pixels except when a theme explicitly redefines them.

Alternatively we could just ask GTK+ to draw bevels and borders in
fg[NORMAL] where they currently use black, and bg[NORMAL] where they
currently use white.

Which approach seems better?  And can we get this in for 2.2 please?  I
would be happy to provide a patch for either solution.  (I will file
bugs when I can reach bugzilla again).

best regards,

Bill