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

[Gerald Klix]

This clearly needs more testing, Windows sends only one key.
I overlooked the else in the VM's C-code.
I suspect scrolling by emulation is wrong only on Unix.

BTW: Using the Trackpad on Windows I can get a scroll delta bigger than 
120 (pixels?). Interestingly enough horizontal double-finger swipes
cause the VM to report cursor keys, whereas a conventional
mouse's scroll-wheel tilt is reported as scroll event.

Me puzzled ...


Best Regards,

Gerald



On 8/13/21 4:48 PM, Gerald Klix via Cuis-dev wrote:
> Phil,
> 
> On 8/13/21 4:09 PM, Phil B via Cuis-dev wrote:
>> 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.
> Well, I worked as a software tester for some time and I can decidedly
> assert you: Not every programmer on this globe has your constructive
> attitude, so better be careful.
>>
>>
>>> 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.
> I still have to do some tests on windows and with a mouse/trackpad
> that makes it easy to generate vertical and horizontal
> scrolls at the same time.
> If this happens the #(up down left right) direction
> handling scheme will break.
> If these test go well, I will prepare a complete change-set.
>>
>>
>>>
>>> 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?
> Juan,
> 
> since you have a Mac handy, can you please test that my assumption
> is correct. Activate mouse-wheel-event reporting in the VM
> and make sure that scrolling still works.
> Please also check that my assumption about the
> 3 keyboard-events that are generated is correct for OSX.
>>
>> Thanks,
>> Phil
>>
>>
> 
> Best Regards,
> 
> Gerald