WM_TAKE_FOCUS
El protocolo de ICCCM que, junto con una bandera de WM_HINTS, da cuatro respuestas distintas a quién decide dónde va el foco de teclado: el programa, el gestor de ventanas o nadie.
El foco de teclado en X es una única ventana, y XSetInputFocus puede llamarlo cualquiera. ICCCM tenía que regular quién lo hace cuando el usuario pulsa en una ventana, y la respuesta fue una matriz. El campo input de WM_HINTS dice si el programa quiere que el gestor le dé el foco; incluir WM_TAKE_FOCUS en WM_PROTOCOLS dice si quiere que se le avise. Cuatro combinaciones: No Input, para xclock y xload, que nunca quieren el teclado; Passive, donde el gestor simplemente pone el foco en la ventana de nivel superior y el programa se conforma, como xterm; Locally Active, donde el gestor pone el foco y además envía el mensaje para que el programa pueda pasarlo al campo de texto correcto entre sus propias subventanas; y Globally Active, donde el gestor nunca toca el foco, solo envía el mensaje y deja que el programa decida.
El mensaje lleva una marca de tiempo, y el programa debe usarla en su propia llamada en vez de CurrentTime, o un clic antiguo puede ganar a uno reciente. Los modelos explican todo un género de informes de errores. Los programas Motif y Xt son Locally Active, igual que GTK y Qt. El AWT de Java eligió Globally Active y toma el foco a través de una ventana intermediaria propia, una de las razones por las que los programas Java pelearon durante años por conseguir el teclado en gestores en mosaico como dwm y xmonad. Los gestores que ignoran la matriz y ponen el foco sin más suelen funcionar, hasta que se topan con un programa que se tomó ICCCM en serio.