On Wednesday, October 13, 2021 at 8:17:18 AM UTC-7 Albrecht Schlosser wrote:
The handling of FL_SCROLL_GESTURE had a
negative inherited from the FL_MOUSEWHEEL code -- since it
seemed quite counterintuitive for this use, I removed it there.
This one is tricky on macOS. You can use the system preferences for
trackball and mouse, respectively, to enable "natural scrolling". No
matter which one you use, both trackball and mouse are affected!
I would have expected that these are different settings, and
when I switched to "natural" my Mac did what I expected with the
trackpad but the mouse scrolling change was not expected. With this
*user preference* the sign of the scrolling delta is inverted
(again, in both cases). It's not yet clear to me which sign
convention we should apply taking this into account. Do (can) we
access the system preference to compensate this? Is it useful to do
so? I don't know.
I assume your setting is "natural" - please try to use your program
after switching "natural scrollling" off. Is it still intuitive? I
don't think so.
Yes, while I hated 'natural' when they first introduced it, I also hate using computers where people set 'weird' settings (swap L/R buttons, etc). So I forced myself to get used to it.
I'm sure these biases are particular to me -- when I was in high school, I did repair at a small computer store. Using random customer's computers made me appreciate default settings. Then much later in life, as a professor, I was reminded of this when I need to help students on their own laptop -- why can't everybody leave shift, alt, control, and return in the same place (within one language layout of course)....
I think trackpad scrolling (and eventually touch-screen) will need to be able to detect the 'natural' scroll setting. In a touch-screen environment, you certainly don't want to click-and-drag something and have it fly the wrong way...
Yep, that's great. Your addition is really helpful. Thanks. I pulled
all your changes into my own fork.
Great -- feel free to squash the mess down to something palatable for inclusion when the time comes.
It may not be practical to map all OS gestures to a common set of FLTK gestures. While that would be ideal (if all OS's supported a wide set of gestures), it would not be a useful feature if there is not a useful common set.
Should we map Windows one-finger Flick and MacOS three-finger swype to the same event? I say probably not. Although they could reasonably be used for the same purpose (say turning pages in a virtual book), what would we do if MacOS later supports a one-finger flick and Windows a 3-finger swype?
Another approach would be to add support for all OS supported gestures -- mapping common gestures to common events. That allows the application to decide to interpret flick and swype in the same way (or not).
I see this as analogous to the two-finger scroll being different from mouse wheel scroll -- it is nice for a default behavior for them to be the same -- but there is cool opportunity in separating them out.
Finally, one important note: please don't rely on this experimental
code for your "real" applications. I'm sure we will change the API
before we go into production (release). For instance, one major
change would be to add new Fl_event_*() accessor methods for a
better interface to gestures. Some of these variables obviously need
to be floats or doubles so the user doesn't need to divide by 1,000
or 100,000 or any other factor.
Understood.
Rob
