14 Sep
2010
14 Sep
'10
12:27 p.m.
On 09/14/2010 09:14 AM, Thorsten Wilms wrote:
On Mon, 2010-09-13 at 22:14 +0200, Olivier Guilyardi
wrote:
Of course you can do that, but I think that by default (and usually in themes)
it's the same as the selected color, such as the one when you click/hover a menu
item.
For the default rendering of the blue part,
using
GtkStyle.bg[GDK_STATE_SELECTED] seems to make sense since it renders to a color
(blue, brown, etc..) in many modern themes. However, in some other themes, it's
just another shade of gray.
Thorsten, did you think about this?
Sure. AFAIR fan-sliders use that approach.
I wonder if you can query for the color used for progress-bars. Either ignore unfortunate themes, or try to evaluate
the provided
colors, to use some fall-back if there isn't sufficient contrast.
Detecting contrast sounds like unreliable magic. I agree about ignoring
unfortunate themes. It needs a bit of testing, but even if there's just gray, I
think that the contrast should be sufficient in most cases.
An option for user-defined colors would have the
problem that users have
to know about that and then have to bother defining it, if colors are
unpleasant, otherwise.
To me, it's also the developer responsibility. With a customizable knob widget,
by default it would just use the base color palette. But a developer could
customize colors by providing his own styles, and even have different colors for
different knobs in the UI.
But, since most of the appearance could be controlled through GTK rc styles,
users as well as theme designers could add specific global rules for the knobs.
That would only work if the developer doesn't override them in his app of course.
Ideally, I think it could be useful to allow gradients (through some start/end
colors style rules), as well as wheel thickness and possibly a couple of other
details.
It'll take a bit of time, but I'll try and show you something that works when
it's ready.
--
Olivier