Re: style->black and style->white
- From: Owen Taylor <otaylor redhat com>
- To: Bill Haneman <bill haneman sun com>
- Cc: gtk-devel-list gnome org
- Subject: Re: style->black and style->white
- Date: Tue, 12 Nov 2002 13:53:18 -0500 (EST)
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]