GNOME Bugzilla – Bug 667831
queue resizes on eel canvas as elements' visibility change
Last modified: 2012-01-16 16:15:36 UTC
Created attachment 205150 [details] [review] patch Nautilus' file view does first create an empty eel canvas, and then fill it in with the elements. However, gtk_widget_get_preferred_height/width still yield 0 after the elements were added to the canvas root. I'm attaching a patch that haves the eel canvas queue resizes as elements are added/removed, or change visibility, so the size request caches are updated for the widget. fwiw, I've only seen this to have a visible effect when overshooting with the GTK+ kinetic scrolling patches, as the child widget (the eel canvas in nautilus file view) may be relocated then, and the 0,0 size request plays odd in that case.
Review of attachment 205150 [details] [review]: Looks plausible; just a comment below. Also, you could factor out an eel_canvas_queue_resize() function that does the drawable check. ::: eel/eel-canvas.c @@ +790,3 @@ + + if (gtk_widget_is_drawable (GTK_WIDGET (item->canvas))) + gtk_widget_queue_resize (GTK_WIDGET (item->canvas)); Is this really needed here on _show()? Why don't you have a matching call on eel_canvas_item_hide()?
Created attachment 205377 [details] [review] patch v2
(In reply to comment #1) > Is this really needed here on _show()? Why don't you have a matching call on > eel_canvas_item_hide()? I assumed show() may happen regardless of the canvas widget being drawable or not, you're absolutely right about the missing call in _hide() though, I've added it in v2
Thanks, pushed this to git master.