|
|
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 fltkcoredev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/79ad888d-3521-f6d3-7b6a-ee177499382f%40online.de.
[ Direct Link to Message ] | |
|
| |