Color schemes for GTK+

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Color schemes for GTK+

Matthias Clasen
Color schemes for GTK+
----------------------

This is a proposal to add support for color schemes ("recolorable
themes") to GTK+. The proposal has two parts, a desktop-wide set
of named colors, and support for named colors in rc files.


1) Add a setting gtk-color-scheme, which holds a string specifying
a set of named colors, in the following format:

name1: color1
name2: color2
...

E.g

 "foreground: black\nbackground: #0a0a0a\n"

Color names must be acceptable as identifiers in the gtkrc syntax,
color specifications must be in the format accepted by
gdk_color_parse().

This setting is available in string form, but GTK+ converts it to
a hash table mapping names to GdkColors. This hash table is attached
as object data to the settings object, and can be obtained with

 g_object_get_data (G_OBJECT (settings), "gtk-color-scheme")
 
In this way, theme engines have access to the color scheme.


2a) Extend the gtkrc syntax to allow named colors. Where a color
is expected in a gtkrc file, a named color can be specified as

 @name

This resolves to the color named "name" in the current color scheme.
What color names are allowed depends on the color scheme, although it
is expected that there will be a small set of standard color names,
which can be assumed to be present in every color scheme (this is the
set of colors that a "color scheme capplet" would allow users to
change).


2b) In order to ensure that gtkrc files continue to work in the absence
of a color scheme setting (e.g. when no settings manager is running),
the rc file syntax is further extended to allow rc files to specify
default values for the named colors it uses, in the following form:

colors
{
  name1 = color1
  name2 = color2
  ...
}

E.g.

colors
{
  foreground = "black"
  background = "#0a0a0a"
}

Note that rc files can define and use named colors which are not
present in the color scheme, e.g.

colors
{
  foreground = "black"
  light-foreground = lighter (@foreground)
}


2c) Allow "color expressions" in rc files, to enable themes to derive
color variations from the colors in the color scheme. The following
expressions are initially proposed:

 mix (factor, color1, color2)

Compute a new color by mixing color1 and color2. The factor
determines how close the new color will be to color1. A factor of
1.0 will give pure color1, a factor of 0.0 will give pure color2.
Factors in between will give a mixture.

 shade (factor, color)

Compute a lighter or darker variant of color, by first converting the
color to the HLS color space and then modifying the L (lightness)
coordinate. A factor of 1.0 leaves the color unchanged, smaller
factors yield darker colors, larger factors yield lighter colors.
 
 lighter (color)   is a shorthand for shade (1.3, color)
 darker (color)    is a shorthand for shade (0.7, color)
 
E.g:
 
 mix (0.5, "red", "blue")
 shade (1.5, mix (0.3, "#0abbc0", { 0.3, 0.5, 0.9 }))
 lighter (@foreground)


The attached patch implements all parts of this proposal.


Comments appreciated, Matthias


_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

colors.diff (23K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Color schemes for GTK+

Nickolay V. Shmyrev
Hi Mattias.

Color schemes proposal is very interesting, but I have a few probably
related questions:

1.

As I've understood, the goal of this proposal is to implement color capplet
in Control Center to let user manually select color scheme for desktop.

In general I think it's questionable. We don't let user change some
simple settings and force him to use gconf-editor while we are going to
let him change color scheme. It's really hard to select color scheme
that nicely fits with desktop. User should take into account the
following things: number of color applications, icons, background and
different gtk widgets. Isn't it better to provide default gnome theme
with several predefined color schemes. I can't imagine the user that can
accomplish this task. But this question is rather question to usability
list.

It's not clear for me, how then UI for capplet will be build. Are you
going to retrieve list of named colors from style and expose them? Then
you will need at least some support of i18n for every named color and
readable comment for it. If this list will be specific for every engine,
why do we need to expose it in rc file? is someone going to edit things
like 0.75 in light_background = shade (@background, 0.75)?

Isn't it better to place this things into engine directly.

2.

If there will be a fixed set of named colors, what is that list and why
do we also need to allow users edit this fixed list. And where is
support for color applications? How is it related to stock colors
proposal? Btw, it has a patch also, but no response was recieved.

3.

I think that gtk_shade_color and gtk_mix_colors are useful for theme
engines and applications, why not expose them in API in gdkcolor.h? For
example, they are copy-pasted in clearlooks engine and used in several
places of gtk.





_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Color schemes for GTK+

Matthias Clasen
On Fri, 2005-06-10 at 18:18 +0400, Nickolay V. Shmyrev wrote:

> Hi Mattias.
>
> Color schemes proposal is very interesting, but I have a few probably
> related questions:
>
> 1.
>
> As I've understood, the goal of this proposal is to implement color capplet
> in Control Center to let user manually select color scheme for desktop.
>
> In general I think it's questionable. We don't let user change some
> simple settings and force him to use gconf-editor while we are going to
> let him change color scheme. It's really hard to select color scheme
> that nicely fits with desktop. User should take into account the
> following things: number of color applications, icons, background and
> different gtk widgets. Isn't it better to provide default gnome theme
> with several predefined color schemes. I can't imagine the user that can
> accomplish this task. But this question is rather question to usability
> list.
>
> It's not clear for me, how then UI for capplet will be build. Are you
> going to retrieve list of named colors from style and expose them? Then
> you will need at least some support of i18n for every named color and
> readable comment for it. If this list will be specific for every engine,
> why do we need to expose it in rc file? is someone going to edit things
> like 0.75 in light_background = shade (@background, 0.75)?
>
> Isn't it better to place this things into engine directly.

The color capplet is not written yet, and I would certainly ask for
interaction designers input how they think it should be done. I can
see three levels of complexity here:

1) Have a fixed set of colors, and have named color schemes. The color
   color capplet would list available color schemes, much like the
   other theme tabs list available widget, wm, icon themes. Maybe
   themes could propose a default color scheme, like they can propose
   a font currently.

2) Have a fixed set of colors, and let the user tweak them individually
   in the color capplet. Themes could still propose a default color
   scheme.
 
3) Like 2), but drop the fixed set of colors, each theme can have its
   own set of named colors, and the color capplet has to adapt to that
   somehow.


I think 3) is overly complex.

> 2.
>
> If there will be a fixed set of named colors, what is that list and why
> do we also need to allow users edit this fixed list. And where is
> support for color applications? How is it related to stock colors
> proposal? Btw, it has a patch also, but no response was recieved.

This is a good question which I forgot to ask in my mail. I think
Billy Biggs had a proposal for a set of colors at some point. I keep
loosing the url to that page, though...

I don't think there is a strong relation to the stock colors proposal.
It should be possible to implement stock colors on top of the color
scheme proposal. But then you need a color capplet that can handle
color schemes with arbitrary lists of colors, not just a fixed set
that might be sufficient for themes.

>
> 3.
>
> I think that gtk_shade_color and gtk_mix_colors are useful for theme
> engines and applications, why not expose them in API in gdkcolor.h? For
> example, they are copy-pasted in clearlooks engine and used in several
> places of gtk.
>

Possible, although you have to answer the nasty question about the best
color space to use, if you want to make them part of the official api.
The current implementation uses RGB for mixing, and HLS for shading.



_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list