GNOME Bugzilla – Bug 662177
Toolbar returns invalid paths for toolbar items
Last modified: 2011-11-14 10:18:57 UTC
In certain cases GtkToolbar returns invalid widget paths for toolbar items. This has to do with adding invisible toolbar items, as done by GtkUiManager. I had a hard time making a simple test case, but this is easily demonstrated by running the glade application. Warnings like this are output: (glade:15517): Gtk-CRITICAL **: gtk_style_provider_get_style_property: assertion `g_type_is_a (gtk_widget_path_get_object_type (path), pspec->owner_type)' failed Putting the following assertion at the end of gtk_toolbar_get_path_for_child() reports that indeed invalid paths are being returned: g_assert (gtk_widget_path_get_object_type (path) == G_OBJECT_TYPE (child));
Created attachment 199417 [details] [review] gtk: GtkToolbar returns invalid paths when adding tool items * Fix problems where gtk_toolbar_get_path_for_child() returns invalid paths, because content has changed since siblings_path was calculated
Isn't gtk_toolbar_invalidate_siblings() the exact same thing as gtk_toolbar_invalidate_order()? And if so, isn't adding a call to gtk_toolbar_invalidate_order() in toolbar_content_remove() enough to fix the problem?
(In reply to comment #2) > Isn't gtk_toolbar_invalidate_siblings() the exact same thing as > gtk_toolbar_invalidate_order()? Well it invalidate_siblings() doesn't call gtk_widget_reset_styles() for all children. > And if so, isn't adding a call to gtk_toolbar_invalidate_order() in > toolbar_content_remove() enough to fix the problem? No toolbar content is being removed in this case. Note that the expensive gtk_widget_reset_styles() is being called all over the place, and it asks for widget paths. For example gtk_widget_set_parent() ends up calling reset_styles(). So essentially priv->sibling_path seems to be set in unexpected places when the toolbar is in an interim state. That interim sibling_paths is then not cleared out. This is what it seems to me, but you might understand it better. So the reason for splitting invalidate_siblings() out from invalidate_order() is that this doesn't cause yet more unnecessary reset_styles() churn.
Created attachment 199506 [details] [review] gtk: GtkToolbar returns invalid paths when adding tool items * Calculate siblings_path on demand, so that it's always correct and doesn't get out of sync with the toolbar state.
Comment on attachment 199506 [details] [review] gtk: GtkToolbar returns invalid paths when adding tool items This sounds like the easiest solution for the problem, so let's go with it.
Thanks. Merged into master. Can I backport this into gtk-3-2 branch?
Please do.
I tried cherry-picking these two commits to the gtk-3-2 branch, but it didn't fix the problem. Can you think of any other commits that need to be back ported? commit 43afb192f20af925b16aa13e8d3f6122954ab2f1 Author: Stef Walter <stefw@collabora.co.uk> Date: Wed Oct 19 13:17:18 2011 +0200 gtk: GtkToolbar returns invalid paths when adding tool items * Calculate siblings_path on demand, so that it's always correct and doesn't get out of sync with the toolbar state. https://bugzilla.gnome.org/show_bug.cgi?id=662177 commit ad389880850607129d87823d3ed605bc4e598aca Author: Benjamin Otte <otte@redhat.com> Date: Tue Sep 27 04:29:55 2011 +0200 toolbar: Fix widget path creation code - Ensure arrow button is always included - Invalidate list when direction changes
No idea. And I'm on vacation still, so I have the luxury to not care. ;) Poke me next week, if I forget about it please.
Pokedy poke :)
I pushed those commits to gtk-3-2, since I just tested them to work properly on a clean build/installation; Stef, it's possible you still had the old .so lurking in your library path? Anyway, closing as FIXED, feel free to reopen if this is an issue again.
That did the trick. Yeah, it's possible I screwed up on my jhbuild directory. Thanks!