Hacker News Reader

Comment by jhallenworld | Hacker News Reader

An interesting part of the X protocol is XGrabPointer (and XGrabKeyboard). These force events to be delivered relative to a particular window instead of to the focus window. Cascading menus can be implemented by making a stack of such grabs: push when you open a submenu, pop when you ESC back to parent.

Anyway, so it's very useful that everything in X is a window, because it works well with this input grabbing. Also it's nice for borders: the border was one outer window, and the drawing area was a smaller inner window.

I don't quite remember anymore, but I think a bad part about using the X's windows is that the coordinates were limited. Sure you only need 12-bits or so for screen coordinates, but it's convenient if you had 64-bits to handle any possible clipping or relative offset situation.

View on HN

I don't think that's unique to X windows, though - pretty much all GUI platforms have a similar concept, otherwise any time you accidentally drag your mouse outside of a window you'd start sending events to another application.

On MS Windows it's called "Capture".

> otherwise any time you accidentally drag your mouse outside of a window you'd start sending events to another application.

macOS does precisely that. Open a Chrome window and put a Finder window over it, then move your mouse and do a scroll gesture - the target will always be whatever is below the mouse cursor at that moment, even if you don't actively select the window.

That's also the behavior on Windows

It's also the behavior on Linux with X11 (haven't tried Wayland)

At least on XFCE with X11, this behavior is configurable, you can enable it or disable it, as you wish.

Note that this is a feature that was added in Windows 10. Previous versions of Windows didn't have this functionality (you had to click on a window to scroll in it).

An X-Mouse mode was available since at least Win98SE [1]. It was hidden and you had to enable it in the Registry [2], typically via Tweak UI.

That mode would move the input focus without actually clicking on another window. You could see the caption bars change color accordingly, but the "temporarily" focused window could be set to either stay in it's original z-order or moved to the top.

Windows 10 uses a different method: it doesn't change the focus and only sends mouse scrolling events to the target window. That's less powerful, but probably more intuitive for us non-*nix users.

[1]: https://stackoverflow.com/questions/70599589/how-do-i-turn-o...

[2]: https://superuser.com/a/19643

But it wasn't for a long time. I think it was broken until at least windows 7.

Well I think this is desired behavior. But what if you grab a slider (so that the mouse button is held down), and drift out of the window? I thought some versions of Windows didn't handle this well, the slider would jump back home or something unless you kept pointing at it. The way it should work: as long as you are holding the button down, it should not matter what the x-coordinate of the mouse is if it's a y-slider, and vice-versa.

It makes sense for mouse scrolling to target whatever the mouse is pointing at, just like all the other mouse buttons. Keyboard scrolling needs to use the current input focus to select a target because you can't point with the keyboard.

This is also why you can't change the volume or start a screensaver while a drop down is open.

Reply on news.ycombinator.com