Xlib difference between _NET_ACTIVE_WINDOW and XGetInputFocus

Question

What's the difference between _NET_ACTIVE_WINDOW and XGetInputFocus() ? Do they always point to the same window? When use one over the other?

Thanks.

Combine

Answer 1

The main difference is more in setting than in getting. When setting focus (activating windows), you prefer the atom over the xlib function because then the window manager might handle your request differently - for example, if you want to activate a window that has a modal dialog up at the time, the WM might focus that dialog instead of the window itself, or if the user has disabled focus stealing, the WM might just highlight the window instead of actually focusing it.

There are a few small differences in getting too, based on the same idea, though I'm not sure exactly what all the differences are, I think it might be app specific. With programs I've written, getting the property and the focus return the same window. With Firefox though, it is returning two different windows - the active one is the window we expect, but the focus is on a hidden window instead. I don't know why it does that, but it does.

_NET_ACTIVE_WINDOW insulates you from those kind of application implementation details better than XGetInputFocus. Something like a window manager or a keyboard grabber might be interested in the specific details, but an app asking if it is active itself (or requesting to become active) ought to use the atom.

Read a bit more here too btw: http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#idm140200472702304

Weigh

IOW the difference is obscure and arbitrary :) An alternative answer would be: _NET_ACTIVE_WINDOW is there to fix the fact that the app should never talk to the "mechanism" API but ever only to the "policy" API, but since X exposes both to the user in the same API now we have this mess. – Combine

Yeah, that's my feeling on it. I'm actually kinda surprised that in my tests, the window manager menu changed neither setting. It just filtered the events out of the queue without actually unfocusing it. But the Firefox one is weird - it isn't the WM doing that... but I suspect a modal dialog might do it too, I just don't have any programs here that actually use them. (I HATE modal dialogs as a user.) – Weigh

Answer 2

No, they don't always point to the same thing.

_NET_ACTIVE_WINDOW is a WM thing. It will not point to a window not managed by the WM.

Input focus doesn't know or care about WMs (other than being set mostly by WMs). It can be set by any program at any time to any window: internal, override-redirect or even to an unrelated managed window (though few programs do that).

What you want to use very much depends on your exact needs. Normal apps should hardly use either. If you want to send keyboard events, use XGetInputFocus. In most other cases you probably want _NET_ACTIVE_WINDOW.

Intramuscular

I want to know the active window for two reasons: 1) to know if my app is active and 2) to get the active display i.e. the display which currently has keyboard focus. – Combine

I'm not sure how this answer can help me decide which method to use. It seems like XGetInputFocus() is a safer option given how bad WMs are in general. It's not clear to me when not to use it or why _NET_ACTIVE_WINDOW was added in the first place. – Combine

"I want to know" is not a sufficient reason. Why do you want to know that? How exactly this information influences behaviour of your app? – Intramuscular

If it has to do with keyboard events, you probably want XGetInputFocus. If you want to change look and feel depending on which window appears active to the user, _NET_ACTIVE_WINDOW. There are many use cases... – Intramuscular

It's still not clear to me when _NET_ACTIVE_WINDOW would return a different window than GetInputFocus() or what the purpose of that atom is and why was it added over GetInputFocus(). I understand that one is set by WM and one by X, but that doesn't explain why there are two of them and what's the pracitcal difference between them. – Combine