When InputHint is not in WM_HINTS (i.e., the flag is not set), treat the window
as if the InputHint was set (the default behavior). This means that i3 will
focus the window when it becomes managed.
fixes#1676
http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.7
> Clients using the Globally Active model can only use a SetInputFocus request
> to acquire the input focus when they do not already have it on receipt of one
> of the following events:
> * ButtonPress
> * ButtonRelease
> * Passive-grabbed KeyPress
> * Passive-grabbed KeyRelease
Since managing a window happens on a MapNotify (which is absent from this
list), the window cannot accept input focus, so we should not try to focus
the window at all.
Fixes an issue with xfce4-notifyd which (correctly) declines focus when
we send WM_TAKE_FOCUS, which puts i3 in a state where i3 focus and X
focus are different when a notification appears.
If input focus is set by the window manager, it is not necessary to send
WM_TAKE_FOCUS because it has already taken focus.
http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.7
> The goal is to support window managers that want to assign the input
> focus to a top-level window in such a way that the top-level window
> either can assign it to one of its subwindows or can decline the offer
> of the focus. For example, a clock or a text editor with no currently
> open frames might not want to take focus even though the window
> manager generally believes that clients should take the input focus
> after being deiconified or raised.
Both setting input focus and sending WM_TAKE_FOCUS is effectively
setting focus on the window twice which is certainly against the spirit
of the spec, if not the letter.
fixes#1167
