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 16:53 Oct 13 top right image
 
On  10/13/21 11:54 PM Rob McDonald wrote:
On Wednesday, October 13, 2021 at 1:58:14 PM UTC-7 Albrecht Schlosser wrote:
On 10/13/21 6:48 PM Rob McDonald wrote:

I don't have a touch screen Windows machine -- I'm glad that you have such a machine to test on.

Although I need to boot my (dual boot) working Linux machine into Windows for that. I hate to do this but it's a way to develop and test Windows software. Unfortunately touch gestures don't work with my Windows (Virtualbox) VM under Linux. :-(

I see this as analogous to the two-finger scroll being different from mouse wheel scroll -- it is nice for a default behavior for them to be the same -- but there is cool opportunity in separating them out.

Agreed. However this is a little different because of backwards compatibility. Currently all FLTK programs that handle FL_MOUSEWHEEL events continue to work with trackpad scroll events if these are mapped to FL_MOUSEWHEEL events. As soon as we separate them out programs need to be modified. That's why I think we need a backwards compatible way to deal with these two event types. Let's see ...

Compatibility is merely a matter of foresight.  If we make them the same event now and want to change it later, we then have a compatibility problem (:

Yep, agreed.

[Albrecht:] Here's a new idea (untested): we could first send an FL_SCROLL_GESTURE event and if this is not handled by any widget, send an FL_MOUSEWHEEL event. This way "new" programs can handle the FL_SCROLL_GESTURE event and "old" programs can still handle FL_MOUSEWHEEL events. It's similar to FL_KEYBOARD events that are converted to FL_SHORTCUT (if not handled) and finally to FL_SHORTCUT with flipped case. Does that sound sensible?

[Rob:] Devious and clever -- I never would have thought of this.

If that works, I think it will be a great solution.

I hope it will. We have the precedent of FL_KEYBOARD and FL_SHORTCUT, so I believe it should (a) be doable and (b) work for users. It's a little overhead to send an event that nobody uses (if both FL_SCROLL_GESTURE *and* FL_MOUSEWHEEL are not used). But that's a small price.

Under all circumstances, I think a "real mousewheel" should always send "real mousewheel" events.  I.e. we should differentiate the event type - only send gesture scroll events if the OS event originates from a non-mousehweel source -- then re-send as a mousewheel if nothing down the line handled the gesture event.

Yes, sure. If this was not clear: I wouldn't want to change mousewheel events as such. Real mousewheel events shall keep sending FL_MOUSEWHEEL events, nothing else. This idea was only about your changes to send trackpad scroll events as a different type of event which is good. The idea described above should make it possible in a backwards compatible way, and only this new event type should be handled by sending FL_SCROLL_GESTURE first and then FL_MOUSEWHEEL as a fallback.

--
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/dc3f77e3-ba4b-be0a-dd7f-e6bffab08da3%40online.de.
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 'erco@seriss.com'.