Axis events to keyboard focus (Re: Input and games.)

[Vincent Povirk]

> Windows used to do this and it is completely nuts. They fixed it in recent versions

I don't know what version of Windows you're using, but I can still
observe this behavior in the Windows 8 file dialogs. I wrote a program
to work around it: https://github.com/madewokherd/xscrollwheel

Some toolkits on Windows, like gtk, direct scroll wheel input based on
cursor position, but they're not really using the native windowing
system for their widgets. The upshot of this is that in gtk on Windows
you can only scroll if your top-level window is focused AND your
cursor is on something scrollable.

I don't think it makes sense to send a scroll wheel event to a window
that's not beneath the cursor, as most toolkits will behave like gtk
and ignore the events. Nor do I think it makes sense to dictate
focus/message routing policy within a client's surface.

A compositor could just drop events that aren't over a focused window,
and it would solve Todd's problem, unless he's also expecting to be
able to scroll things without hovering over them.