GNOME Bugzilla – Bug 751409
gtk_style_context_add_provider() does not propagate to children
Last modified: 2018-05-02 16:38:03 UTC
When a custom style provider is added through the gtk_style_context_add_provider() API, the style is not propagated to children of that style - only to subelements, since they share the same style context. This is how gtk_style_context_add_provider() is documented to work, but it's not very intuitive, considering that all the other styles propagate according to CSS rules. After talking about this on IRC with Benjamin, he suggested that a new API is added, since gtk_style_context_add_provider() is used in many other places and we probably don't want to change that behavior now.
+1 From Eclipse/SWT side. It would really help. Some elements can't be accessed without this at present (e.g in combo box Bug 747798)
*** Bug 747798 has been marked as a duplicate of this bug. ***
Benjamin and I talked about this at the GTK hackfest. First of all it needs to be possible for widgets' style contexts to be able to take their styles from more than two GtkCssCascades (see gtkstylecontext.c). (A GtkCssCascade is a list of GtkCssProviders with their corresponding priorities.) Currently they can be affected by cascades of CSS providers added with gtk_style_context_add_provider_for_screen(), and cascades of providers added to the style context directly with gtk_style_context_add_provider(). This limit of two cascades is currently hardcoded. Extending this requires not just three cascades but N cascades, since a style context can be affected by any number of parent contexts' providers. The patch I'm about to post should lay this groundwork. After that, there will need to be a second level of custom cascade added to GtkStyleContext, besides the default screen cascade and the custom cascade that gtk_style_context_add_provider() adds to. This will require some careful thinking about what happens when providers are added or removed, so that cascades always inherit from the correct parent cascades.
Created attachment 329884 [details] [review] style cascade: Allow cascades with more ancestors Previously a style cascade's parent could not have a parent itself. That represented the two levels at which you could add a style provider: at the screen level, with gtk_style_context_add_provider_for_screen(), and at the style context level, with gtk_style_context_add_provider(). This commit changes no functionality, but this change will be necessary for adding style providers in the future that apply to a subtree of the widget tree. It relaxes the requirement that a style cascade's parent must not have a parent, since in the future a style context may be affected by any number of parent widgets' style contexts.
Comment on attachment 329884 [details] [review] style cascade: Allow cascades with more ancestors I'd have split that into 2 commits - one for he tests and one for the code - but that's just nitpicking.
Attachment 329884 [details] pushed as 76bacfd - style cascade: Allow cascades with more ancestors
Thanks - Sorry I didn't push it earlier, I discovered I did not have my SSH key on the machine I brought to the hackfest. Going to reopen this though, since that was just the preliminary work.
*** Bug 768925 has been marked as a duplicate of this bug. ***
-- 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/559.