GNOME Bugzilla – Bug 778886
Frame: property label-yalign does nothing, since the border node was removed
Last modified: 2018-03-01 20:00:09 UTC
This used to control where the label-widget appeared relative to the border node. The default of 0.5 meant that the label-widget would get positioned vertically centered across the border (assuming the user didn't set flat style on the frame). The border CSS node has been removed, as of commit 96a94fc21d0baf6972bb05038a2fd03dced8147d - with the result that the border is drawn around the entire Frame. So, now the label-widget is always located inside the top-left (assuming no overridden xalign) of the frame/border, and the label-yalign property has no purpose/effect. It's hard to think of this property ever recovering any role, assuming the border node is staying gone... which I hope it doesn't :( But if that's not coming back, then the label-yalign property is dead wood and should be removed.
Created attachment 346148 [details] [review] Frame—Remove the now-useless property label-yalign The border is now drawn by the entire Frame, not as an internal border node, so we are no longer able to align the label to vertically overlap the border. The property no longer has any effect, so no use keeping it.
Created attachment 346685 [details] [review] [PATCH 2/2] Frame: Rename (get|set)_label_align() to _xalign() Their API just changed by dropping the yalign arg, so while users are adapting to that change, it is a free opportunity to unify the names of the methods with the property they now solely reflect, label-xalign.
Comment on attachment 346148 [details] [review] Frame—Remove the now-useless property label-yalign (tweaked the commit subject [no more pesky em dash] and message since this)
Created attachment 346686 [details] [review] [PATCH 1/2] Frame: Erase the now-useless property label-yalign The border is now drawn on the frame node, not using an internal border node, so we are no longer able to align the label to vertically overlap the border. The property no longer performs its original purpose, & nor is it a useful candidate for giving a new role, so no point keeping it. updated commit message + fixed missing return value (return_val_if_fail)
Review of attachment 346686 [details] [review]: sure, seems right for gtk4
Doesn't apply cleanly. Can you redo these and send an MR ?
Yeah, I got the same result - have a rebase that will probably work but have been having jhbuild troubles (says that a build dir for meson 0.44 doesn't exist) and didn't have time to figure that out yet.
(In reply to Matthias Clasen from comment #6) > Doesn't apply cleanly. Can you redo these and send an MR ? finally: https://gitlab.gnome.org/GNOME/gtk/merge_requests/40