Re: style->black and style->white

[Owen Taylor <otaylor redhat com>]

Bill Haneman <bill haneman sun com> writes:

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

It _could_, but I really wouldn't suggest it.

> > > 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 :-)

I think you are thinking of text[NORMAP], base[NORMAL] (the colors
used for entries) which are black and white in the default 
color scheme. 

(But could easily be beige and brown in a different color scheme. It's
a mistake to assume that there is any connection between fg/bg and
base/text.... one could be inverted and the other not.)

bg[NORMAL] is typically gray.

Regards,
                                        Owen