Topic: mousewheel event handling

tothxa Topic Opener Joined: 2021-03-24, 12:44 Posts: 484 OS: antix / Debian Version: some new PR I'm testing Tribe Member	Posted at: 2021-08-18, 21:30 I have some ideas for wheel handling that need changing what arguments are passed to handle_mousewheel. I'd like to ask for feedback on them. My changes in https://github.com/tothxa/widelands/tree/mousewheel (see https://www.widelands.org/forum/topic/5349/) will often check for modifier keys, sometimes in more than one place until the final handler is reached. So it may make sense to call SDL_GetModState() before the handlers and pass the modstate to them. Though this would mix keyboard and mouse handling… SDL reports the global setting of whether the wheel direction is flipped with each event, but it is not passed to the handlers. I think it would make sense to "unflip" the wheel direction when the wheel is not used for moving the window contents. So the reported y/x values would be used in multilinetextarea, scrollbar and map movement. But I think flipped scrolling is completely wrong in the case of tabpanel, slider and spinbox, so these could use the currently omitted information to correct the direction. Though I'll make all of them invertible as per https://www.widelands.org/forum/post/37785/ but if the system setting would be passed to the handlers, then the default behaviour would be correct in most cases for most users. I can't test the use of the `which` argument (the SDL mouse instance ID), because it's always 0 on my system (Xorg with /dev/input/mice), even if I plug in multiple mouses besides the touchpad. SDL documentation doesn't help much, other than that "touch devices" (seems to be only touchscreens) have a special ID… In current master some places only handle wheel events for `(which == 0)` (e.g. map zooming), while others ignore it (e.g. scrollbar). Is there any reason for this difference? Maybe touchscreen support will make it necessary to ignore `(which == SDL_TOUCH_MOUSEID)`, but then probably in all cases, so no need to pass it down to handlers, just move on in the event loop. But is there any other use for this? Top Quote

Nordfriese Joined: 2017-01-17, 18:07 Posts: 2055 OS: Debian Testing Version: Latest master One Elder of Players Location: 0x55555d3a34c0	Posted at: 2021-08-19, 11:12 If you need more parameters to be passed down the event handling hierarchy, feel free to add them. The only downside of any such change is that you'll need to update the definitions of the respective handlers in all overriding classes, which can be a tedious task, but if you don't mind doing that go ahead Flipped scrolling: Sounds good to me, but this should be commented on by someone who uses it, I hate that system setting which: No idea what this does or why we check for it… Top Quote

tothxa Topic Opener Joined: 2021-03-24, 12:44 Posts: 484 OS: antix / Debian Version: some new PR I'm testing Tribe Member	Posted at: 2021-08-19, 18:51 Thank you for the answers. Yes, I figured I'll have to update all handlers, but I tried hard to find them and I still think that all of them are in UI elements derived from panel. There were only 9 of those, and I already touched most of them (and added a few more). I'll try to hunt down when `which` was added. Maybe there will be some explanation… But it seems that none of the other mouse events pass it down, even though all SDL mouse events have this field. I'm too old school for flipped scrolling too. (and they even call it "natural scrolling" in xinput… kids these days… ) Anyway, it would be nice if I could get comments from others for my other questions as well… Top Quote