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

[Gerald Klix]

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