WM_TAKE_FOCUS
O protocolo do ICCCM que, junto com uma flag em WM_HINTS, dá quatro respostas diferentes para quem decide onde vai o foco do teclado — o aplicativo, o gerenciador de janelas ou ninguém.
O foco do teclado no X é uma única janela, e XSetInputFocus pode ser chamada por qualquer um. O ICCCM precisou regular quem faz isso quando o usuário clica numa janela, e a resposta virou uma matriz. O campo input em WM_HINTS diz se o aplicativo quer que o gerenciador lhe dê o foco; listar WM_TAKE_FOCUS em WM_PROTOCOLS diz se ele quer ser avisado. Quatro combinações: No Input, para xclock e xload, que nunca querem o teclado; Passive, em que o gerenciador simplesmente define o foco na janela de nível superior e o aplicativo se contenta, como o xterm; Locally Active, em que o gerenciador define o foco e ainda envia a mensagem para o aplicativo repassá-lo ao campo de texto certo entre suas subjanelas; e Globally Active, em que o gerenciador nunca toca no foco, apenas envia a mensagem e deixa o aplicativo decidir sozinho.
A mensagem carrega um timestamp, e o aplicativo deve usá-lo em vez de CurrentTime na própria chamada, ou um clique antigo pode vencer um mais novo. Os modelos explicam todo um gênero de relatos de bug. Programas Motif e Xt são Locally Active, assim como GTK e Qt. O AWT do Java escolheu Globally Active e toma o foco por uma janela-proxy própria, uma das razões pelas quais aplicativos Java penaram anos para conseguir o teclado em gerenciadores de janelas de tiling como dwm e xmonad. Gerenciadores que ignoram a matriz e simplesmente definem o foco costumam funcionar — até encontrarem um programa que levou o ICCCM a sério.