USER FORUM
(you are viewing a thread; or go back to list of threads)
inverted scrolling since GTK4 preparation (by freem)
Hello.
Since I no longer have a github account, I can not create an issue on the tracker nor a PR to get back to the behavior any person is likely to expect, with the exception of gnome developpers.
The issue is that since commit 31d0c27ecdc4ace0a1793191629d258cbd861826 "Handle smooth scrolling", the scrolling is *inverted*.
I did panicked when I noticed the "Prep for GTK4" issue on the tracker, because I know that every major version of gtk since gnome took control over it made things worst, making me remove as much gtk applications I can from my systems.
I have no problem if solvespace allows people to use GTK4, but please, I beg you, keep the gtk3 compatibility and default behaviors until some other toolkit is integrated in the master.
Since I no longer have a github account, I can not create an issue on the tracker nor a PR to get back to the behavior any person is likely to expect, with the exception of gnome developpers.
The issue is that since commit 31d0c27ecdc4ace0a1793191629d258cbd861826 "Handle smooth scrolling", the scrolling is *inverted*.
I did panicked when I noticed the "Prep for GTK4" issue on the tracker, because I know that every major version of gtk since gnome took control over it made things worst, making me remove as much gtk applications I can from my systems.
I have no problem if solvespace allows people to use GTK4, but please, I beg you, keep the gtk3 compatibility and default behaviors until some other toolkit is integrated in the master.
(no subject) (by Paul)
Can you describe what the exact behavior is? What does "smooth scrolling" mean? And then how is it inverted? What is reversed?
(no subject) (by freem)
> What does "smooth scrolling" mean?
You need to ask that to the commit's author, not to me.
> Can you describe what the exact behavior is?
> And then how is it inverted? What is reversed?
The original behavior, before this commit, that *any* (non-gnome, ofc) application I've seen so far (including blender, freecad, and other 3D drawing applications) will have, is that using wheel_down will zoom out, that is, your camera will move backward, the view will appear smaller, as if you moved your head backward.
Since this commit, intended to prepare an upgrade to gtk4, behavior is inverted between wheel_up and wheel_down.
This makes using solvespace very un-intuitive to me, and the behavioral change is probably not intended.
You need to ask that to the commit's author, not to me.
> Can you describe what the exact behavior is?
> And then how is it inverted? What is reversed?
The original behavior, before this commit, that *any* (non-gnome, ofc) application I've seen so far (including blender, freecad, and other 3D drawing applications) will have, is that using wheel_down will zoom out, that is, your camera will move backward, the view will appear smaller, as if you moved your head backward.
Since this commit, intended to prepare an upgrade to gtk4, behavior is inverted between wheel_up and wheel_down.
This makes using solvespace very un-intuitive to me, and the behavioral change is probably not intended.
(no subject) (by ruevs)
For cross reference:
The original pull request that proposed the change: https://github.com/solvespace/solvespace/pull/1464
The one I eventually merged: https://github.com/solvespace/solvespace/pull/1470
The original commit: https://github.com/solvespace/...c4ace0a1793191629d258cbd861826
and the one modified by me: https://github.com/solvespace/...807bc9d2c26a024bfc8083679ad2eb
The original pull request that proposed the change: https://github.com/solvespace/solvespace/pull/1464
The one I eventually merged: https://github.com/solvespace/solvespace/pull/1470
The original commit: https://github.com/solvespace/...c4ace0a1793191629d258cbd861826
and the one modified by me: https://github.com/solvespace/...807bc9d2c26a024bfc8083679ad2eb
(no subject) (by ruevs)
I don't have access to he Linux machine I did this on, but I did not notice the change "inverting" the scroll direction, and what is even weirder - looking at the code (on a phone) I do not understand how it could.
So if you use a version before these two commits the scrolling works in the opposite direction?
So if you use a version before these two commits the scrolling works in the opposite direction?
(no subject) (by freem)
> So if you use a version before these two commits the scrolling works in the opposite direction?
Exactly.
As said, reverting 2 commits "solved" the issue for me.
Exactly.
As said, reverting 2 commits "solved" the issue for me.
(no subject) (by ruevs)
Are you able to compile SolveSpace? If you can it would be interesting if you change this line:
https://github.com/solvespace/...e/src/platform/guigtk.cpp#L581
in the code to:
"delta = -dy;"
And see if it helps.
https://github.com/solvespace/...e/src/platform/guigtk.cpp#L581
in the code to:
"delta = -dy;"
And see if it helps.
(no subject) (by ruevs)
(no subject) (by ruevs)
(no subject) (by Paul)
Thank you @ruevs. After a long time away from Solvespace, I upgraded and updated my PC last night, built the latest version and confirmed this issue only to see your fix pending ;-) The scrolling behavior really did feel wrong!
Post a reply to this comment: