On 10/13/21 11:54 PM Rob McDonald
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 (:
[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
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
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 email@example.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 ]