After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 114355 - Symbolic themable colors
Symbolic themable colors
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: Other
2.2.x
Other All
: Normal enhancement
: Medium API
Assigned To: gtk-bugs
gtk-bugs
: 163428 (view as bug list)
Depends on:
Blocks: 113649
 
 
Reported: 2003-06-03 16:46 UTC by Owen Taylor
Modified: 2005-11-25 14:35 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Tar.gz with patch and new files (9.63 KB, application/x-compressed-tar)
2005-04-04 15:28 UTC, Nickolay V. Shmyrev
  Details
maemo gtk+ logical colors implementation (35.52 KB, patch)
2005-09-12 11:46 UTC, Tommi Komulainen
none Details | Review
Updated logical colors patch from maemo-gtk against HEAD (23.09 KB, patch)
2005-11-17 18:25 UTC, Michael Natterer
none Details | Review
New file needed for above patch (1.92 KB, text/plain)
2005-11-17 18:26 UTC, Michael Natterer
  Details
New file needed for above patch (2.66 KB, text/plain)
2005-11-17 18:28 UTC, Michael Natterer
  Details
maemo patch merged with matthias' patch (37.25 KB, patch)
2005-11-22 18:50 UTC, Michael Natterer
committed Details | Review

Description Owen Taylor 2003-06-03 16:46:19 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)'
Comment 1 Iain 2003-12-26 15:53:58 UTC
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?
Comment 2 Daniel Brockman 2004-08-12 18:25:33 UTC
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?
Comment 3 Owen Taylor 2004-08-12 18:36:20 UTC
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.
Comment 4 Owen Taylor 2005-01-09 17:35:48 UTC
*** Bug 163428 has been marked as a duplicate of this bug. ***
Comment 5 Nickolay V. Shmyrev 2005-01-15 20:02:14 UTC
Is it possible to plan this feature to 2.8?
Comment 6 Federico Mena Quintero 2005-03-30 03:23:40 UTC
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.
Comment 7 Federico Mena Quintero 2005-03-31 19:33:07 UTC
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
Comment 8 Nickolay V. Shmyrev 2005-04-04 15:28:58 UTC
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
Comment 9 Tommi Komulainen 2005-09-12 11:46:15 UTC
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"
}
Comment 10 Michael Natterer 2005-11-17 18:25:00 UTC
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.
Comment 11 Michael Natterer 2005-11-17 18:26:03 UTC
Created attachment 54882 [details]
New file needed for above patch
Comment 12 Michael Natterer 2005-11-17 18:28:00 UTC
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.
Comment 13 Tim Janik 2005-11-18 13:15:39 UTC
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
Comment 14 Matthias Clasen 2005-11-19 05:02:38 UTC
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.
Comment 15 Michael Natterer 2005-11-21 13:00:27 UTC
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.
Comment 16 Matthias Clasen 2005-11-21 13:44:33 UTC
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");


 
Comment 17 Michael Natterer 2005-11-21 14:22:49 UTC
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.
Comment 18 Michael Natterer 2005-11-22 18:50:39 UTC
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
}
Comment 19 Matthias Clasen 2005-11-23 06:11:48 UTC
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.
Comment 20 Michael Natterer 2005-11-23 10:37:14 UTC
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.