After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 744517 - insufficient deprecation note for gtk_widget_get_style
insufficient deprecation note for gtk_widget_get_style
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: .General
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2015-02-14 09:23 UTC by Stefan Sauer (gstreamer, gtkdoc dev)
Modified: 2018-05-02 16:25 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Stefan Sauer (gstreamer, gtkdoc dev) 2015-02-14 09:23:43 UTC
Right now I am using this code to paint my clutter-canvas in a color matching the UI-theme:

  GtkStyle *style = gtk_widget_get_style (self->priv->canvas_widget);
  GdkColor *c = &style->base[GTK_STATE_NORMAL];
  ClutterColor stage_color = {
    c->red >> 8, c->green >> 8, c->blue >> 8, 0xff
  };
  clutter_stage_set_color (CLUTTER_STAGE (self->priv->stage), &stage_color);

Unfortuantely gtk_widget_get_style() is deprecated and tells me I should use GtkStyleContext. Voila:

  GtkStyleContext *style = gtk_widget_get_style_context (
      self->priv->canvas_widget);
  GdkRGBA c;
  // this seems th be *always* black
  gtk_style_context_get_background_color (style, GTK_STATE_NORMAL, &c);
  ClutterColor stage_color = {
    c.red * 256, c.green * 256, c.blue * 256, c.alpha * 256
  };  
  clutter_stage_set_color (CLUTTER_STAGE (self->priv->stage), &stage_color);

But gtk_style_context_get_background_color() is also not recommended (bug #742198). So I am a bit short on what I am supposed to do here.
Comment 1 Matthias Clasen 2015-02-15 01:41:18 UTC
css doesn't have the concept of a background color.
gtk_render_background does the right thing
Comment 2 Stefan Sauer (gstreamer, gtkdoc dev) 2015-02-15 16:40:03 UTC
Then apparently GtkClutterEmbed is not using gtk_render_background() which is not helpful at this point. Hence I still need a way to get the color that gtk_render_background() would use. I can try to see if I can ::draw() the clutter_embed and then chain up, but it seems more complicated than it should be.
Comment 3 Stefan Sauer (gstreamer, gtkdoc dev) 2015-02-15 17:20:49 UTC
Just for reference:
https://git.gnome.org/browse/clutter-gtk/tree/clutter-gtk/gtk-clutter-embed.c#n274

And since
https://git.gnome.org/browse/clutter-gtk/tree/clutter-gtk/gtk-clutter-embed.c#n86
it is a GTK_TYPE_CONTAINER and it chains up after it has drawn the stage, the parent can't rig it.

I you feel like GtkClutterEmbed does it wrong we can change the category.
Comment 4 Emmanuele Bassi (:ebassi) 2015-02-15 19:47:53 UTC
(In reply to Stefan Sauer (gstreamer, gtkdoc dev) from comment #3)

this is really not an issue with GTK+'s own API, nor with the deprecation. you're just seeing the seams of the integration between two toolkits.

> Just for reference:
> https://git.gnome.org/browse/clutter-gtk/tree/clutter-gtk/gtk-clutter-embed.
> c#n274
> 
> And since
> https://git.gnome.org/browse/clutter-gtk/tree/clutter-gtk/gtk-clutter-embed.
> c#n86
> it is a GTK_TYPE_CONTAINER and it chains up after it has drawn the stage,
> the parent can't rig it

you're trying to get the Stage to have a background color on a widget that does not have any style whatsoever.

> I you feel like GtkClutterEmbed does it wrong we can change the category.

GtkClutterEmbed is a very special case, since it's embedding a native window to draw on it using GL.

GtkClutterEmbed is also not heavily maintained, so any change inside GTK+ is likely to break it.

you have the option to set the color of the Stage to use the alpha channel, and then just draw it transparent; the background of the parent will be visible through the stage's own background.
Comment 5 Stefan Sauer (gstreamer, gtkdoc dev) 2015-02-16 06:31:55 UTC
Thanks for the replies. Unfortunately the alpha option does not work, the background would comes out black.

Here are the variants that I've tried:
https://github.com/Buzztrax/buzztrax/blob/master/src/ui/edit/main-page-machines.c#L1533-1564

and here is where the part of the UI is setup:
https://github.com/Buzztrax/buzztrax/blob/master/src/ui/edit/main-page-machines.c#L1773-1788

In the code in git alpha is opaque (to apply the color), but I've tried alpha=0 as well.
Comment 6 Stefan Sauer (gstreamer, gtkdoc dev) 2015-07-21 20:54:10 UTC
Still banging my head against this. Even if I use an event_box as a parent for the clutter_embed, the background will be black. I need to find a way to either configure the color correctly or tell clutter_embed to *not* draw the background.
Comment 7 Stefan Sauer (gstreamer, gtkdoc dev) 2015-07-22 12:31:57 UTC
FYI: I am now using a css color, which does not help to align this what the theme defines, but is better than nothing. I think this boils down that we don't have any facilities for custom widgets to align with the chosen theme.
Comment 8 Matthias Clasen 2015-07-23 00:27:03 UTC
That is not true. If you use gtk_render apis like gtk_render_background and gtk_render_frame, your custom widget will pick up current theme just fine.
Comment 9 Emmanuele Bassi (:ebassi) 2015-07-23 00:59:56 UTC
You can even use gtk_render_* with a new GtkStyleContext and draw on a ClutterCanvas — thus rendering GTK widget style components inside a ClutterActor.

In short: if you want to draw what a GTK widget would draw in a ClutterActor, use GtkStyleContext and the gtk_render_* API on a Cairo context (i.e. do what GTK does), instead of querying the state of the GTK style machinery and drawing with Clutter.
Comment 10 Daniel Boles 2017-10-12 11:32:52 UTC
Does anything actually need done here?
Comment 11 GNOME Infrastructure Team 2018-05-02 16:25:15 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/532.