I have an application in which I wish to make a custom
color-picking dialog, with sliders for red, green, and blue.
This dialog should also have a split "difference bar" like
the standard GTK color-picker, and I have run into some
problems implementing it.
The idea is to use a GtkDrawingArea, set the background
to the old color, and draw a rectangle in one half of the
area that tracks the user's selected color. I have been
able to make this work, but I've run across some very
strange behavior, and I am not confident that I've understood
what's going on.
I gave the GtkDrawingArea its own local style, by copying
out the default style, modifying it, and reassigning it -- this
is done in order to set the background color. When drawing the
rectangle, I use this local style's foreground graphics context,
setting the ".foreground" color-attribute to the new GdkColor,
but if you do only this to set the color, then colors change
elsewhere in the dialog, specifically the bevels of the sliders,
and the backgrounds (*not* foregrounds!) of some nearby text
areas. Even though the style has been copied out, it appears
that the graphics contexts are still shared.
Interestingly, I have found that if I set the foreground
color in the style first, (i.e. style.fg[0]=<color>), and then
*also* set the foreground attribute of the graphics context
(style.fg_gc[0].foreground=<color>), I see no extra color changes
outside of the DrawingArea itself -- setting the style.fg seems
to "un-share" the graphics contexts.
Is this correct behavior, and is it likely to persist in future
versions? I don't mind working around behavioral oddities, but
these look like things that might get fixed later on, causing
my code to break. Also, does anyone know of a handy reference
on GTK's handling of colors and graphics contexts generally?
Thanks.
-- A.
[EMAIL PROTECTED]
_______________________________________________
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
