GNOME Bugzilla – Bug 760569
Scrolls in the wrong direction (Mint17.3 Xfce)
Last modified: 2017-10-16 11:03:59 UTC
Under Xfce/Xfwm4 only, w/ Touchpad/ReverseScroll enabled.
Thanks for a bug report. Could you try the same with gtk3-demo application, please? These things are usually not handled by the evolution itself, but with a lower library, like gtk3. By the way, if you mean with that cryptic description that you have setup to use ReverseScroll, isn't is expected that the scroll will work in an opposite direction than you you "scroll" with the touchpad?
Thank you for your reply. Indeed, gtk3 -help, for example, has the bug; I will report it to them. BTW, same behaviour if, instead of using Xfce GUI to set up natural scrolling, I do xmodmap -e "pointer = 1 2 3 5 4 7 6 8 9 10 11 12" Other programs (firefox, thunar, and even gimp) scroll appropriately. Looks like some functions of gtk work and others don't.
Thanks for the update. I can pass this bug report to gtk+, it's very easy here.
(In reply to Eric Polin from comment #2) > Other programs (firefox, thunar, and even gimp) scroll appropriately. Looks > like some functions of gtk work and others don't. As it might be relevant, those other programs would have been using GTK+ 2, not 3, at the time this comment was written. Only Firefox has gained a released GTK+ 3 version since then. I'm still not sure about the problem. It certainly should not be specific to Evolution, rather GTK+ 3. And GTK+ should just pick up your system's setting for scrolling. If it does not get that, then the problem might be in the XFCE settings manager that you used to apply the scrolling type.
Still there on Evolution v3.18.5.2: the inbox, preview, msg detail all scroll in direct direction although reverse scrolling box is checked (http://docs.xfce.org/xfce/xfce4-settings/mouse). Workaround: reverse at the low-level instead synclient | grep ScrollDelta synclient VertScrollDelta=-<formerValue> HorizScrollDelta=-<formerValue> This is ideally what the reverse direction should do, instead of acting at some higher and less universal level in the layers of the GTK or other part of the GUI. I agree this is an XFCE issue. Also agree that Evolution seems to use some specific or older GTK widgets that plug at a lower level than the ones used in most other applications, below the layer where the reverse scrolling is handled by that checkbox. LSB Version: core-9.20160110ubuntu0.2-amd64:core-9.20160110ubuntu0.2-noarch:printing-9.20160110ubuntu0.2-amd64:printing-9.20160110ubuntu0.2-noarch:security-9.20160110ubuntu0.2-amd64:security-9.20160110ubuntu0.2-noarch Distributor ID: LinuxMint Description: Linux Mint 18.1 Serena Release: 18.1 Codename: serena
(In reply to Eric Polin from comment #5) > Also agree that Evolution seems to use some specific or older GTK widgets > that plug at a lower level than the ones used in most other applications, > below the layer where the reverse scrolling is handled by that checkbox. That's true. Evolution has several custom widgets. Not every has a comparable replacement in gtk+ stack, unfortunately.
I'm still not sure that there is a bug on the GTK+ side here. (In reply to Eric Polin from comment #5) > Workaround: reverse at the low-level instead > synclient | grep ScrollDelta > synclient VertScrollDelta=-<formerValue> HorizScrollDelta=-<formerValue> Of course, this only works on the synclient driver, but nowadays libinput is gaining ground. > This is ideally what the reverse direction should do, instead of acting at > some higher and less universal level in the layers of the GTK or other part > of the GUI. I agree this is an XFCE issue. It would be instructive to check what the XFCE setting does. Perhaps then the bug is really on their side, i.e. they might need to be more inclusive when setting natural scrolling. > Also agree that Evolution seems to use some specific or older GTK widgets > that plug at a lower level than the ones used in most other applications, > below the layer where the reverse scrolling is handled by that checkbox. I still think GTK+ just works with whatever scroll events it's given, which are already inverted or not, by the time it receives them. Didn't you already prove that by seeing the same issue in the upstream GTK+ demo, thus ruling out any effect of Evolution's custom widgets?
In fact, here's a bug report at the XFCE side, still open: https://bugzilla.xfce.org/show_bug.cgi?id=11193 other workarounds are suggested there, including for users of libinput. Given that it's still open, it does seem like XFCE acknowledge it as a problem on this side, and equally that they don't feel it's something to be blamed on GTK+. :P
Thanks for spending your time on this bug report and finding the upstream bug for it. I'd say the proper resolution for this bug is NotGNOME now, right?
It seems that way: I believe the canonical answer here is https://bugzilla.gnome.org/show_bug.cgi?id=674716#c13 See also Bug 761447, which is effectively identical to the present one and which was also marked as a duplicate of the above. *** This bug has been marked as a duplicate of bug 674716 ***