andreas.raab at gmx.de
Fri Mar 18 06:47:15 UTC 2005
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?
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
More information about the Vm-dev