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 708583 - StyleContext: removing or adding a provider doesn't invalidate the style context
StyleContext: removing or adding a provider doesn't invalidate the style context
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Class: GtkStyleContext
3.9.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks: 707923
 
 
Reported: 2013-09-22 16:50 UTC by Sébastien Wilmet
Modified: 2013-10-05 12:03 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Improve doc of gtk_style_context_invalidate() (997 bytes, patch)
2013-09-28 14:21 UTC, Sébastien Wilmet
committed Details | Review

Description Sébastien Wilmet 2013-09-22 16:50:05 UTC
When calling gtk_style_context_add_provider() or gtk_style_context_remove_provider(), the style context is not invalided. I.e. gtk_style_context_invalidate() is not called.

The gtk_style_context_invalidate() documentation says:

> If you're using a GtkStyleContext returned from
> gtk_widget_get_style_context(), you do not need to call this yourself.

It is the case in GtkSourceView (where the bug occurs), the StyleContext comes from gtk_widget_get_style_context().

So either the documentation must be fixed, or the style context must be invalidated when a provider is added or removed.
Comment 1 Benjamin Otte (Company) 2013-09-26 00:13:50 UTC
Yeah, this probably needs doc fixes.

Style contexts returned from gtk_widget_get_style_context() are invalidated lazily. So the invalidate signal (and in turn the widget's style_updated() signal are only emitted once the frame clock runs and the style + layout + draw cycle is executed.
Comment 2 Benjamin Otte (Company) 2013-09-26 00:15:29 UTC
Fwiw, other style contexts should be invalidated immediately since 3.6 or so when style providers got their changed signal without the need to call  gtk_style_context_invalidate().
Comment 3 Sébastien Wilmet 2013-09-26 15:37:20 UTC
gtk_style_context_get_color() is called just after changing the provider, in the same main loop cycle. But the returned color is wrong. When calling gtk_style_context_invalidate() after changing the provider, the returned color is good. So it's maybe a bug in the lazy invalidation.
Comment 4 Benjamin Otte (Company) 2013-09-26 21:43:17 UTC
Lazy means it's not updated immediately. It will return the color used in the last drawing cycle, even if you explicitly override it.

That's by design.
Comment 5 Sébastien Wilmet 2013-09-26 22:19:07 UTC
Okay. I thought the value should be updated when we request it.
So the invalidate() function is useful when we don't want to wait the next drawing cycle.
Comment 6 Benjamin Otte (Company) 2013-09-26 22:43:49 UTC
Ideally we'd want that, but there were a bunch of reasons why that was a bad idea (too many GTK apps requesting stuff immediately to make lazy invalidation not worth it) so that I did it this way.

It's one of the things we might want to look at again for 4.0 (because that's how Javascript Style objects work) after we've fixed all the stupid GTK widgets.
Comment 7 Sébastien Wilmet 2013-09-28 14:21:19 UTC
Created attachment 255985 [details] [review]
Improve doc of gtk_style_context_invalidate()
Comment 8 Benjamin Otte (Company) 2013-10-05 12:03:15 UTC
I've deprecated gtk_style_context_invalidate() now. It shouldn't be needed in
regular code as the style context should invalidate itself properly whenever
it gets modified.

Attachment 255985 [details] pushed as ab112a2 - Improve doc of gtk_style_context_invalidate()