A maneira mais simples de saber se um aplicativo GTK (por exemplo, Firefox) está totalmente carregado e pronto, a fim de maximizá-lo

Question

Nos quiosques do Linux, para redefinir o estado de alguns aplicativos "nos bastidores" (enquanto o protetor de tela deixa a tela em branco), eu uso um script BASH que, entre outras coisas, chama wmctrl , com a tarefa de maximizar a janela do Firefox.

"wmctrl" envia mensagens (assíncronas?) para o gerenciador de janelas (XFWM no meu caso) para primeiro localizar um "id de janela":

FF_WID=$(wmctrl -l | grep ' - Mozilla Firefox' | cut -d ' ' -f1)

e, em seguida, para maximizá-lo em tela cheia:

wmctrl -ir $FF_WID -b add,fullscreen

O problema é que a última invocação falha silenciosamente (mesmo com a opção "verbose") quando a janela do Firefox é "não totalmente carregada" (ou seja: quando o gerenciador de janelas já atribuiu um id de janela, mas - talvez porque está terminando de desenhar os widgets? - ainda não é possível executar a ação necessária - maximização).

Solução: Basicamente, se um atraso arbitrário: sleep N for adicionado antes do comando de maximização, a ação será executada.

Mas os inconvenientes são dois: máquinas diferentes precisam de atrasos diferentes; Além disso, se o atraso for muito longo, a área de trabalho, embora vazia, fica visível por um momento perceptível, e isso não é agradável para os usuários.

Com atrasos (também) curtos, há obviamente um momento em que o processo (Firefox) já é gerado, mas o "ID da janela" do WM ainda não está atribuído. Uma alternativa possível e melhor teria sido essa:

while FF_WID=$(wmctrl -l | grep ' - Mozilla Firefox' | cut -d ' ' -f1) ; do
    true
done    
wmctrl -ir $FF_WID -b add,fullscreen

Mas, infelizmente, ter um "id de janela" não é suficiente. Isso provavelmente porque há eventos do GTK pendentes, um pouco bloqueando a solicitação de maximização.

O mesmo comportamento é observável ao substituir o Firefox por outro aplicativo GTK, como "xfce4-terminal".

Outra solução alternativa - mas válida apenas no que diz respeito ao Firefox, enquanto busco uma solução geral - pode ser habilitar o registro no lado do aplicativo e observar eventos durante a fase de carregamento, buscando um "aplicativo pronto" ou semelhante. Para fazer isso, vou experimentar um pouco com os recursos de registro do Firefox (NSPR_LOG_MODULES)

Como outra solução parcial, já experimentei alguns complementos para o Firefox no modo quiosque (tela cheia), mas precisei (e consegui) comportamentos ligeiramente diferentes em termos de personalização da interface do usuário.

É desnecessário dizer que a opção -fullscreen documentada em outro lugar para o Firefox não é válida na versão do Linux.

Por ter lido esta outra questão , e por ter consequentemente Eu experimentei muito, eu tendem a excluir qualquer problema com possíveis comportamentos diferentes de "wmctrl" quando invocado com ou sem a opção -i (nome ou formulário inteiro).

Pesquisou muito sobre esse problema sem encontrar uma solução geral e "não tão suja".

A: PODE O PROBLEMA SER REALMENTE CAUSADO PELA EXAUSÃO INCOMPLETA DA FILAÇÃO GTK?

B: (SE É VERDADEIRO) EXISTE UMA TÉCNICA APLICÁVEL A PARTIR DE UM SCRIPT BASH, PARA FORÇAR UM ATRASO LIMITADO APENAS AO PONTO ONDE A FILA ACIMA ESTIQUETADA?

• Eu sei que existem várias maneiras de interagir com o mecanismo do GTK, por exemplo via ligações Python ou PERL.
• Há também um "gtk-server" adequado para interação entre o script GTK e o BASH.
• Existe também uma interface FFI (ctypes.sh) que permite, funcionando como um plugin BASH, direcionar chamadas de bibliotecas compartilhadas (incluindo o GTK, qualquer biblioteca compartilhada) de qualquer script BASH.

É claro que a solução ideal será a mais horizontal possível (válida não apenas para o Firefox, mas para qualquer aplicativo GTK) e exigirá o menor número possível de programas | intérpretes | hacks dependentes da versão para instalar e manter ...

Muito obrigado pela leitura (longa, longa), tenha um bom dia