| |
| |
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.
Welcome.
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 (
https://github.com/Albrecht-S/fltk/commits/MacOS_Gestures ) 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
#ifndef FL_ROTATE_GESTURE
#define FL_ROTATE_GESTURE=28
#endif
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
...
#else
case
FL_ROTATE_GESTURE:
...
case FL_TOUCH_GESTURE:
...
#endif
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 fltkcoredev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/38839b53-8e81-5e84-ac83-906c1d5b7535%40online.de.
[ Direct Link to Message ] | |
|
| |
