Re: style->black and style->white

[Owen Taylor <otaylor redhat com>]

Bill Haneman <bill haneman sun com> writes:

> 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.

If you want good quality High Contrast themes, there is no 
alternative to providing a theme engine. If you compare 
 
 http://people.redhat.com/otaylor/gtk/screenshots/gtk12-highcontrast.png

  HighContrast GTK+-1.2 theme shipped with Red Hat 7.2/7.3. (Couple 
  hour hack based off of Raleigh.)

 http://people.redhat.com/otaylor/gtk/screenshots/gtk20-highcontrast.png

  Recent gnome-themes HighContrast theme

I think you'll see that the bevelling is just defective in the gtk20
version. This _isn't_ because of the use of style->black_gc, this
is because you need to draw a black line on the upper left, where
the default theme wants to draw a light color that contrasts with
the background.
 
> 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

I see virtually no use of white_gc or black_gc in GTK+ outside of
the themeable paint functions. (Note that these GC's are occasionally
used when some GC is needed for a purpose like drawing a pixmap, 
but the color doesn't matter)

I also suspect that most of the problems you are seeing aren't 
problems with white/black but rather problems with style->light_gc
or (for inverse themes) style->dark_gc not contrasting with
style->bg_gc.

> 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.

I don't think making black white and white black would be
a good idea. Look at gtkcolorsel.c for an example of a place 
where that would break code that currently properly worries
about contrast from the background.
 
> 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.

Yeah, we could make GTK+ look just like Motif-1.2. I'm sure that would
be _real_ popular :-). 

Regards,
                                        Owen