Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Win generate mouse wheel events #461

Merged
merged 5 commits into from Dec 27, 2019

Conversation

nicolas-cellier-aka-nice
Copy link
Contributor

This let windows VM generate mouse wheel events if asked to do so
OSX and linux already do that.

Those hacks were workaround for lack of support of mouse wheel events in the 90s from M$ OSes.
I'm glad to remind that it's 2020 in a few days, not 1999 anymore, so YAGNI.
We do not support those OS for quite some time, and we should stop bothering.
See https://devblogs.microsoft.com/oldnewthing/20080806-00/?p=21353 for a bit of history
Now that we simplified the obsolete logic, there no reason to handle this message differently from others
as recommended here: https://docs.microsoft.com/en-us/windows/win32/inputdev/wm-mousemove
`(int)(short) LOWORD(lParam)` is OK, but `LOWORD(lParam)` is not because position can be signed in case of multi-monitor
Note that this VM parameter is saved in the image and controlled via `Smalltalk sendMouseWheelEvents: true.`

WARNING: unlike Unix and OSX, fill both `buttons` and `modifiers` fields of the event structure.
Unix and OSX only fill `buttons` field with modifiers states! (???) I'd rather change the others.

Note: with my MacBook trackpad, there are many events generated with small scroll deltas (not multiple of 120, but down to 1 unit...)
I don't know why, but it gives sluggish scroll behavior, which does not happen when we emulate via arrow keys.
On some devices (example Mac trackpad), many events are generated with small deltas.
This is overwhelming the EventSensor loop at image side to the detriment of user experience.
Workaround by letting the VM accumulate those deltas until they reach a threshold before delivering.

In case of high delta values, we generate a single value.
It's up to image side to handle those values
(until now, Squeak 5.3 just ignored them, VM is not to be blamed for that).

Note: 2 values are hardcoded for now
- the timeout for stopping accumulation (500ms)
- the threshold for delivering the event to the image.

The threshold could have been WHEEL_DELTA, but it gives bad sensitivity on my own device, so use only a fraction of that in the hope that it fits other devices too.
Please report if those tuning are inappropriate. We may add parameters in the future if necessary...
@nicolas-cellier-aka-nice nicolas-cellier-aka-nice deleted the win_generate_mouse_wheel_events branch December 28, 2019 13:18
hogoww referenced this pull request in hogoww/opensmalltalk-vm Dec 23, 2021
hogoww referenced this pull request in hogoww/opensmalltalk-vm Dec 23, 2021
… ] on method [ hashBitsOf: ] SURVIVED 20/20 test cases.
hogoww referenced this pull request in hogoww/opensmalltalk-vm Dec 29, 2021
hogoww referenced this pull request in hogoww/opensmalltalk-vm Dec 29, 2021
…hod [ freeTreeNodesDo: ] KILLED by 1/234 test cases.
hogoww referenced this pull request in hogoww/opensmalltalk-vm Feb 26, 2022
…oat value ] on method [ popObjStack: ] 14 test cases.
hogoww referenced this pull request in hogoww/opensmalltalk-vm Feb 26, 2022
…at value ] on method [ popObjStack: ] 14/14 test case are EQUIVALENT
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant