MP2 - V2.1 Mouse wheel scrolls 2/3 rows at time, instead of one, in EPG (1 Viewer)

[The Solutor]

:

Description
Looks like the mouse wheel events are taken at the wrong level, so the EPG screen behaves like Office where the 2/3/4 rows per click are a common and meaningful option.

Instead, doing that in EPG, is just misleading/frustrating, both because not logical, and also because non in line with what happens in MP1/WMC/Kodi and whatever.

Steps to Reproduce:
Open MP2 go to the EPG page and turn the MW

 

[Brownard]

Mouse wheel scrolling in MP2 uses the global Windows setting for the number of lines to scroll therefore you should see the same behaviour in all scrollable 'lists' inside MP2 and it is at least consistent with Windows and every other screen in MP2 . It would actually be very straightforward to override this setting in the EPG grid (change 1 line of code) but we'd probably need a good justification to do so.
On Win 10 at least, the Windows setting is found under Control Panel -> Hardware and Sound -> Devices -> Mouse -> Wheel -> Choose how many lines to scroll each time.

 

[The Solutor]

Mouse wheel scrolling in MP2 uses the global Windows setting for the number of lines to scroll

Indeed that's the bug I'm talking about.

therefore you should see the same behaviour in all scrollable 'lists' inside MP2 and it is at least consistent with Windows and every other screen in MP2 .

Not correct.

The home menu, for example, scrolls (correctly) one row at time.

It would actually be very straightforward to override this setting in the EPG grid (change 1 line of code) but we'd probably need a good justification to do so.

Fixing an annoying bug seem a good reason to me.

Doing it with just one line of code makes it look even better.

Making MP2's behavior in line with MP1, WMC, kodi, and so on would be another good one.

On Win 10 at least, the Windows setting is found under Control Panel -> Hardware and Sound -> Devices -> Mouse -> Wheel -> Choose how many lines to scroll each time.

That setting is there since the day one of mouse wheels (aka 1997 or so) and was even backported in Win31 which was still alive and kicking at the time.

That setting must be ignored by any SW where that setting becomes an annoyance, no matter if we are talking about the speeddial of a browser or a 6 foot interface in a TV program.

If you really like to scroll multiple rows inside MP2, just add a MP2 only setting. Taking the system wide value is just pointless.

 

[Brownard]

Wrong.

The home menu, for example scrolls (correctly) one row at time.

Indeed, I'll concede that one, but you'll struggle to find other examples
The reason it's only 1 in that case is because it would otherwise be unusable as only one row is focusable at a time (and it's implemented differently to most other lists behind the scenes).

Don't get me wrong, i don't really have strong feelings either way. Its just the first time I recall it being raised and I'd be reluctant to change it based on 1 person's request.

 

[The Solutor]

@Brownard

Don't get me wrong either.

But a long time overlooked bug is still a bug, and no this isn't a MP2 bug alone, practically any SW was plagued by inconsistencies in MW scrolling especially in early days of MWs, and in linux where different desktop environments further complicated the matter.

Back to MP2, likely no one cared about that detail, because many considers the mouse input as a second class citizen, and most of the efforts are focused on remote support. (IMHO a mistake who greatly reduced the usage of MPx over WMC, which is consistent and mouse friendly since the day one)

I call this "input method racism", which is something that should be avoided.

Do you like another evident (unrelated to MP) example?

The removal of the GO button on many address and search fields that is happening lately.

That forces the keyboard use just to push a single key (ENTER) on an otherwise mouse only operation, it's just crazy but it's a trend followed by many in the sake of simplification and clean look.

 

[Brownard]

But a long time overlooked bug is still a bug

I understand what you are saying but it's not a bug, it's by design. Someone (before my time) has made an explicit decision in the code to use the Windows setting.

 

[The Solutor]

All matter of (not so relevant) semantic.

IMHO bug aren't just coding mistakes and typos, wrong decisions are bugs as well. In short when "intended" and "expected" doesn't overlap you get a bug. Call it logical bug, design bug, whatever you like, it's still something that needs to be fixed to adjust the program.

And to be clear I'm not "blaming" you or everyone else for this, just you are doing your coding duties, I'm doing my bug hunting/quality control ones. Helping each other is the point.