Hi; On 4 May 2015 at 13:38, The Devils Jester <thedevilsjester@xxxxxxxxx> wrote: > I am aware of the dynamics of GTK If you say this, followed by: > In the same vein, of colors, can someone explain what I am doing wrong when: > gtk_style_context_get_background_color(context, GTK_STATE_FLAG_NORMAL, > &bg_n); gives me nothing but black for the same widget that > gtk_widget_get_style gives me the (expected) rgb (214,214,214) ? Then it means you're not really aware of the dynamics of GTK. The gtk_widget_get_style() function is a deprecated API that we had to leave in there because the CSS style machinery wasn't finished by the time we released 3.0, and because applications would have needed much more porting from 2.x to 3.0 if we downright eliminated that function. It was not optimal, but the other option would have been to delay GTK 3.0 by another 6 to 12 months, and that would have had a cascade of effects on the rest of the ecosystem based on GTK+. Historical reasons aside, this means that gtk_widget_get_style() returns a best effort value which may or may not make sense. For instance, if you ask gtk_widget_get_style() the for the background color of a widget using a with a background image in CSS, what color should you get? What happens if the widget is using a gradient? Right now, it's completely undefined. That is why you don't query a style context for a background color: you just ask the style context to draw a background, according to the state in which the style context is. > but the need to render custom widgets to > use a similar color palette to the current theme is a real one that does not > seem to have an elegant solution. The elegant solution is to use the gtk_render_* family of functions. Ciao, Emmanuele. -- https://www.bassi.io [@] ebassi [@gmail.com] _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gtk-list
