No Linux, muitos programas têm uma versão CLI e um front-end GUI. Eu li em algum lugar que isso segue a filosofia linux e é uma boa prática. Claro que é verdade a partir de uma perspectiva de desenvolvedores para manter o código da GUI separado do programa real.
Dado um programa, que pode ser usado felizmente a partir da linha de comando, eu gostaria de criar uma GUI para a versão da linha de comando. Quais são minhas opções aqui?
Eu posso pensar em apenas 2 que o desenvolvedor da GUI usaria.
chamando o programa com os parâmetros configurados da seguinte forma:
system ("someprogram --paramter1 -p2 -p3")
ter a versão CLI capaz de executar no modo de servidor com soquetes (unix, inet, ...) e usar esses soquetes para se comunicar com o "servidor"
A solução mais limpa seria a segunda na minha opinião, mas isso nem sempre é possível sem alterar a versão do CLI.
A pergunta atual é qual é a maneira correta de ter uma versão cli e uma versão GUI construídas separadamente?
Uma abordagem diferente é escrever sua funcionalidade como uma biblioteca. Então você tem uma GUI que usa a biblioteca; e um CLI que também usa a biblioteca. Dependendo da complexidade da sua tarefa, esta pode ser a melhor solução, pois ambos os programas podem funcionar de forma independente, sem a necessidade de qualquer tipo de comunicação entre processos.
Se a execução do programa for relativamente sem estado , ou não for interativa, ou se apenas executar até a conclusão, a primeira opção será mais fácil e apropriada.
Se o programa é stateful , ou de longa duração, a segunda opção é mais apropriada, embora mais complexa.
Pense no FTP: usando curl ou wget para fazer o script de um download e usando expect para fazer o script de uma sessão ftp interativa, pode não haver uma resposta correta em todos os casos.
Casos de estudo interessantes incluem:
nmap pode fornecer toda a sua saída útil complexa em XML, com feedback durante a digitalização, uma vez iniciado, você só precisa sentar e esperar gpg como um CLI tem um longo histórico de integração com clientes de email GUI, ele usa descritores de arquivo para entrada e saída xmlclitools tem operação de modo dual interessante, independente e cliente / servidor Qual idioma você planeja usar para a GUI? Adivinhando C / C ++ com base na chamada system() . Você também pode usar os os.exec * () ou os.system () funciona ou funções similares em vários outros idiomas, incluindo apenas outro script de shell que chama Zenity , Yad ou GTKDialog para as interações da GUI.
O uso da função system (/ system) C / C ++ tem uma série de ressalvas . Como a maioria dos outros compiladores e interpretadores de linguagem são escritos em C / C ++, suas funções / métodos equivalentes geralmente têm os mesmos problemas. Use com cuidado.
A comunidade Puppy Linux faz amplo uso do GTKDialog chamado a partir de scripts de shell bash, já que ele suporta mais todos os widgets usuais de GUI do GTK +. O código GTKDialog semelhante a XML é incorporado em uma string de script de shell export ed que é passada na chamada para o executável gtkdialog . Assim, todo o código permanece no mesmo arquivo.
Yad é uma bifurcação de Zenity que multiplica drasticamente as capacidades de GTK + GUI do Zenity e é a minha preferência atual ferramenta.
A abordagem geral do GTKDialog , Zenity e Yad é ...
A GUI interativa e o código funcional também podem estar no mesmo script , com uma opção de linha de comando para selecionar GUI, CLI ou API (não interativa), se desejado. Melhor ainda seria a detecção interna na inicialização do tipo de ambiente com a seleção automática da interface apropriada.
Tags command-line gui programming