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
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
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
(1) What zoom values do you see on your macOS system? Do they make
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
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.