WM_TAKE_FOCUS
Le protocole ICCCM qui, avec un seul drapeau de WM_HINTS, donne quatre réponses différentes à la question de savoir qui décide où va le focus clavier : l'application, le gestionnaire de fenêtres, ou personne.
Le focus clavier, dans X, est une fenêtre unique, et XSetInputFocus peut être appelé par n'importe qui. L'ICCCM devait réglementer qui s'en charge quand l'utilisateur clique sur une fenêtre, et la réponse est devenue une matrice. Le champ input de WM_HINTS dit si l'application veut que le gestionnaire lui donne le focus ; inscrire WM_TAKE_FOCUS dans WM_PROTOCOLS dit si elle veut en être informée. Quatre combinaisons : No Input, pour xclock et xload, qui ne veulent jamais le clavier ; Passive, où le gestionnaire pose simplement le focus sur la fenêtre de premier niveau et l'application s'en contente, comme xterm ; Locally Active, où le gestionnaire pose le focus et envoie en plus le message pour que l'application le transmette au bon champ de texte parmi ses sous-fenêtres ; et Globally Active, où le gestionnaire ne touche jamais au focus mais envoie seulement le message et laisse l'application décider seule.
Le message porte un horodatage, que l'application doit utiliser dans son propre appel à la place de CurrentTime, faute de quoi un vieux clic peut l'emporter sur un plus récent. Ces modèles expliquent tout un genre de rapports de bogues. Les programmes Motif et Xt sont Locally Active, de même que GTK et Qt. L'AWT de Java a choisi Globally Active et prend le focus par une fenêtre intermédiaire à lui, ce qui explique en partie pourquoi les applications Java ont longtemps peiné à obtenir le clavier dans des gestionnaires en mosaïque comme dwm et xmonad. Les gestionnaires qui ignorent la matrice et posent simplement le focus fonctionnent en général — jusqu'à ce qu'ils croisent un programme qui a pris l'ICCCM au sérieux.