FLTK logo

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? Rob McDonald Oct 13, 2021  
 
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 the future...

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.

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/a2ccd39f-196d-4e9a-81a7-cd2f001078aen%40googlegroups.com.
Direct Link to Message ]
 
     
Previous Message ]New Message | Reply ]Next Message ]
 
 

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