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 13, 2021  
 
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 ]
 
     
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'.