Focus stealing

Focus stealing

Posted Aug 18, 2005 22:24 UTC (Thu) by newren (subscriber, #5160)
In reply to: Focus stealing by zblaxell
Parent article: GNOME and the way forward

Lots of interesting info in your post. Thanks! Some comments:

The applications don't seem to mind, and I didn't have to rewrite them, I just dishonor their input grab requests from the X server. In fact, I often wonder why it ever seemed necessary to grab the mouse or keyboard focus for these operations in the first place, since the menus work just fine without it, and modifying any particular application or toolkit to work that way is trivial. There are really good reasons to not grab the mouse and keyboard--especially if the application is prone to locking up while it has a menu posted.

Really? I had assumed (never actually checked) that it'd be a lot of hard work to modify toolkits to work without mouse and keyboard grabs. From the few things I had read on the matter, though, it doesn't look like toolkit authors are willing to make such a change--perhaps it causes lots of race conditions or other problems? (Man, I'm exposing my ignorance here...)

although if it was technically feasible, I'd try to get the new window to be immediately below the window with the mouse cursor, and first in the Alt-Tab list. Forcing all new windows to be minimized would work too, although I wouldn't be surprised if there was at least one application that would just try to un-minimize itself.

It's not very hard at all to place windows below the focused one and first in the alt-tab list. Also, the WM gets MapRequest events whenever an application tries to map a window (unless it's an override redirect window) and can just deny or delay the request so it could keep apps from un-minimizing themselves for the most part.

as you alt-tab through the windows, it pops up each window to the top--and if you keep going, it pops the window back to its original place in the stacking order.

Try using Alt-Esc in metacity. Other WMs may have something like that too with an alternate keybinding.

There is always a window under the mouse. As far as I know the mouse can't be anywhere except above the root window, and one can't delete the root window.

Yes, I unfortunately used "window" as the user thinks of them instead of as the real X objects. Note that mose focus-follows-mouse users prefer a sloppy style meaning that windows are focused when the mouse enters them but they are not defocused on exit--and users don't consider the root window and other special windows (e.g. the taskbar) to count when the mouse enters them. Saying always keep the focus under the mouse is nice and all but this is just an example of how most people don't really mean that.

Which are those? I've seen some applications (mostly Xaw) that can't get focus with some window managers even when they want it and can get it under twm...I had assumed that was a window manager bug.

See section 4.1.7 of the ICCCM (e.g. at http://tronche.com/gui/x/icccm/sec-4.html). Basically, it's a violation of the ICCCM for the window manager to try to set focus to a window with the input field set to false.

---

(Log in to post comments)