When in 3D view, scrollwheel inputs are sometimes registered twice

[iirelu]

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.

[novaplusplus]

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.

[man-of-eel]

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.

[eevee]

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.