Re: Themeable colors

В Втр, 29/03/2005 в 12:29 +0100, Bill Haneman пишет:
> >typedef enum {
> >
> maybe, but not appropriate to 'inverse' themes, for instance...
> No, definitely bad ;-)
> because this would encourage app writers to do something that basically is hard-coding colors.  What we need are more "semantically specified" colors.  
> So to extend the current notion of SELECTED, PRELIGHT, FG, BG, BASE, TEXT, we need other style names that indicate the context in which a color is to be used, but not its hue or value.
> - Bill
> >} GtkPaletteType;
> >
> >

Look for example - GtkSourceView syntax highlighting. There is _no_
symantics in usage of red color for #include directive in C. What color
will you choose? Prelight or selected of something like this can
intersect with background and embedded widgets. But any time you change
your theme you are managed to reselect those colors also. Spellcheck
uses red, but that can badly work for pink background.

GEdit is not the only example. Every time I change my theme or desktop
background the first thing that I do is open settings of multiload
applet and adjust every of more than 20 colors. There are sound editing
software, games, applets, graphs. All of them require to be themable but
now they just hardcode some default values.

The only sense of those colors is that they are distinguisable one from
another and from background/foreground/prelight. If you don't like color
names, you can just use PALETTE_1, PALETTE_2 and so on, but this doesn't
make life easier.

Even without those change applications are not accessible and use custom
color. Because they do need more colors than 4. They require exactly
red, exactly dark, exactly light. But they really can use colors that
more suitable for theme. 

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]