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. _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
