Scroll events

[Andreas Raab]

Hmm... I really don't mind representing scroll events differently 
(having added the Ctrl-Cursor hack way back) ... but how do other 
platforms represent scroll wheel events? On Windows, there is an 
explicit message WM_SCROLLWHEEL (or so - don't quite remember the name) 
which is independent of both, keyboard and mouse events. I'd be happy to 
pass this up individually, but what about the other platforms?

Cheers,
   - Andreas

Bert Freudenberg wrote:
> Scroll events really should be mouse events (*). This hasn't been too 
> much of a problem in Morphic where we have a focus-follows-mouse policy. 
> But in Tweak, for example, the keyboard scroll events go to the focused 
> pane even when I point the mouse somewhere else.
> 
> AFAIK no host platform originally delivers scroll events as keyboard 
> events, so it appears as the Right Thing to do, rather then hacking 
> around it on the image side. However, I'm not sure about the best way to 
> actually hand this to the image ... Any opinions?
> 
> As a further data point, there are mice having both vertical and 
> horizontal scroll capabilities, something that users may want to put to 
> use. Not sure if we should support the additional buttons, too, but why 
> not? My mouse has 8 of them in total, all of which do something 
> reasonable - yes I'm on a Mac ;-)
> 
> [OT] Rumor has it that Apple is going to introduce a new mouse soon, 
> which may have two buttons or an iPod-like wheel or both ...
> 
> - Bert -
> 
> (*) Yes, I'm guilty for coming up with the arrow-key hack in the first 
> place, but it was TSTTCPW
> 
>