Symbolic Themable Colors
This is gnomebug:114355 and there is patch attached to it that implements this feature.
Right now we have the following symbolic colors in GtkStyle:
fg |
normal text foreground over bg (normal widget text, e.g. labels) |
bg |
normal background for widgets |
light |
light background for 3D effects. This color is private for default gtk theme and in even not initialized with other themes. So it would be better to remove it from public API. |
dark |
dark background for 3D effects. This color is private for default gtk theme and in even not initialized with other themes. So it would be better to remove it from public API. |
mid |
midtone background for 3D effects. This color is private for default gtk theme and in even not initialized with other themes. So it would be better to remove it from public API. |
text |
editable text foreground, used over base (labels, textview) |
base |
editable text background (labels, textview) |
text_aa |
FIXME: the comment in gtkstyle.h says "halfway between text/base", but there is no use of this in the GTK+ sources. This color is private for default gtk theme and in even not initialized with other themes. So it would be better to remove it from public API. |
See this mailing list thread: Themable colors
TommiKomulainen: maemo gtk+ has another implementation of symbolic or logical colors attached in the bug and also in the subversion repository (user: guest, pass: guest)
We need more symbolic colors
- Foreground for visited/unvisited links in hypertext
- Color for misspelled words (or the red squiggles in a word processor)
- Color for highlights (think of the highlighted current day in a calendar)
- Variants of the 'primary' fg/bg colors, for instance for tables with alternating row colors)
- Colors for warnings/errors ("warning", "error", for example)?
- A small palette of background colors, for example, for color-coded calendar entries, graphs (think automatic bar charts and the multiload applet), etc.
- An explicit color for borders/outlines? i.e. instead of hard-coded black
- Color for "no matches" background in a search entry, a la firefox (maybe this is included in the warnings/errors colors)
- Any others?
TimMuller: What about general-purpose secondary/tertiary foreground colours? This would be useful for applications that want to distinguish pieces of information by colour instead of style/size, like in this screenshot.
CallumMcKenzie: It would be nice if there were a reasonably large set of foreground colours distinguishable from each other and from the background colour - but without a specified use. The case I am particularly thinking of is the numbers in the game Mines where colour is an important cue. The hard-coded colours can easily loose contrast, especially on darker themes. These would not have to be distinguishable from the other colours, like link colours, with a specified use.
Things to consider
We probably want fg/bg pairs for some of the colors, where fg is the text foreground and bg is the background. The current pairs are (fg, bg) and (text, base) from the table above.
Right now the existing colors (fg, bg, text, etc.) all have variants for each GtkStateType (NORMAL, ACTIVE, PRELIGHT, SELECTED, INSENSITIVE). Do we need such variants for all the newly-defined colors? If so, it would be beneficial to extend the gtkrc syntax to allow for automatic variations:
visited_link[NORMAL] = "#aabbcc" visited_link[INSENSITIVE] = lighten(visited_link[NORMAL])
In any case, the GtkStyle documentation needs to be improved! Nothing says what the paired colors are, for example. And there should be some guidelines as to which colors should be 'readily distinguishable' from one another, outside of the obvious pairs, i.e. fg_1 should be distinguishable from fg_2, etc.
We want to be able to write a simple "color setting" control. How does that work ? One option would be a setting containing a palette, ie essentially a map from color names to rgb triplets.
How can themes adapt to the user-selected stock colors ? Do we add new rc file syntax:
fg[NORMAL] = stock-color("foreground")Do themes need to be able to derive new colors from the stock colors ? Do we need to parse color expressions like:
fg[NORMAL] = lerp(0.5, stock-color("foreground"), #ff00ff)How can themes mark themselves as being "recolorable" ? We probably want to disable the color setting control if the theme uses fixed colors.
Suggestion from Bill H: Regarding the user-editable color palette (bgs) used for bar graphs, etc., we might suggest a rule such as 'fg_color_<even>' should be used adjacent to 'fg_color_<odd>', etc. This would aid in the creation of visually appealling themes, and allow HighContrast themes to make use of a larger palette (which would otherwise be difficult for high contrast themes).
Auditing apps
We need to audit apps for proper use of the fg/bg pairs outlined above. We could create a theme which would make improperly-paired text be unreadable. For example, to detect the case where someone uses fg over base, we could make those nearly the same color in the theme. We already have a similar tool, a theme called "BlueThemeOfDeath" which can be used to detect apps which hard-code colors (all themed colors are set to RGB-8-bit=(0,0,255).
Auditing themes
Conversely, we need a way to audit themes. See the pages with the theme checklist and the NewDefaultTheme.