Mouse position on scroll event is set to -1

[wmcbrine]

Mouse position on scroll event is set to -1

[mannyamorim]

Thanks for taking a look at this guys. I know, I'm digging up some old code here. Since the original reason for this behavior seems to be forgotten/lost, I am recommending that we bring it inline with the behavior in ncurses. NCurses treats all of the mouse events as button presses and therefore it sends the actual coordinates.

I have a hard time imagining why an application would be relying on receiving a (-1,-1) when looking for mouse scroll events so I feel like this should be safe to merge without worrying about breaking existing applications.

Since I'm primarily concerned with the WINCON port I have submitted a PR for that port #91. However, as @Bill-Gray mentioned above it seems to be the same for all of the ports and it probably makes sense to change it everywhere.

The patch is only a few lines, so when you have chance, please let me know what you are thinking about it. Thanks.

[Bill-Gray]

I never liked the (-1,-1) coords, but assumed there was some backward compatibility issue. Since Mark doesn't recall one, I've decided to return the coordinates in my fork. If somebody reports things flying apart, we can go back to the (-1,-1) bit.

Note that I've only got WinGUI, X11, VT, and SDLn thus far, with the other platforms to follow. @mannyamorim, I'd appreciate it if you submitted your WinCon patch to my fork as well.
That'll leave me with DOS, DOSVGA, and OS/2. My mouse wheel is unrecognized on the first two, and I don't have OS/2, so I'll let those go for the nonce... the DOS fix looks obvious (and identical on both platforms), but I hate to make changes and say "of course it's going to work; I don't need to test it."

[wmcbrine]

Patched for SDL, X11, wincon, DOS.

[Bill-Gray]

This is not just a WinCon issue. All the ports do it. I think in all ports, it would be easy to report actual coordinates, as it would be here.

When starting my fork and adding new ports, I noticed this behavior, scratched my head, and said, "Well, I don't want to do anything that breaks expected behavior." But I can't really see how anybody would be relying on this (odd) behavior, and am considering changing it in my fork so that the actual mouse position is reported for all events.

[wmcbrine]

Perhaps @rexx-org can comment on the purpose of this feature, as it dates to his original addition of scroll wheel support in 2004. 5fff3d6

[rexx-org]

Sorry, I can't provide any insight into the rationale for these settings :-(

[GiorgosXou]

Any update on this issue? It happens to be something that I use on my TUIFIManager, as a range in which the mouse-events should take any action (not something really critical, but it would be nice to work just like with ncurses)