On Wednesday, October 13, 2021 at 1:58:14 PM UTC-7 Albrecht Schlosser wrote:
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.
Agreed. I expect that someday Apple will support touch screens.
I don't have a touch screen Windows machine -- I'm glad that you have such a machine to test on.
I have used various forms of SMART Boards in the past -- a multi-touch surface paired with a monitor or projector. These usually send one-finger events as a mouse (movement, click, click-n-drag) -- or if special software is loaded, as proprietary events. I haven't used one of these in years, but if I was marketing one for MacOS today, I would set it up to work with existing gestures. In short - there may be a way to plug a touch screen into a Mac that isn't official Mac hardware.
These devices are commonly used in educational settings, but are also great for any collaborative / creative work environments (think two people standing at an interactive touch whiteboard). I've used them successfully doing collaborative design reviews with 3D CAD.
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
Agreed -- and you guessed my preference too.
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 ...
Compatibility is merely a matter of foresight. If we make them the same event now and want to change it later, we then have a compatibility problem (:
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?
Devious and clever -- I never would have thought of this.
If that works, I think it will be a great solution.
Under all circumstances, I think a "real mousewheel" should always send "real mousewheel" events. I.e. we should differentiate the event type - only send gesture scroll events if the OS event originates from a non-mousehweel source -- then re-send as a mousewheel if nothing down the line handled the gesture event.