[Cuis-dev] [RFC] True Mouse Wheel Support

[Phil B]

Gerald,

On Fri, Aug 13, 2021 at 3:41 AM Gerald Klix <cuis.01 at klix.ch> wrote:

> That surprised me, too. After some thinking -- could not sleep --
> it dawned to me that the problem is elsewhere ...
> >  I would expect it to be
> > the other way around (i.e. that the cooked keyboard event rate would be
> > slower.)  I'm assuming that this is a VM thing that probably needs to be
> > fixed there (i.e. higher resolution scroll events are quite handy for
> > scrolling long lists, zooming etc)
> ... Actually the code that generates scroll events from keyboard
> events (and vice versa) -- please, don't take this personally -- was
> flawed from the very beginning. It generates three/two scroll
>

WHAT!?! :-)  Seriously, don't worry about calling out any bad code I
submit... mistakes happen.  I'd rather have them spotted/fixed than have
anyone worry about offending.


> events from three/two keyboard events.
> If you look at the vm-code, you discover that the VM generates three
> or two keyboard events from one mouse-wheel event:
>
> X11:
>
> https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/c6c18805f2a5ba03b5ea3e765bb7fec1a2fce248/platforms/unix/vm-display-X11/sqUnixX11.c#L3641
>
> OSX Quartz:
>
> https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/c6c18805f2a5ba03b5ea3e765bb7fec1a2fce248/platforms/unix/vm-display-Quartz/sqUnixQuartz.m#L1911
>
> These ones only generates two keyboard events.
>
> Linux/Unix framebuffer:
>
> https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/c6c18805f2a5ba03b5ea3e765bb7fec1a2fce248/platforms/unix/vm-display-fbdev/sqUnixEvdevKeyMouse.c#L662
>
> Windows:
>
> https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/c6c18805f2a5ba03b5ea3e765bb7fec1a2fce248/platforms/win32/vm/sqWin32Window.c#L429
>
> (Side note: I might be wrong concerning the event count on windows)
>
> In a nutshell the VM is not really consistent here,
> but 2 vs. 3 events did probably go unnoticed.
>
> You can used the attached file-out of a slightly
> instrumented HandMorph>>#generateKeyboardEvent:
> method to see the three keyboard
> events and the resulting three scroll events.
>
> As a fix, I suggest to react only on the simulated
> key-down-event and ignore the other events.
> We than can adjust the scroll counts in the individual
> morph classes. I also suggest to make these scroll counts
> preferences. This should lead to consistent behavior across
> OSes and scroll-wheel event reporting protocols.
> Forthermore advanced users can adjust the scroll rate.
>

Good catch... yes, that's a bug in at least what I did previously.  So no
VM fix needed since, as you've shown, the VM is doing the right thing re:
simulating a keyboard event and I should have been paying attention to the
event type.  I'm in agreement with the modified behavior you're proposing
as it will make the behavior consistent regardless of event source or
platform.


>
> Best Regards,
>
> Gerald
>
>
> > Nice to finally see those wheel
> > side-to-side direction events... nice work!
> Thanks!
> >
> > The only question I have is if there's a way to detect the capability and
> > set the VM parameter automatically on image start?  If so, we could have
> a
> > preference as to whether or not it should automatically be set. (I
> imagine
> > most would)
> Actually we can activate it unconditionally, because
> the OSX VM will disregard the VM parameter and sent simulated keyboard
> events anyway. It Quartz window code does not refer to
> this VM parameter.
>
>
Cool... then I'd suggest enabling on image startup.  Juan, would you agree?

Thanks,
Phil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20210813/f5ac674f/attachment.htm>