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 19:28 Oct 10 top right image
On Saturday, October 9, 2021 at 1:58:37 PM UTC-7 Albrecht Schlosser wrote:
Thanks, I took a quick look ... looks good, thank you very much!

I still need to test it though.

Thanks for checking it out.
I took a look into the Windows documentation you posted in another message. I couldn't resist and tried what I could get. Took me (way too many) hours but I'm now at a point where I get the gesture messages and I can interpret the data partly - not yet finished though.

This looks like a great start to me.   

The tricky part will be to integrate it with the FLTK event system (for now I'm only logging the messages) and to create the *correct* FLTK event data to have identical events and associated data on all platforms. Example:

Agreed, we want to make all platforms behave as much the same as possible to a FLTK developer / user. 

Of course the rotation angle must have the same units and orientation on all platforms etc..

How is the "rotation angle" on macOS defined? Is it relative (per event) or is it some kind of absolute angle? Clockwise or counter-clockwise? My observations on Windows seem to indicate that it's the absolute angle of the two fingers, 0° = "north", increasing counter-clockwise (more tests needed, I didn't find it in the docs - docs are AFAICT incomplete and confusing).

I believe the angle on MacOS is always a delta.  I'll have to dig back in to verify the sign convention.

BTW: after reading the macOS docs I believe that the zoom value issued on macOS by FLTK's FL_ZOOM_GESTURE event is not "correct" (whatever "correct" means here). The docs say you need to add 1 to the "magnification" value (you can still multiply with 1000). But what exactly is that value?

The pinch zoom also gave deltas 

Some questions:
(1) What zoom values do you see on your macOS system? Do they make sense?

I'll go back and set up a test program to look into this.  I needed some sign flips to make zoom work right on my machine -- but I'm feeding it into an OpenGL zoom parameter that may be counter intuitive.
(2) What hardware did you use?

I'm testing with my touchpad on my 15" 2017 MacBook Pro.
(3) I have a macBook Air with touch-/trackpad (no external device). Does it work with this config?

I would expect it should work with that.
I think here we have an issue with backwards compatibility. If I read your statements correctly (but this may be not the case) then "splitting" in different event types may be an issue. IIRC I used my built-in (macBook Air) touchpad with two-finger scrolling as a replacement for scrolling with the mousewheel - because I don't use a mouse with my macBook. If this would be "converted" to FL_SCROLL_GESTURE then it could break existing apps that rely on FL_MOUSEWHEEL simulation. But, again, this needs testing...

I agree, this will need to be addressed for compatibility.

In my (poor) testing, I was not seeing two finger scroll events coming through as useful mousescroll events (I must have been wrong).  So, I didn't think we were losing anything.

I think it is valuable to be able to have an application specify that it wants to treat a scroll gesture differently from a mouse wheel scroll -- while keeping the default the same for compatibility.  Are there examples in FLTK of specifying this kind of behavior?

You can define the env variable FLTK_SCALING_FACTOR=1.5 or similar before starting your program. Then all your FLTK programs should start zoomed by 150% and you could use cmd/+/- on a Mac to change scaling (ctrl/+/- on other systems).

OK, I wasn't sure it was _that_ scale factor.

On a screen-based touch system, it makes sense for the events to be somehow in 'pixels' -- but I have no idea what the scale is for a trackpad on a Mac.

Ideally, in a 3D manipulation program, if you use two-finger scroll for Pan, you would want the object to track with your fingers -- like you were physically moving it.  No matter the zoom level, etc. 

Do we have a 3D OpenGL test program?  It might provide a good example to make a test case out of.

We could also do a 2D version -- pan, zoom, and rotate some simple objects on a screen.  Perhaps an image manipulation, or a simple map interface.

Finally, as this adds some new event types, I am not sure how to add protections to existing applications that still need to be able to compile against older versions of FLTK that do not have these defined.

That's not an issue. Additional events are ignored by existing programs. But changing the semantics like changing a working event to another one (which would be ignored) is problematic (see my notes above).

I meant for the situation where my open source application is sometimes compiled by end users on old versions of FLTK bundled with Linux distributions.   I'd like for these cases to still build and work - even if they lose this functionality.

I suppose a simple


somewhere in my application will work.

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-2022 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to ''.