Invert scroll direction if "natural scolling" is used

[cg505]

Scrolling on a laptop touchpad can use "Traditional" or "Natural" mode:

The "natural" mode works quite well for scrolling content, e.g. webpages, especially when super-precise smooth scrolling is enabled.

However, it also inverts the scroll direction for this extension, which means that the volume increases when you pull down your fingers, which doesn't make much sense.

Complicating the issue: I also often use a mouse with my laptop, and I don't want that to be inverted! It already works correctly. So ideally the logic is:

• Check if the scroll event is coming from a touchpad or a mouse. If coming from a mouse, use current behavior.
• If coming from a touchpad, check if natural scrolling is enabled. If yes, invert the scroll direction. Otherwise use current behavior.

The traditional/natural scrolling can presumably be read from wherever GNOME stores that setting. I'm not sure how to detect if the scroll input is coming from a touchpad or mouse. I spent some time trying to find documentation on the scroll-event signal but my lack of experience here was showing. There may be some metadata on event that we can use, but I wasn't able to find any conclusive docs on this.

I'd be glad to put in some more effort on making the code change here given some pointer from a maintainer.

[Moon-0xff]

This is not the first time this issue is raised (#89).
Though, as you are using the Natural (Reversed) setting and you also notice the scroll direction is reversed. Perhaps it's indeed reversed.
We are just following gnome-shell's volume widget behaviour (scroll direction), so it seems like a problem with gnome-shell itself.

I wanted to say that you should raise an issue there, but it seems like it would be a duplicate of this issue, which points to another issue on GTK.
I guess we shouldn't fix it ourselves?
Let me know what you think, or if you are able to get more info on this "bug" (or anyone else for that matter).

[Moon-0xff]

Regarding the logic you laid out: It seems like the way it should be done, perhaps adding an option to enable it regardless if natural scrolling is being used or not.

As I mentioned before, I'm not sure if this is the project where to implement it though.

[cg505]

Wow, thanks for the pointer. Sounds like a mess. It is indeed true that this behavior is mirrored by scrolling on other UI elements that do not move (e.g. the volume slider in top right settings dropdown). I voted for the issue in the gtk repo but I definitely do not have the experience to tackle that.

That said, mpris-label is by far the thing I scroll on the most besides my web browser, so I'd personally like to fix it even if ideally it would be fixed upstream. If we don't have enough information in the scroll event to tell whether natural scrolling is being applied it may not be possible though.

[cg505]

Do you know if scroll-event signal is documented anywhere? I could try to play with that.

[cg505]

I was able to figure out how to get it in lg so I see it's a clutter event. I also found the clutter reference. I will see if this is possible.