GNOME Bugzilla – Bug 114355
Symbolic themable colors
Last modified: 2005-11-25 14:35:50 UTC
The ability to define named colors then refer to them from RC styles, is need for a couple of things: - A "color editing" theme GUI that is different from selection of the current theme. - Sharing colors via XSETTINGS with KDE, OpenOffice.org, etc. - Using colors in programs that are outside the normal GTK+ palette but should still be themable. You might want also to be able to specify functions of the named colors... 'darken(background)'
I don't know if they need to be named. At the moment I'm hardcoding red and blue into my program, but that'll suck if the gtk theme uses Red or blue. I think maybe 16 colours that match with the theme, but are distinguishable from the base gtk colours, and maybe lighter and darker sets of these colours too?
Yeah, I think any improvement in this area would be really useful, not least for custom widget authors. Being able to set one color to a function of another would definitely be nice. Functions for darkening and lightening -- and perhaps other common color operations, such as desaturating -- would be very cool, but perhaps most useful of all would be the identity function. If widgets used specialized, named colors instead of hard-coding the RGB values into the binary, a lot of useful hooks would be provided to theme authors. But if each of these special colors also defaulted to some sane value relative to a more generic named color, theme authors would not be required to specify each and every last color; they could ignore the colors for widgets they don't care about, or those for which the defaults work really well. However, I do suspect this is not in scope of what Owen is talking about. Nonetheless, it would be even cooler still if the corresponding thing could also be done to the style API. I'm talking about adding API for making custom drawing functions virtual for engines to override. For instance, a tetris game could use this to define a function `acmetris_draw_piece' and provide a default implementation that simply draws a vanilla tetris piece using the appropriate symbolic colors; a caring engine could then override it as necessary to make it fit in with the L&F. Likewise for all other widget parts that currently get no love from the `gtk_draw_*' functions. However, I don't know whether this is feasible in practice, let alone what the correct approach would be. I just know that the current lack of an equivalent facility keeps preventing me from doing what to me appears to be the Right Thing. Basically, what I have in mind is associating some sort of dynamic vtable of drawing functions to each GtkStyle (using signals?). Doing a vtable hash lookup (or signal emission) each time a widget fragment is to be drawn might kill performance, I have no idea; maybe this could be remedied by allowing the custom widgets to cache their style functions. Anyway, I'm getting way off-topic. Does anyone think opening a new bug for this would be worthwhile?
I think you are talking about a new theme system... there are some rough notes in: http://people.redhat.com/otaylor/guadec5/ But a long ways from anything concrete.
*** Bug 163428 has been marked as a duplicate of this bug. ***
Is it possible to plan this feature to 2.8?
The original motivation was to extend the "stock color" system to include things like - colors for unvisited/visited links in hypertext - nice pastel background colors for things like color-coded calendars - a way to get useful variants of the above, like "darken(some_color)" and "lighten(some_color)" for 3D effects. - something else which I forget. Having things like your proposed GTK_PALETTE_RED doesn't make much sense; if you want a specific color, just use it from your app: GdkColor c; c.red = 0xffff; c.green = c.blue = 0; gdk_gc_set_rgb_fg_color (my_gc, &c); gdk_draw_line (drawable, my_gc, ...); On the other hand, it would be good if "logical" colors like the ones above for links/color-coded backgrounds were configurable from themes.
The mailing list discussion is here: http://mail.gnome.org/archives/gtk-devel-list/2005-March/msg00187.html The wiki page to sketch this out is here: http://live.gnome.org/GTK_2b_2fSymbolicThemableColors
Created attachment 39678 [details] Tar.gz with patch and new files This is test patch to gtk-2.6.4 to look at new proposal
Created attachment 52121 [details] [review] maemo gtk+ logical colors implementation This patch is from maemo gtk+ and lets you define colors similar to following: style "my-colors" { logical_color["LinkTextColor"] = "#000000"; text[NORMAL] = "LinkTextColor" }
Created attachment 54881 [details] [review] Updated logical colors patch from maemo-gtk against HEAD Attached patch against HEAD removes the various free_object_list(), copy_object_list() functions and replaces them by code using g_slist_foreach(). Also generally cleaned up the patch a bit.
Created attachment 54882 [details] New file needed for above patch
Created attachment 54883 [details] New file needed for above patch The new files implement an internal object GtkHashTable which is nothing but a tiny GObject around GHashTable in order to get refcounting. I'm open to suggestions how to get a refcountable hash table without this.
a thread to solve the hash table reference counting has been started here: http://mail.gnome.org/archives/gtk-devel-list/2005-November/msg00093.html
My own proposal for this is here: http://mail.gnome.org/archives/gtk-devel-list/2005-June/msg00028.html I think the Maemo patch misses one important feature compared to my patch, being able to specify symbolic colors in a setting. That is necessary to enable a "color scheme" capplet.
Very good point :) But your proposal doesn't make the colors themeable on a per-widget basis, which is needed for themeable widget-specific colors (like the color coded calendar example mentioned above). IMHO the concepts from the two patches should be merged somehow. Perhaps by searching the settings-set color hash first and then falling back to the style-based list of color hashes. This way full theme configurability would be preserved and the desktop-wide color scheme from XSETTINGS would simply override the "standard" colors.
Probably makes sense. Note that my patch provides another nice feature, namely color-expressions that can be used when assigning colors in rc files. When trying to find the value for a symbolic color for a widget, we probably need to first check the widget-specific style, and then fall back to the global setting, right ? When going this way, there should probably be a color expression that allow to refer to the "global" symbolic color, so that they can be tweaked on a per-widget basis, like logical_color["LinkTextColor"] = darker("LinkTextColor");
Um, right it needs to check the global setting last of course. I also wonder what the "logical_" prefix is good for. color["LinkTextColor"] = darker("LinkTextColor"); would work just as well i guess.
Created attachment 55097 [details] [review] maemo patch merged with matthias' patch Updated merged patch gets rid of GtkHashTable because we have g_hash_table-ref/unref() now. It uses the GtkSettings property and the nice @ syntax and the color expressions from matthias' patch and the per-style color hash of colors from maemo. The syntax is now for example: (from patched tests/testgtkrc) style "red-bar-parent" { color["my-red"] = "red" color["my-other-red"] = { 0.95, .55, 0.55 } } style "red-bar" = "red-bar-parent" { color["my-light-red"] = lighter (lighter (@my-red)) bg[PRELIGHT] = @my-light-red }
You need to bump the GLib requirement in configure.in to 2.9.1 for the hash table refcounting functions. gtk_style_lookup_color should be marked as a 2.10 API addition and added to the docs. We will also need to describe the new symbolic color possibilities in the docs, but that can probably wait until the patch has landed. It would be nice if we could avoid the use of GTK_[RC]_STYLE_GET_PRIVATE() in some places, but its probably not worth reshuffling the private parts of GtkStyle/GtkRcStyle to make room for a private pointer.
Fixed in CVS. I don't think that shuffling around members to make room for the new pointers in GtkStyle/GtkRcStyle is possible. 2005-11-23 Michael Natterer <mitch@imendio.com> Added symbolic themable colors. Patch is a merged version of proposals from Matthias and maemo-gtk. Fixes bug #114355. * configure.in: require glib >= 2.9.1 for refcountable hashtables. * gtk/gtksettings.c: added property "color-scheme" which is a string defining colors like "foreground:black\nbackground:grey". Automatically provide a name->GdkColor hash table mapping for the color scheme. * gtk/gtkrc.[ch]: added list of color hashes that works like the list of icon factories. Append the color scheme hash from GtkSettings if it exists. Extended gtkrc syntax to allow defining and referencing of logical colors. Also allow to modulate colors in gtkrc by using arbitrary expressions of mix(), shade(), lighter() and darker(). Added internal function _gtk_rc_style_get_color_hashes(). * gtk/gtkstyle.[ch]: keep a private list of color hashes around. Get the list from _gtk_rc_style_get_color_hashes(). Export internal function _gtk_style_shade() (used by above color expressions). Added public API gtk_style_lookup_color() which looks up a logical color by name. * gtk/gtk.symbols: add gtk_style_lookup_color * tests/testgtkrc: use symbolic colors for making the scrollbars red.