Zenity: interface gráfica para scripts, parte 1

Embora uma quantidade cada vez maior de recém-convertidos o evitem (e eu não os culpo por isso), o shell continua sendo uma ferramenta chave para a maioria dos usuários GNU/Linux. Programas feitos em shell script são criados, compartilhados e utilizados nas mais variadas circunstâncias. Alguns poupam tempo, outros salvam vidas. Mas mesmo que o trabalho de fazer o script tenha sido de outra pessoa, usuários menos experientes e confiantes podem achar complicado e assustador utilizá-los. Como trazer a flexibilidade do shell script para o usuário que só trabalha com interfaces gráficas? Há pouco tempo eu me deparei com esse dilema e descobri o Zenity.

O que é um shell, e por que ele precisa de um script?

Antes de irmos adiante, o shell é uma interface pela qual você passa comandos ao computador. Não há widgets, botões ou coisas do gênero: apenas o local para a entrada de comandos. No Windows, o shell costuma ser chamado de linha de comando (ou CLI). Na maioria dos sistemas GNU/Linux, o shell é o que você vê e usa ao abrir um terminal. Shell scripts são arquivos de texto contendo comandos do shell e seus parâmetros, a serem executados numa ordem determinada. Embora haja algumas pequenas diferenças, de modo geral os comandos que você digita em um terminal podem ser postos em um script, e você chama o script para que o sistema os execute. Os shell scripts também podem ser interativos, solicitando ao usuário que tome decisões e entre com dados antes de prosseguir.

Rodando os scripts pela interface gráfica

Obviamente, os shell scripts podem ser executados pela interface gráfica: ponha um atalho para o script no desktop e use-o para executar o script em segundo plano ou em uma janela de terminal (você escolhe). O problema é que para um usuário de interface gráfica a interação é muito diferente do resto da experiência que ele tem com o computador. Pelo que eu vejo, usuários acostumados a janelas com botões para “Sim” e “Não” ficam desconcertados ao verem uma janela preta com um monte de texto em branco e uma mensagem na última linha: Interface não encontrada: prosseguir (S/N)?

Exemplos de janelas do Zenity

O Zenity não é uma ferramenta única (é semelhante ao dialog e ao Xdialog, dentre outros) e também não foi a primeira a aparecer, mas é bastante útil. O diretório de software da FSF diz que “O Zenity exibe janelas em Gtk+ a partir da linha de comando e através de shell scripts”, e não consigo pensar em maneira melhor de descrevê-lo. Pondo as coisas de outra maneira, o Zenity permite que um usuário de interfaces gráficas interaja com um script de maneira mutuamente benéfica. Às vezes seu script precisa fazer uma pergunta ao usuário, e o Zenity recebe a resposta oferecendo ao usuário uma janela familiar. O usuário final não precisa nem saber que está rodando um script.

Hello world!

Como já mencionei, os comandos do shell podem ser postos em scripts para serem executados. O mesmo se aplica no sentido inverso. Você pode pegar um comando de um script e executá-lo no shell se quiser. No caso do Zenity isso não é tão útil, a não ser para fins de testes. Vamos a um exemplo simples de como o Zenity exibe uma janela informativa. Presumindo que o Zenity esteja instalado (há pacotes para a maioria dos sistemas GNU/Linux, é só procurar por um no seu gerenciador de pacotes/software), digite isto diretamente em um terminal gráfico (xterm e afins) e veja o que acontece:

Se você colocar isso em um script e criar um atalho para ele no desktop, vai obter o mesmo resultado sem precisar de uma janela de terminal. Tudo muito bom, mas não muito interativo. O Zenity, obviamente, pode fazer mais do que exibir janelas informativas. Passe o parâmetro question e você vai obter algo mais útil. zenity --question --text "Deseja prosseguir?" exibe uma pergunta e retorna 0 ou 1 quando o usuário clica nos botões Ok ou Cancelar, respectivamente. Lembre-se de que o Zenity foi desenvolvido para interações simples com shell scripts, logo você estará limitado aos botões com etiquetas OK e Cancelar. Na prática, isso significa ter que adequar suas perguntas a essas respostas ou explicar nas janelas gráficas o que cada botão faz. Se precisar de algo mais completo, talvez seja melhor refazer seu script em uma linguagem (como Python, por exemplo) que seja compatível com alguma interface gráfica. O Zenity também oferece janelas para calendários, abertura e gravação de arquivos, indicadores de progressos e avisos. Em outras palavras: se seu script tem algum tipo de interação com o usuário, o Zenity provavelmente pode replicá-la.

Como o Zenity manteve a minha sanidade

Uma amiga minha comprou recentemente um Asus EeePC com 4 GB de armazenamento e ficou muito satisfeita com ele. Com certeza muitos representantes de vendas carregando seus substitutos de desktops botam um baita olho gordo nele no trem. Há pouco tempo, minha amiga adquiriu um modem de banda larga 3G para ter conexão com a internet mesmo longe do escritório ou de um ponto de acesso. O dispositivo USB veio com um driver binário para o GNU/Linux (estou trabalhando em uma solução livre) em CD, além de um driver específico para o EeePC. O único problema é que o driver precisa ser descarregado manualmente por um script sempre que é necessário usá-lo. Embora uma solução pelo udev fosse possível, nós não queríamos que o modem conectasse automaticamente sempre que fosse encaixado. O script também permite reconectar e interromper a conexão. O shell script faz bastante coisa e apresenta um grupo de parâmetros simples e diretos: up para conectar, down para desconectar e restart para reconectar. Ele precisa de privilégios de superusuário, mas o sudo cuida disso.

O problema é que a amiga em questão não é do tipo que pressionaria Ctrl+Alt+T para abrir um terminal e então digitar sudo /caminho/para/o/scriptdeconexao.sh up só para conectar à internet (e depois lembrar de usar restart no lugar de up se a conexão cair). Outro problema foi o script não manter logs; se eu quisesse resolver problemas mais tarde, ia precisar de um log que registrasse alguns detalhes sobre as conexões realizadas. Para concluir, quando você chama o script para se conectar não há feedback até a conexão ser estabelecida, e esse tempo em que o programa fica parado pode deixar usuários inexperientes nervosos. Disposto a melhorar a experiência de usuário oferecida pelo script, escrevi um script ao redor dele que detectava se a conexão estava ativa ou não (e se havia caído sem que o usuário soubesse). Com base nessas informações, o script pedia ao usuário que confirmasse o que ele estava prestes a fazer e chamava o script original, direcionando a saída para um arquivo de log.

Funcionou direitinho: agora o usuário só precisava lembrar de um único comando para conectar, reconectar ou desconectar. Mas continuava sendo um comando do shell, e o terminal tinha que ser chamado. Eu poderia colocar um ícone no desktop, mas o usuário ainda encontraria a “tela preta esquisita” (já ouvi chamarem o terminal assim). Foi aí que o Zenity me salvou. Eu o descobri pelo Google, e consegui trocar toda a minha interação com o usuário por chamadas ao Zenity imediatamente. Agora é só clicar em um ícone no desktop para rodar o script; ele detecta se a conexão está ativa ou não (ou se caiu) e pede ao usuário que confirme o que deseja fazer. Depois ele mostra uma janela com uma barra de progresso enquanto tenta realizar a tarefa. No final, exibe uma janela com uma informação de sucesso, um aviso ou um erro. Tudo é registrado nos logs conforme eu precisava (tudo gerenciado pelo logrotate, obviamente) e o usuário fica muito feliz.

E não acabou!

Na segunda parte deste artigo, vou mergulhar mais fundo explicando como fazer o que eu fiz com o Zenity. Portanto, teremos mais informações sobre janelas de progresso, erros, avisos e perguntas. Se eu abri o seu apetite, procure na internet por zenity examples. Você vai achar muita coisa boa.

Créditos a Ryan Cartwright – freesoftwaremagazine.com