GNOME Bugzilla – Bug 769876
GtkGrid, :nth-child not working as expected in rtl, resulting in .linked child widgets visual breakage
Last modified: 2018-04-22 19:31:41 UTC
Created attachment 333260 [details] Screenshot. The search bar of dconf-editor uses a “linked” CSS class on a GtkGrid to link a GtkSearchEntry and a GtkButton. Looks like it is broken in languages that are writen right-to-left.
This is not a theme issue, the :nth-child pseudoclass doesn't work as it should there, try `.linked button:last-child { color: red; }` in the inspector and stare at the button (which should be the :first-child) getting a red arrow. Changing summary to reflect the issue.
OK, I see, thanks. I solved `dconf-editor` problem using GtkBox ( https://git.gnome.org/browse/dconf-editor/commit/?id=23317f8675422e289bce1e456b69f50de65dd22f ), but I think the issue is a dangerous one as nobody^Wonly a few people test in RTL.
It seems to me that the problem here is really Box! It applies :last-child to both * the FIRST child added to the container * the FIRST child in the reading direction Grid correctly selects the _last_ for both points, but this does not agree with whatever the theme CSS is trying to do.
Created attachment 347097 [details] test case run, then use the inspector to change the text direction
Created attachment 347098 [details] screenshots of test case in LTR vs RTL modes
*** Bug 772817 has been marked as a duplicate of this bug. ***
GtkBox is behaving as documented here: gtkbox.c: * In horizontal orientation, the nodes of the children are always arranged * from left to right. So :first-child will always select the leftmost child, * regardless of text direction. GtkGrid does not document how it handles such cases one way or another.
I'm going to attach a patch at Bug 772817 for GtkPathBar, which is another widget that flips the children in RTL and thus needs TLC. That may end up being adaptable to other cases, at least while the widgets themselves refuse to handle the child order like GtkBox, as Bug 681660 indicated GtkGrid won't do (for now).
(In reply to Daniel Boles from comment #7) > GtkBox is behaving as documented here: gtkbox.c: > * In horizontal orientation, the nodes of the children are always arranged > * from left to right. So :first-child will always select the leftmost child, > * regardless of text direction. Note that for master, Benjamin and Timm want this to stop, but it's not quite trivial on the theme side: > Company: > dboles: when you do this work, can you make box also not flip on RTL > anymore? > > dboles: > I was thinking that might be the correct approach for master > but in gtk-3-22 it'll have to be some awful workaround like that patch > > Company: > yes, baedert and me complain about it all the time > but neither of us wants to fix the theme... > > dboles: > Company: it's hopefully not that difficult - at least, fixing that one case > on gtk-3-22 seemed easy enough and shouldn't(!?!) break anything > else > Company: then we'd probably just have .linked assume no flipping, converse > to what it currently does, and avoid the need for any > %linked_rtlflip or whatever > > Company: > dboles: yeah - but there might be more cases that use boxes than just > .linked > dboles: so one would probably need to look through the theme and figure our > if all the cases of :first-child/:last-child still work > dboles: like, I have no idea what happens with spinbuttons or comboboxes
*** This bug has been marked as a duplicate of bug 681660 ***