Re: [fltk.coredev] Gesture progress for 1.4?

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? Albrecht Schlosser 11:14 Oct 11 top right image
On 10/11/21 4:28 AM Rob McDonald wrote:
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.

Yes, once the event recognition works and you know what kind of info the OS provides with the system events the rest is straight-forward.

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.

Thanks for all your input, this is very helpful. I'm only commenting on parts of it but I considered the rest as well.

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.

If you are already doing this, could you please post the source code here? Otherwise please drop me a note and I'll do it myself (I'd like to avoid duplicated work).

Note that I modified the zoom value in my test environment in two ways:
 - add 1.0 to the raw zoom value as described in the macOS documentation (why could they not do this???)
 - multiply zoom and rotation by 100,000 rather than 1,000 for better granularity (this will be obsolete with the "new" event variables)

Adding 1.0 to the raw zoom value is essential and a bug fix (the 1.3 implementation got it wrong).

In the future I'll add new float/double Fl::event_* variables for gestures so the user doesn't need to "convert" the Fl::e_dy() value to something usable.

Please try my modified code ( ) and let me know what you think about it. See also the commit message about other changes (I also fixed indenting partly which I didn't document).

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?

FLTK has the Fl::option() interface but this is something I'd like to avoid here.

I'm thinking of some new Fl::event_* variables we'd better use for these new events, maybe a struct that can hold all necessary information. This could have a flags member with such info. Or something totally different, maybe. Still thinking...

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.

Let's first think of a basic FLTK (2D) test program. This is necessary for demonstration of the functionality and to get things right.

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.

Yep, something like that. I was thinking of "some simple objects" which you can move, zoom and rotate (and pan the entire scene).

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.

Ah, yes, I didn't think of that, but that's of course important.

I suppose a simple


somewhere in my application will work.

I'd rather disable the entire part which wouldn't work if you want to be compatible with both FLTK 1.3 and 1.4, for instance in handle() like this:

  switch(event) {
    case FL_PUSH:
#if FL_API_VERSION < 10400
    case FL_ZOOM_GESTURE: // only in FLTK 1.3

I'm assuming here that the old (1.3) version would deliver the data different than the 1.4 version. Using Fl::event_dy() etc. is likely not what we want in 1.4. However, there's no decision yet, this is only a potential example. I'm working on a better (and compatible) solution.

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