| |
| |
On 10/13/21 2:20 AM Rob McDonald wrote:
On Tuesday, October 12, 2021
at 3:13:23 PM UTC-7 Albrecht Schlosser wrote:
On
10/12/21 7:13 PM Rob McDonald wrote:
> https://github.com/ramcdona/fltk/tree/MacOS_Gestures
Yep, found it. The only "real" issue is in draw(): you're
pushing the
matrix at the wrong place in the code. You need to move
'fl_push_matrix();' up before 'fl_translate(...);' and it
should work
... with some minor issues. Cute!
That would have taken me a long time to figure out --
drawing the first time works, but I suppose it quickly
out-runs the stack depth of 4 and stops working...
Hmm, not really. You can imagin fl_push_matrix as "save" and
fl_pop_matrix as "restore" functions, respectively. There was
nothing wrong with the stack (which is, BTW, 32 matrices deep, not
only 4) because you used push and pop correctly in pairs. But you
used transformation calls before you saved the current matrix and
these transformations accumulated.
FLTK's fl_rotate() is positive CCW
whereas FL_ROTATE_GESTURE is positive CW. The sign flip is
expected.
OK, I see.
The handling of FL_SCROLL_GESTURE had a
negative inherited from the FL_MOUSEWHEEL code -- since it
seemed quite counterintuitive for this use, I removed it there.
This one is tricky on macOS. You can use the system preferences for
trackball and mouse, respectively, to enable "natural scrolling". No
matter which one you use, both trackball and mouse are affected!
I would have expected that these are different settings, and
when I switched to "natural" my Mac did what I expected with the
trackpad but the mouse scrolling change was not expected. With this
*user preference* the sign of the scrolling delta is inverted
(again, in both cases). It's not yet clear to me which sign
convention we should apply taking this into account. Do (can) we
access the system preference to compensate this? Is it useful to do
so? I don't know.
I assume your setting is "natural" - please try to use your program
after switching "natural scrollling" off. Is it still intuitive? I
don't think so.
I've updated my branch with all these
fixes together. It makes for a little 2D app that responds in
all the ways I would want it to -- rotate, pan, zoom.
Yep, that's great. Your addition is really helpful. Thanks. I pulled
all your changes into my own fork.
It looks like MacOS and Windows both also support a swype
gesture -- I hadn't looked into it because I don't see a use
in my application. However, as long as we're at it, we should
probably be complete.
Yes, probably. My next step will be to add the Windows
implementation. Once that is done we can see which sign conventions
we should use and how "cross platform" compatible this all will be.
Windows seem to call the swipe gesture "Flicks" if I interpret their
docs correctly. It's hard for a non-native English speaker like me
to interpret these gestures and the particular naming in the docs.
https://docs.microsoft.com/en-us/windows/win32/wintouch/windows-touch-gestures-overview
The macOS docs state: "Three fingers brushing across the
trackpad surface in a common direction is a swipe gesture."
https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/EventOverview/HandlingTouchEvents/HandlingTouchEvents.html
Finally, one important note: please don't rely on this experimental
code for your "real" applications. I'm sure we will change the API
before we go into production (release). For instance, one major
change would be to add new Fl_event_*() accessor methods for a
better interface to gestures. Some of these variables obviously need
to be floats or doubles so the user doesn't need to divide by 1,000
or 100,000 or any other factor.
--
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/8ea73100-2f85-b0b6-056e-516fe81427a6%40online.de.
[ Direct Link to Message ] | |
|
| |
