edgetx
edgetx copied to clipboard
EdgeTX
Simulator navigation issue with mousewheel
Is there an existing issue for this problem?
- [X] I have searched the existing issues
What part of EdgeTX is the focus of this bug?
Simulator
Current Behavior
In the simulation of a Horus X10 Express or TX16, the highlight always jumps over 2 menu items when you have rolled one step with the mouse wheel.
Expected Behavior
it should jump only one step.
Steps To Reproduce
- open Simulator
- enter the Systemmenü
- roll with mousewheel
Version
Other (Please specify below)
Transmitter
FrSky X10 Express / X10S Express (ACCESS)
Anything else?
testetd with 2.8 selfbuild commit 62692dba
Ah, good, it's not just me then. It's definitely a regression... 2.7 was fine, but 2.8 is doing the double step (I've been using the +/- keys on the keyboard when I needed it to not skip).
Ah, good, it's not just me then. It's definitely a regression... 2.7 was fine, but 2.8 is doing the double step (I've been using the +/- keys on the keyboard when I needed it to not skip).
I can confirm this too with W10 Companion built in simulator, Stand alone simulator won't accept mouse input as touch at all, see https://github.com/EdgeTX/edgetx/issues/2195
@pfeerick is it possible for you to fix this problem? I work with the simulator very often and it is a strong hindrance during testing.
I would if I could - I have no idea how this Simulator Companion stuff works. Nearest I can tell atm is for some reason
https://github.com/EdgeTX/edgetx/blob/7a06eb1d964e16e3d4efb1b576fdddf53b29d649/companion/src/simulation/simulateduiwidget.cpp#L164
is firing twice per scroll event - why it's firing twice I don't know, but that seems to be the culprit.
Any idea as to what has changed to do this @elecpower? I can reproduce this behaviour on a WSL2/WSLg environment, so seems universal to Windows and Linux. Or am I barking up the wrong tree, and simulator used to ignore/miss second event?
https://stackoverflow.com/questions/23248932/qt-qscrollarea-scroll-speed
Maybe this does help?
Just noticed that on the TX12 simulator it works fine - one step per wheel scroll step, so perhaps we should be looking more at the interface between LVGL and simulator... since AFAIK nothing actually changed in the main simulator code?
Just noticed that on the TX12 simulator it works fine - one step per wheel scroll step, so perhaps we should be looking more at the interface between LVGL and simulator... since AFAIK nothing actually changed in the main simulator code?
The main difference between both is:
- non-LVGL code accounts only for the direction of the encoder movement, not for the number of ticks.
This works without issue on real hardware, and is actually the way it is supposed to be. The question is really: why does the QT code generate the events twice? It seems this went undetected so far because of the way the rotary encoder driver is/was working on non-LVGL targets.
