Open sprite-1 opened 5 years ago
This might be relevant: https://github.com/elementary/wingpanel-indicator-sound/pull/94
This is because "natural scrolling" only makes sense for the vertical axis but is being applied to both.
Can you clarify on that a bit more? IMO using two fingers on the touchpad and dragging left or right should still simulate a "touch" experience whether it's vertical or horizontal in scrolling because that's how it would have behaved on a touch-screen interface as well (which I believe is the basis for "natural scrolling")
I mean that horizontal scrolling should always be "natural".
Could you confirm whether dragging the view (not the scrollbar) left and right using the touchpad has the expected effect? I think scrolling on the scrollbar itself is handled by Gtk not Files but I need to check.
Do you have the natural-scroll setting on or off?
I'm not in front of my computer.right now but I have natural scrolling disabled for mouse which is where I'm experiencing the issue in question
So is the issue that the horizontal scrolling is incorrect under these circumstances?:
As far as I can tell from the code, these events are handled by Gtk not Files.
So is the issue that the horizontal scrolling is incorrect under these circumstances?:
Yeah
As far as I can tell from the code, these events are handled by Gtk not Files.
That's interesting then because everywhere else that I have seen, the behavior is the opposite of that, so does that mean they all implemented their own scrolling handler?
Which app(s) are you using for comparison? Certainly in the case of the wingpanel sound indicator we had to use our own handlers to get the wanted behaviour.
If I remember correctly; Chrome, Sublime Text 3, and Epiphany
In Epiphany, which is the only Gnome app mentioned, however I am unsure it uses Gtk. The direction the horizontal scroll bar moves depends on the "natural scroll" setting. It moves to the right on a down mouse scroll without natural-scroll but moves to the left with natural scroll on. However, the appearance of the scrollbar differs from Files and from Gedit, which I believe also uses Gtk. The behaviour of the Files horizontal scrollbar slider with respect to mouse vertical scrolls seems to be the same as GEdit - that is, down == left (no natural scroll) and down == right (natural scroll).
Tbh I am not sure this is worth adding extra complexity to the code for; if using a mouse the best way is to drag the slider. If using a touchpad, you can scroll the view directly (in a natural fashion regardless of the natural scroll setting).
Anyway it needs to be defined very clearly what the expected behaviour is for each of the several ways to scroll the view for both natural scroll settings and for both devices.
If you hover the cursor over the bottom horizontal scrollbar for column view (Ctrl + 3), it is scrolling at the opposite direction.
Everywhere else, if there's a horizontal scrollbar, a scroll downwards should move the scrollbar to the right and a scroll upwards should move it to the left You can even see this behavior in Files itself by holding down Shift and scrolling. Yet, if the cursor is directly on top of of the scrollbar at the bottom, the action is reversed.