Re: [fltk.coredev] Gesture progress for 1.4?

GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 All Forums  |  Back to fltk.coredev  ]
 
Previous Message ]New Message | Reply ]Next Message ]

Re: Gesture progress for 1.4? Rob McDonald 09:48 Oct 13 top right image
 
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. 

Yes, probably. My next step will be to add the Windows implementation. Once that is done we can see which sign conventions we should use and how "cross platform" compatible this all will be. Windows seem to call the swipe gesture "Flicks" if I interpret their docs correctly. It's hard for a non-native English speaker like me to interpret these gestures and the particular naming in the docs.
https://docs.microsoft.com/en-us/windows/win32/wintouch/windows-touch-gestures-overview

The macOS docs state: "Three fingers brushing across the trackpad surface in a common direction is a swipe gesture."
https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/EventOverview/HandlingTouchEvents/HandlingTouchEvents.html

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

 

--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/fa75d4d5-ab72-46dd-9ee4-aff47e8b53d0n%40googlegroups.com.
Direct Link to Message ]
 
bottom left image   bottom right image
Previous Message ]New Message | Reply ]Next Message ]
 
 

Comments are owned by the poster. All other content is copyright 1998-2021 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.