FLTK logo

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? Albrecht Schlosser Oct 12, 2021  
 
On 10/12/21 9:41 AM imacarthur wrote:

On Saturday, 9 October 2021 at 21:58:37 UTC+1 Albrecht Schlosser wrote:

Note that the two WM_MOUSEHWHEEL messages at the beginning of the log are really that. However, I don't know where exactly the other ewo interspersed WM_MOUSEHWHEEL messages came from. I think that's a Windows "feature", some gestures are sent as normal mousewheel events for backwards compatibility (more tests required).


Yes, from the subsequent discussion, it does seem very likely that the WM_MOUSEWHEEL events embedded in the GID_ZOOM stream may well be there to support legacy applications.
And therefore... do we need to do something analogous in our gesture event handling...?

Yes, I think so.

Windows gesture support in general is documented here:
https://docs.microsoft.com/en-us/windows/win32/wintouch/windows-touch-gestures-overview#gestures-overview

The MS docs on "Legacy Support" can be found on the same page:
https://docs.microsoft.com/en-us/windows/win32/wintouch/windows-touch-gestures-overview#legacy-support

Interesting part: "The pan gesture maps to using the scroll wheel: WM_VSCROLL, WM_HSCROLL".

We don't handle these messages currently but I'm pretty sure I saw (vertical) WM_MOUSEWHEEL and (horizontal) WM_MOUSEHWHEEL messages originating from pan gestures. I'll check that out.

On macOS the system handles the pan gestures by sending  "mousewheel" events but, as Rob discovered and proposed in his patch, you can distinguish pan gestures from real mousewheel events and you *can* create different FLTK events. I think we need to keep the "legacy" behavior (FL_MOUSEWHEEL) but we can maybe add a flag so user programs know the origin (if necessary).

Another possibility would be to call an FLTK method that sets an option how to deal with such messages. Old programs that don't call this would get the "legacy" messages, new programs could opt in to use the "new" (gesture) messages. Or something like that. However, I wouldn't want to do that and I'm looking for a better way.

--
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/cce340ce-6bf1-2b2d-7152-29056e543e55%40online.de.
Direct Link to Message ]
 
     
Previous Message ]New Message | Reply ]Next Message ]
 
 

Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.