Re: Color schemes for GTK+

[Matthias Clasen <mclasen redhat com>]

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.