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

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   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? Albrecht Schlosser Oct 13, 2021 top right image
On 10/13/21 6:48 PM Rob McDonald wrote:
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...

As I was told Apple doesn't produce systems (MacBooks) with touch-screens. Are touch-screens supported by macOS? If not we won't know how to deal with them until Apple will produce and/or support systems with touch-screens. I'm saying this for a reason: if we design an API today it may be wrong in the future once touch-screens are working with Apple systems. Currently I know that my tests with my notebook's touch-screen worked on Windows.

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).

Well put, all good points. My conclusion from your writing is that we should indeed let "different things" be separate FLTK events. The one-finger-flick vs. three-finger-swipe argument is compelling.

For all new (and documented) events we can tell the user that they can and should handle FL_FLICK and FL_SWIPE events in the same 'case' statement, for instance. With a note that this may change in the future...

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.

Agreed. However this is a little different because of backwards compatibility. Currently all FLTK programs that handle FL_MOUSEWHEEL events continue to work with trackpad scroll events if these are mapped to FL_MOUSEWHEEL events. As soon as we separate them out programs need to be modified. That's why I think we need a backwards compatible way to deal with these two event types. Let's see ...

Here's a new idea (untested): we could first send an FL_SCROLL_GESTURE event and if this is not handled by any widget, send an FL_MOUSEWHEEL event. This way "new" programs can handle the FL_SCROLL_GESTURE event and "old" programs can still handle FL_MOUSEWHEEL events. It's similar to FL_KEYBOARD events that are converted to FL_SHORTCUT (if not handled) and finally to FL_SHORTCUT with flipped case. Does that sound sensible?

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
To view this discussion on the web visit
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-2023 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to ''.