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