GNOME Bugzilla – Bug 669342
overlay: add left/right/top/bottom style classes to overlay children
Last modified: 2012-02-29 17:37:45 UTC
See attached patch. This is very useful e.g. to round corners and tweak borders for the floating bars in Nautilus and Epiphany.
Created attachment 206724 [details] [review] overlay: add left/right/top/bottom style classes to overlay children If the children has no programmatic margin set, follow its vertical and horizontal alignment changes and set left/right/top/bottom style classes accordingly.
Hmm, I don't think this is going to work with the overlays in my new color-chooser, which use ::get-child-position
Created attachment 206913 [details] [review] overlay: add left/right/top/bottom style classes to overlay children A different approach, which also works when a custom get-child-position function is used. Now we just compare the allocations of the child widget and the overlay.
Created attachment 206914 [details] [review] tests: add a test for GtkOverlay position style classes Tests style classes are correctly set for various overlay use scenarios.
Review of attachment 206913 [details] [review]: ::: gtk/gtkoverlay.c @@ +196,3 @@ + gtk_style_context_add_class (context, GTK_STYLE_CLASS_BOTTOM); + else + changed = FALSE; This doesn't look right to me... changed should only be FALSE if _all_ the classes are unchanged, no ?
(In reply to comment #5) > This doesn't look right to me... changed should only be FALSE if _all_ the > classes are unchanged, no ? Yeah, that code was wrong. There was also another issue where the style classes were not correctly compensating for the presence of a scrolled window. Fixing that also uncovered another bug that was already present in GtkOverlay, namely we weren't checking the return value of gtk_widget_translate_coordinates(), which could lead to using uninitialized values as allocation coordinates. I now pushed a fixed version of this patchset to git master, including an updated test that covers the GtkScrolledWindow case too.