GNOME Bugzilla – Bug 772817
File Chooser: Path arrow button frames are reversed and detached in RTL mode
Last modified: 2018-04-22 21:16:08 UTC
Created attachment 337532 [details] The arrows next to the path buttons are sorrounded with reversed and detached frames When opening a file with the file chooser widget (in LibreOffice or gedit, for example) in an RTL environment, the frames around the arrow buttons next to the path folder names buttons are reversed. See attached screenshot for example with Hebrew.
*** This bug has been marked as a duplicate of bug 769876 ***
GtkBox is behaving as expected; it's the themes that aren't, so removing the dupe. Note that if your downstream theme still has this problem, you would have to report it to them directly. However, we should fix this in our themes in GTK+.
The problem here is really that the themes implement %linked under the assumption that the widget adding that class behaves as GtkBox does wrt RTL, i.e. 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. but GtkPathBar is a GtkContainer, not a GtkBox, and it doesn't behave the same way. It's more like a single-row GtkGrid as seen at the other bug. A quick hack would be to work around this in the CSS. A proper fix would really be to define a consistent way for all horizontal containers to behave in this regard.
Created attachment 371235 [details] [review] themes: Fix swapped borders on RTL PathBar buttons Our .linked assumes GtkBox et al., which are documented as not changing node order for RTL, so the left child is always :first-child, and so on. But some widgets do change node order when RTL is active. In particular, GtkPathBar does, and not accounting for that in our themes meant that in RTL, its left/rightmost buttons got each other’s borders, looking wrong. This patch adds the groundwork for supporting widgets like that, via the %linked_rtlflip placeholder, and overrides with that on .path-bar.linked so that the correct borders get applied to those buttons when using RTL.
NautilusPathBar is a wildcard here. It (A) already works in RTL and (B) my fix breaks it again, so I need to dodge that. In their case, it seems the widgets get relayouted, as with my GTK+ patch, they initially look correct - but once I re-focus the Nautilus window, they go wrong again, because my new style takes over and counteracts the magical acrobatics they're already doing to fix this problem. These 2 PathBars have the same CSS node names/classes, widget.path-bar :( Could we perhaps add .GtkPathBar or something on our side, to avoid affecting Nautilus?
Created attachment 371236 [details] [review] themes: Fix swapped borders on RTL PathBar buttons Our .linked assumes GtkBox et al., which are documented as not changing node order for RTL, so the left child is always :first-child, and so on. But some widgets do change node order when RTL is active. In particular, GtkPathBar does, and not accounting for that in our themes meant that in RTL, its left/rightmost buttons got each other’s borders, looking wrong. This patch adds the groundwork for supporting widgets like that, via the %linked_rtlflip placeholder, and overrides filechooser .path-bar.linked > button so that the correct borders get applied to those buttons when using RTL. Note that I select only PathBars within a FileChooser because we also have NautilusPathBar, which also uses widget.path-bar – but *does* flip its nodes for RTL already, so letting that get affected broke it again!
relevant, so copying from https://bugzilla.gnome.org/show_bug.cgi?id=769876#c9 > 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 That would mean this would not be needed in master, although maybe we should still pick this there until all the above is done.
Attachment 371236 [details] pushed as a3cb26c - themes: Fix swapped borders on RTL PathBar buttons