Created attachment 300703 [details] [review]
widget: Convenience function for adding CSS style

It seems that one of the most requested functions for GtkWidget is being
able to add new CSS snippets on top of the existing style. This is
usually easily done just by using GtkCssProvider, but since people are
reimplementing this kind of API left and right, having it inside GTK+
may make sense.

The newly added gtk_widget_add_style() takes a CSS string, parses it
through GtkCssProvider, and adds the CSS provider instance to the
widget's style context, which then owns the GtkCssProvider instance.

Since users may want to remove the style later on, it seems easy to
return a pointer to the GtkCssProvider created by this function, than
figuring out a way to return a unique identifier for later removal, as
well as a way to map unique identifiers to GtkStyleProvider instances.

It is conceivable that a gtk_widget_replace_style() function may be
added in the future, which removes all the GtkStyleProviders associated
with a widget's style context, and replaces them with a new
GtkCssProvider that defines the whole of the CSS.

An argument could be made that the function should be called `gtk_widget_add_style_from_string()`, and maybe have a `gtk_widget_add_style_from_resource()` as well, since application developers also ship with additional CSS in the form of files embedded in GResources. I do like the idea of a small, string-oriented function, though. You can still load the data in a GResource, get the bytes buffer, and then pass it to this function.

We could also use a `GError**` out argument, but I went with the `g_critical()` because of the programmatic nature of the function; you're not supposed to feed it random CSS, so there's no point in being recoverable. If you want to feed random CSS, then you should be using GtkCssProvider in the first place.

Side note: this function could be used as the basis for re-implementing the various gtk_widget_modify_* deprecated API, because adding a new style provider to a style context does not change the style contexts of the children of the widget — though this may be not desirable in its own right.

Before we add more convenience functions like this, I think we should sort out the scope question - can we have style providers that apply to a widget and all its descendents ? Because I think that is what many people would expect from this api

-- 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/541.