Re: style->black and style->white

[Bill Haneman <bill haneman sun com>]

On Tue, 2002-11-12 at 16:56, Owen Taylor wrote:
...

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

Perhaps; though dark_gc and light_gc could properly be based on a
heuristic including style->black and style->white.

I take your points; but there are still problems with applications that
use "black" and "white"; we need a way for applications to use "black"
and "white" in a semi-hard-coded manner that is nevertheless themed. 
Excuse the elementary question, but can a gtk-engine redefine
style->black and style->white?  If so then a new engine could do this
for us as well, yes.

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

OK, will look there.
  
> > 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 :-). 

Well, what I suggest above would have _no_effect_ on the default theme
since fg[NORMAL] == (0,0,0) and bg[NORMAL] == white.  That's why I
suggested it :-)

-Bill
 
> Regards,
>                                         Owen