SLADE
SLADE copied to clipboard
When in 3D view, scrollwheel inputs are sometimes registered twice
SLADE Version: 3.2.0 beta 1 Operating System: Linux
Issue Details: When in 3D mode, scrolling to raise/lower floors/ceilings ends up moving them by 8 units twice, instead of just once. The output in the top left confirms this, as it looks like this after repeatedly scrolling down one notch and scrolling up one notch:
The keyboard shortcuts assigned to the same task do not suffer from this problem. Pressing Numpad Plus and Numpad Minus only raises/lowers once, as expected. Other scrollwheel inputs outside of 3D view, like zooming and scrolling, also work fine.
Sorry if I'm putting this in the wrong place, I don't get out into the public part of github much... (originally posted in #1246 but this is the one that's open so I moved my post over here)
I also am on Kubuntu (21.04) and have been recently annoyed by this issue myself, and have been poking at it since I've been playing with the source a bit too. It really seems like wxWidgets is just putting out two near-simultaneous mouse wheel events, but I am utterly unfamiliar with wxWidgets so that's about as far as I can take that thought.
As a super sloppy workaround, I just added a variable to keep track of the last mouse wheel event time (from app::runTimer()), and ignore any that are too close together. I also made it log the delta time between wheel events and as you can see the second one usually happens within <10 ms(?) of the previous, usually small enough to report as 0.
At least here, it definitely doubles up ALL mouse wheel events though, not just in the 3D view.
I don't know if any of this will be of any use, but I figured I might as well report it for the 17 whole SLADE linux users out there affected by this problem.
For me (Ubuntu 18.04) it registers once as it should but only the first time I move the wheel down after entering 3d view, AND if the floor/ceiling height is adjacent to another (i think?). Every subsequent movement registers as two.
I reproduced with a minimal app, so this is definitely a wxGTK bug. Filed wxWidgets/wxWidgets#23383.
FWIW with the workaround, you don't need to fudge it with a delta; e.GetTimestamp()
appears to be exactly the same between both firings, every single time.