paulo1205
(usa Ubuntu)
Enviado em 23/06/2017 - 14:26h
(Por favor, não apague o tópico depois de ler a resposta, mesmo que não goste dela. Deu trabalho, e pode ser útil para outras pessoas.)
Desde a primeira vez que eu li sobre programação em GTK+, eu vi que a coisa era mais complicada do que com Qt. O simples fato de o GTK+ insistir em usar C para fazer orientação a objetos pesada já é um prenúncio de dificuldade.
Por esse motivo, quando eu decidi estudar programação com GUI no Unix, o GTK+ fez o favor de se desclassificar, para mim, logo no começo da comparação com o Qt, que eu fiz para decidir onde deveria focar.
Não obstante, eu sei que, ao longo dos anos, as coisas evoluíram. Por isso — e por causa deste tópico — eu decidi dar uma nova olhada em ambos, e compartilhar minha impressão aqui.
O Qt Creator permite o desenvolvimento de interfaces gráficas que utilizam o Qt (podendo ser o Qt4 ou o Qt5). Para aplicativos que girem em torno de uma GUI do tipo “pequenos conjuntos de formulários”, o modo de se trabalhar com ele é mais ou menos o seguinte:
- Cria-se um “projeto”, que agrega todos os componentes da aplicação.
- Cada formulário da GUI é adicionado ao projeto como uma UI separada.
- Cada UI aloca no projeto um arquivo XML que descreve a UI. Esse arquivo é usado apenas pelo editor de UI (chamado Qt Designer, que geralmente vem integrado ao Qt Creator, mas também pode ser instalado e usado separadamente).
- Para cada UI gerada, é produzido um arquivo .h, que define uma classe que declara em C++ os mesmos elementos dispostos no arquivo XML. O código em C++ que aloca e ajusta as características visuais dos elementos da UI é muito parecido com o código que seria escrito manualmente, caso se optasse por programar manualmente a UI. O arquivo .h é regenerado a cada vez que o XML é alterado, e não deve ser editado manualmente.
- Para cada UI, gera-se também um par de arquivos .h/.cpp nos quais será declarada/definida uma classe em C++ que contém a interface pública da UI. Essa classe tem um membro chamado
ui, que é um ponteiro para a classe do arquivo .h interno, gerado a partir do XML, e esse membro é o canal para que você possa interagir com os demais membros da interface. Esses arquivos da interface podem e devem ser modificados pelo programador.
- No editor visual da UI, é possível associar eventos sobre a UI (por exemplo: clicar num botão, alterar o texto de um
textbox, mudar o tamanho de uma janela etc.) a funções-membros da interface pública. Quando você faz isso, se a função ainda não existir, o par .h/.cpp é modificado pelo Qt Creator para incluir uma declaração e uma implementação vazia da função referida, já com as assinaturas corretas, de modo que basta a você editar o .cpp para preencher a implementação com o código desejado. Além do mais, a associação entre o evento (
signal) e a função tratadora (
slot) também é refletido no arquivo .h interno.
- Ao se produzir o executável da aplicação, todas as UIs estarão embutidas no código C++.
É possível com o Qt construir a UI manualmente, dispensando os arquivos XML e o .h de uso interno, com sua funcionalidade possivelmente mesclada nos arquivos com as classes da interface pública ou noutro arquivo .cpp qualquer. Trabalhando assim, pode-se até prescindir do próprio Qt Creator.
O GTK+ possui um editor de interfaces chamado Glade.
Assim como o Qt Designer, o Glade permite a você desenhar uma interface, produzindo como saída um arquivo XML. Contudo, as aplicações que usam o Glade geralmente não transformam esse XML diretamente em código C que possa ser compilado junto com a aplicação. Em vez disso, o XML tem de coexistir com o executável, e é carregado e associado às funções tratadoras dos eventos em tempo de execução.
Cada arquivo XML geralmente é associado em tempo de execução a um objeto do tipo
Gtk_Builder (ou
Gtk::Builder, se você estiver usando Gtkmm com C++, ou Python ou outra linguagem orientada a objetos), e os componentes da interface são manualmente associados a ponteiros para os respectivos tipos de objetos (e.g. botões a
Gtk_Button/
Gtk::Button,
labels a
Gtk_Label/
Gtk::Label, caixas de texto a
Gtk_Entry/
Gtk::Entry etc.).
Alguns IDEs com foco em GTK possuem integração com o Glade. Pelo que eu entendi das pesquisas que fiz, o mais integrado nesse sentido é a Anjuta. Por isso, eu resolvi baixar o Anjuta, para comparar a facilidade de criar aplicações semelhantes com Qt Creator e com Anjuta/Glade na mesma máquina (com Ubuntu 16.04).
Por trabalhar em conjunto com o Glade, o Anjuta segue a linha de não criar os elementos da GUI no código a ser compilado, mas de ter de fazer o carregamento dinâmico do XML e a conexão entre os sinais e suas funções tratadoras em tempo de execução. Ao contrário do Qt Creator, o Anjuta não ajuda em nada nessa ligação: nada de duplo-clique ou clique com botão direito que permita associar uma função ao evento, e muito menos de criar no código o protótipo ou o esqueleto da função para você.
Isso realmente é uma pena, porque essa parte é trabalhosa e tediosa de fazer na mão, especialmente se você quiser usar C, em vez de C++.
O Anjuta também não cria classes correspondentes a cada UI, logo não cria, por causa da GUI, vários arquivos de código fonte separados. O projeto tem, inicialmente, apenas um arquivo em C, C++ ou outra linguagem, contendo o programa principal e o
boilerplate code para carregar a UI principal num dado do tipo
Gtk_Builder/
Gtk::Builder, e o arquivo contendo o XML de definição da GUI.
Eu resolvi fazer uma aplicação bem simples, um detetor de palíndromos com uma GUI contendo apenas uma caixa de texto e um
label. A cada alteração do texto na caixa de texto, o
label é alterado de modo a informar se o texto digitado é um não um palíndromo. Essa GUI usa apenas um evento, que é aquele disparado a cada mudança do valor do texto da caixa de texto.
Os programas estão em casa. Mais tarde eu posso postar algumas métricas que apontem para diferenças de complexidade, consumo de memória, tamanho dos executáveis gerados etc.
Abaixo, porém, faço alguns comentários gerais sobre minha experiência de ontem:
- A máquina que eu estava usando para testes tinha um processador fraco para os padrões atuais, mas uma quantidade de RAM que ainda me parece razoável. Mesmo assim, o Qt Creator demorava mais de dois minutos (não medi exatamente quanto) para abrir, depois que se clicava no seu ícone. Não parecia ser devido a
thrashing, pois o LED do HD não ficava aceso direto, nem ficavam lentas as outras janelas que eu tinha abertas (de terminal e do Google Chrome). Não sei por que tanta demora na inicialização — vou tentar depurar quando voltar a casa.
- Entretanto, a aplicação com Qt5, depois de compilada, carregava, abria e respondia instantaneamente.
- A documentação do Qt Creator e das classes do Qt é MUITO melhor do que a do Anjuta, do Glade e do Gtkmm/GTK+.
- O Qt Creator/Qt Designer é muito melhor visualmente do que Anjuta/Glade.
- Além de a interface do Anjuta/Glade ser menos menos intuitiva, cada caráter digitado na tela do editor de código fonte provocava o redesenho de todo o texto, com direito a uma tela preta piscando, de modo bem perceptível e incômodo, a cada redesenho. Péssima experiência visual.
- A interface feita com o Glade não apareceu do mesmo modo como eu a havia desenhado no editor visual. A janela ficou com outro tamanho, e os elementos da GUI também mudaram de tamanho, acompanhando o que houve com a janela. Pode ter sido uma falha minha, por esquecer de alguma etapa na inicialização da interface, mas isso apenas ressalta como é mais complicado trabalhar com GTK+ do que com Qt.
- Tive dois problemas de estabilidade diferentes com o Anjuta. Primeiro, de uma hora para outra, ele parou de aceitar o comando para compilar o projeto pela interface gráfica. Como, nessa altura do teste, eu já não estava mais mexendo na GUI do programa, mas apenas ajeitando a parte de verificação de palíndromo aos tipos de dados do Gtkmm/GTK+, eu não liguei muito, e fiquei usando o Anjuta apenas como editor de textos, e compilando via terminal. Mas eu devia ter ligado, porque o segundo problema foi pior, e provavelmente tinha relação com o primeiro: numa determinada hora durante o teste do Anjuta. minha máquina parou de responder. Como eu não gosto de dar
reset forçado na máquina, eu fiquei esperando para ver se ela respondia, e acabei conseguindo ver o ponteiro do mouse se movendo vários segundo depois de eu ter mexido com ele. A máquina estava viva, mas com
thrash. Como eu tinha um outro terminal aberto e com o
top rodando, acabei conseguindo ver que era o Anjuta que havia gastado toda a RAM (10GiB) e estava alocando todo o
swap (mais 20GiB), mas não consegui matar o processo manualmente antes de ele acabar capotando, e levando junto consigo outros programas que estavam abertos na minha sessão. No momento do destrambelhamento do Anjuta, eu só o estava usando como editor de textos, mas talvez o problema viesse desde a hora em que a compilação parou de funcionar. É obviamente decepcionante uma travada com um projeto ridículo como aquele meu teste, pois revela que o Anjuta não está suficientemente maduro para uso em produção.
- Cheguei a ler em alguns sites que o Eclipse pode ser configurado para trabalhar com GTK+ e Gtkmm. Se alguém quiser/puder testar seria bom trazer a experiência para a gente.
- Também vi referências de que o próprio Qt Creator pode ser modificado para trabalhar com GTK+/Gtkmm, mas os sites que eu consegui ver não traziam procedimentos detalhados de
como fazer isso.
