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

[Bill Spitzak]

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

> 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 agree I think that is what is happening. I believe some Microsoft 
applications such as Word are doing this now, too.

> 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.

No certainly not. The nutty behavior of Microsoft is to send it to the 
keyboard focus. Though I would prefer them to be sent to the surface 
with pointer focus, even dropping them would be better.

> 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.

I think the client should drop the events, not the compositor.