GNOME Bugzilla – Bug 737330
EShellSwitcher: Count with GtkPaned::handle-size for button widths
Last modified: 2016-05-24 18:52:46 UTC
If you look at screenshot attachment #287021 [details] from bug #737300, in the "switcher" area (where you have buttons to switch between Mail, Contacts, Calendar, Tasks, Memos), it becomes apparent with Adwaita/GTK 3.14's "super slim vpane dividers" that the padding around the switcher buttons layout is not equal. Indeed there is the standard 6px padding on the left but not on the right. I tried finding where in the code this is governed, and I think (through grepping) that this is in e-shell-switcher.c, in the "shell_switcher_layout_actions" function. It uses the H_PADDING constant multiple times, particularly in a for loop where it uses that to determine the allocation.width and the x position. It is not entirely clear to me how to fix this because you seem to have some fancy calculations going on there, but I hope that pinpointing the probable code where this occurs might make it a trivial fix for you guys :)
Thanks for a bug report, but this will look incorrectly with other themes. The problem is also elsewhere, the current code counts with the width of the slider itself. When it would be wider, then the gap on the right would be twice big, which would look awful everywhere else. As is in the screen-shot, Adwaita makes it hard for users to change the width/height of the components, which feels like the right bug.
Hi Milan, > As is in the screen-shot, > Adwaita makes it hard for users to change the width/height of the components, > which feels like the right bug. I just tested now and that's not entirely accurate: while it visually *looks* thinner, the actionable area for the mouse remains the same, you can be somewhere near the pane "sliding" widget and click+drag it without any precision problems. Now that this is said, are you sure you can't do something about this in Evolution? You said that your code counts the width of the slider, then that means it can figure out that the width is smaller than the width of the left padding; so you could do something like if width_of_pane_handle_widget < left_padding: right_padding = left_padding - width_of_pane_handle_widget FWIW, Evolution is the only application I've seen affected by this, arguably all other apps use equal padding/spacing.
Hmm, Evolution counts with it implicitly, aka it "knows" the slider is 5 pixels width, thus it doesn't add extra padding to the right of the buttons, because it's already there (I made-up the number 5). Using conditional compile for GTK+ version may do it, it just feels odd and can easily break when they change their minds again and will add the padding or anything to the sliders.
Aha, the default GtkPaned::handle-size [1] changed from 5 to 1 pixel. Using this property will be much better than guessing on the Gtk+ version. [1] https://developer.gnome.org/gtk3/3.14/GtkPaned.html#GtkPaned--s-handle-size
Created commit a20e862 in evo master (3.13.7+) [1] Created commit 9da8cc8 in evo evolution-3-12 (3.12.8+) [1] https://git.gnome.org/browse/evolution/commit/?id=a20e862
Ah-ha, I knew you'd be able to come up with an self-adapting solution for that, thank you Milan :)
Uh oh... this issue has come back, exactly as reported before, with Evolution 3.20.2 and GTK/Adwaita 3.20.x.
(In reply to Jean-François Fortin Tam from comment #7) > Uh oh... this issue has come back, exactly as reported before, with > Evolution 3.20.2 and GTK/Adwaita 3.20.x. Hmm, so the gtk+ came with something which broke it again. That's unfortunate. I do see the issue under gnome-shell, but not under MATE. I tend to just live with it, rather than hunt for a fix each 1.5 year (more importantly, the evolution can be built against quite old gtk+, like 3.10.x, where this works properly there; will it be broken for older gtk+, when [if] I fix it for the latest gtk+?).
I'm re-closing this in favour of bug #766773. No need to reopen this, really.