Feature request: Clear mouse wheel buffer when leaving current window

[UselessGuru]

Mouse used is Logitech MX Master 3 with a free spining mouse wheel.

Scenario:
I fast scroll using the free spinning wheel in one window, e.g. Chrome.
Then I move the mouse pointer to another window, e.g. Word, without activating the Word window.
Because the mouse wheel is still spinning, text in Word get scrolled too. This is not what I want.

Request / Idea:
I'd like a feature where the scroll buffer gets cleared (or any current scroll events get discarded) as soon as I leave the original window (where I started scrolling) until I scroll again.

Any ideas?

[phil]

My thoughts are that it wouldn't be easy, because as far a I know, you can clear the windows mouse buffer, the best that could be done, off this top of my head would simply be to ignore the messages after switching windows - possible but could lead to difficulties, like when do you stop ignoring them!

[UselessGuru]

... would simply be to ignore the messages after switching windows - possible but could lead to difficulties, like when do you stop ignoring them!

The free spinning wheel can be stopped by holding the wheel, so no scoll events are fired anymore. This could be used to re-allow events.

How about:
1. Detecting when window is left
2. Ignore all scrolling events that occur faster than every X ms (while wheel is spinning)
3. Start accepting scrolling events again when they occur less than every X ms (after wheel got stopped)

[UselessGuru]

Any news on this idea?

[phil]

No update, I really havnt had any time for XMBC in the last two years.

[UselessGuru]

Any news on this idea?

[phil]

sorry, see previous reply...
You may have noticed, only on release since your last message - things move very slowly here these days - far too much going on away from my computer (well away from having spare time to develop my own hobbies)

[UselessGuru]

Any news on this idea?

[phil]

Not really, in fact I don't think its even possible, because

a) if the wheel is indeed still spinning (or perhaps the driver is still sending events), flushing a buffer wont help because it will continue to fill up after flushing it.

b) As I previously mentioned, there is not way to "flush" the buffer (at least, not from the user level that XMBC operates at).

The best that could be done, is something along the lines that you proposed. Some way of ignoring (swallowing/blocking) future fats messages, for a period of time. Of course, its going to be quite device/machine specific (and to some extent XMBC already has some rudimentary, un-configurable way of doing this). It would need adjusting to be more aggressive when changing windows (or profiles) and configurable in the GUI (probable the global settings as I guess it applies everywhere, maybe irrecoverable at the profile level. The GUI work is a lot more painful than the engine work generally) so minimizing that would be good (especially with only one person actively interested in the feature - sometimes I just stick settings in the XML file rather than the hassle with the GUI).

It would still risk the effect happening, or worse still, blocking wanted actions, so its not something that can just be always on for all users. I often move my mouse quickly and intend to scroll the target window (for example). But then my mouse is also not free-spinning (hate those - perhaps for this reason!) so maybe that wont be a problem, if the scroll events are not fast enough. Im curious to know the rate of the scroll messages (how many per second are you seeing when this happens. If you enable debug logging, it might actually give you away of seeing that (as all messages are logged) but it might also slow it down a bit so it may not be precise.

I believe I put this on the list of things to look at adding in 2.22 beta, but I still haven't got 2.21 released - its still going through the slow process of bug fixes etc. Its almost there (and I'm not putting any new functionality into XMBC until 2.22 beta). As I said before, things are moving very slowly around here. And potentially due to health concerns, things may be moving very much slower in the future - from me at least - I hope not of course, but I'm not sure I will have much say in that

Regards,
Phil