GNOME Bugzilla – Bug 773175
boxes-menu-row button corners are rounded improperly
Last modified: 2017-09-12 09:28:41 UTC
Created attachment 337962 [details] screenshot of current page 2: button corners rounded wrongly at top of box The lowermost button in main_vbox always gets rounded bottom corners, even if the current state of the wizard means that it's at the top.
Created attachment 337963 [details] screenshot of current page 1: uppermost button never gets rounded corners And the uppermost button never gets rounded!
I think the crux of this is - by my limited understanding - that this fragment > .label + .boxes-menu-row, > .boxes-menu-row.button:first-child { does not do what it was intended to, because (A) the 1st button only has the "boxes-menu-row" style class, not "button" (B) we can fix the grammar of this as follows > .boxes-menu > .boxes-menu-row:first-child (C) but then this rule breaks the previous page, because in that case, the 1st child is the top label, and contrary to what that selector seems to be trying to say - there is no way to express 'apply this to the first-child /that is a button/' - so the rule simply applies to the first child overall, here the label. But I might well be very wrong :-) However if this is the case, then I think removing these attempted styles would be better in the interim, until the CSS can be rewritten to work as intended.
I rewrote my post and lost a lot of it... (In reply to djb from comment #2) > > (B) we can fix the grammar of this as follows > > > .boxes-menu > .boxes-menu-row:first-child I meant that this fixes the Enter URL button, on its own (2nd) page, to have rounded top left/right corners. > (C) but then this rule breaks the previous page, because in that case, the > 1st child is the top label, and contrary to what that selector seems to be > trying to say - there is no way to express 'apply this to the first-child > /that is a button/' - so the rule simply applies to the first child overall, > here the label. I meant that on this page - the initial page of the New Box wizard - the top corners of the same button are not rounded, because the rule is given to the topmost label, instead of this button. So the different rules are in conflict with each other, and I don't think there's currently a way to make them work. Maybe it would require dedicated CSS classes to be added to any of these buttons that need to have rounded corners at either the top or the bottom. This would avoid the requirement to play complex selector tricks that don't seem to work anyway.
Created attachment 337969 [details] [review] patch: use specific style classes to apply rounding to given top/bottom corners I sketched this up. It looks OK to me, but (as a bit of a hack) required moving the libvirt_sys_import_button into the middle. I also can't quite tell what the original intention of the CSS was, so maybe I've totally subverted it all... :)
Created attachment 337970 [details] screenshot showing result of patch: page 1
Created attachment 337971 [details] screenshot showing result of patch: page 2
Review of attachment 337969 [details] [review]: Very sorry for such a late review but I was hoping a designer would be able to review better. Thanks a lot for providing a good commit log. Some nitpicks on shortlog: * Convention is to capitalize the first letter of the sentence/phrase, 'Fix' in this case. * We prefer shortlog to summarize the change rather than effect/benefit and be specific. If that's not possible, it typically means that patch needs to be divided further (i-e each logical change in it's own patch). ::: data/ui/wizard-source.ui @@ +85,2 @@ <child> + <object class="GtkButton" id="libvirt_sys_import_button"> Why are you changing order of buttons? These changes (if needed) doesn't belong in this style changing patch.
I'm going to be optimistic and assume this other bug fixed everything *** This bug has been marked as a duplicate of bug 787527 ***