|
|
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 ] | |
|
| |