Enviado em 23/06/2017 - 11:20h
me expliquem, e se for pra instalar qt qual instalar QTcreator ou QT SDK??? e qual a diferenças
GUI em GTK é código puro e no QT é só desenhar no QTcreator???
Responder tópico2. QT nao serve só pra interface grafica
Enviado em 23/06/2017 - 11:54h
3. Re: GUI em GTK é código puro e no QT é só desenhar no QTcreator???
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.
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.
4. Re: GUI em GTK é código puro e no QT é só desenhar no QTcreator???
Enviado em 26/06/2017 - 04:06h
Algumas atualizações sobre os testes comparativos do detector de palíndromos.
Além das versões em C++, feitas com Qt5 e com Gtkmm-3, acrescentei uma versão em C, com GTK+ 3.0.
Uma aparente vantagem de usar GTK+ (C) com Glade/Anjuta, em comparação com Gtkmm (C++), é que passa a funcionar a edição automática da função tratadora de eventos a partir do editor visual da GUI, de um jeito semelhante ao que existe no QT Creator. O Glade permite indicar no arquivo XML o nome das funções em C associadas a cada evento de cada widget, e a função em C gtk_builder_connect_signals() se encarrega de fazer a ligação indicada no XML, depois que ele é carregado para o programa, em tempo de execução. Com o Gtkmm, isso não é possível, e cada conexão de evento (signal) a tratador (slot) tem de ser feita individualmente.
Particularmente, eu continuo gostando mais do jeito do Qt Creator, que faz essa conexão em tempo de compilação. Só não gosto muito do modo como isso é feito, que é acrescentando sintaxe nova, não padrão, ao código, o que obriga a passar o cada arquivo do código fonte por um preprocessador do próprio Qt, chamado MOC (meta object compiler), que converte essa sintaxe nova em C++ puro (e maior, obviamente), para que possa ser reconhecido pelo compilador. Felizmente, tal sintaxe extra é relativamente limitada.
Tendo as três versões do código, seguem abaixo algumas métricas comparativas:
1) Tamanho do código fonte.
Se considerarmos como código fonte também os arquivos de suporte dos projetos, para que eles pudessem ser compilados em outras máquinas, a coisa cresce um bocado, especialmente no mundo GTK.
Antes de cada compilação, eu limpei totalmente os caches de disco, a fim de ter medidas relevantes.
Além das versões em C++, feitas com Qt5 e com Gtkmm-3, acrescentei uma versão em C, com GTK+ 3.0.
Uma aparente vantagem de usar GTK+ (C) com Glade/Anjuta, em comparação com Gtkmm (C++), é que passa a funcionar a edição automática da função tratadora de eventos a partir do editor visual da GUI, de um jeito semelhante ao que existe no QT Creator. O Glade permite indicar no arquivo XML o nome das funções em C associadas a cada evento de cada widget, e a função em C gtk_builder_connect_signals() se encarrega de fazer a ligação indicada no XML, depois que ele é carregado para o programa, em tempo de execução. Com o Gtkmm, isso não é possível, e cada conexão de evento (signal) a tratador (slot) tem de ser feita individualmente.
Particularmente, eu continuo gostando mais do jeito do Qt Creator, que faz essa conexão em tempo de compilação. Só não gosto muito do modo como isso é feito, que é acrescentando sintaxe nova, não padrão, ao código, o que obriga a passar o cada arquivo do código fonte por um preprocessador do próprio Qt, chamado MOC (meta object compiler), que converte essa sintaxe nova em C++ puro (e maior, obviamente), para que possa ser reconhecido pelo compilador. Felizmente, tal sintaxe extra é relativamente limitada.
Tendo as três versões do código, seguem abaixo algumas métricas comparativas:
1) Tamanho do código fonte.
$ wc palindrome-qt5/*.{cpp,h,ui}
35 67 695 palindrome-qt5/dialog.cpp
11 19 152 palindrome-qt5/main.cpp
25 39 315 palindrome-qt5/dialog.h
43 59 881 palindrome-qt5/dialog.ui
114 184 2043 total
$ wc palindrome-gtkmm/src/*.{cc,ui}
74 135 1470 palindrome-gtkmm/src/main.cc
48 93 1863 palindrome-gtkmm/src/palindrome_gtkmm.ui
122 228 3333 total
$ wc palindrome-gtk/src/*.{c,ui}
133 324 2752 palindrome-gtk/src/main.c
52 103 2093 palindrome-gtk/src/palindrome_gtk.ui
185 427 4845 total Desconsiderando os arquivos XML de definição da interface de cada versão, os arquivos de código ficam, respectivamente, com 71, 74 e 133 linhas, 125, 135 e 324 palavras, e 1162, 1470 e 2752 caracteres (depois de ter apagado um bocado de comentários das versões geradas pelo Anjuta).Se considerarmos como código fonte também os arquivos de suporte dos projetos, para que eles pudessem ser compilados em outras máquinas, a coisa cresce um bocado, especialmente no mundo GTK.
$ wc palindrome-qt5/*.{cpp,h,ui,pro}
35 67 695 palindrome-qt5/dialog.cpp
11 19 152 palindrome-qt5/main.cpp
25 39 315 palindrome-qt5/dialog.h
43 59 881 palindrome-qt5/dialog.ui
22 38 372 palindrome-qt5/palindrome-qt5.pro
136 222 2415 total
$ find palindrome-gtkmm \( \( -iname \*anjuta\* -o -iname \*cache\* \) -prune \) -o \( -type f -print0 \) | xargs -r0 wc
508 2024 15155 palindrome-gtkmm/install-sh
18 40 250 palindrome-gtkmm/Makefile.am
61 271 1611 palindrome-gtkmm/config.h.in
791 3616 23566 palindrome-gtkmm/depcomp
1813 4667 36144 palindrome-gtkmm/config.sub
18550 64913 581405 palindrome-gtkmm/configure
0 0 0 palindrome-gtkmm/AUTHORS
0 0 0 palindrome-gtkmm/README
215 965 6872 palindrome-gtkmm/missing
883 3329 27834 palindrome-gtkmm/Makefile.in
0 0 0 palindrome-gtkmm/NEWS
11156 38744 324404 palindrome-gtkmm/ltmain.sh
33 31 345 palindrome-gtkmm/configure.ac
1441 4808 43499 palindrome-gtkmm/config.guess
26 225 1499 palindrome-gtkmm/COPYING
370 2284 15752 palindrome-gtkmm/INSTALL
10476 39549 383279 palindrome-gtkmm/aclocal.m4
2 0 2 palindrome-gtkmm/ChangeLog
347 1107 7333 palindrome-gtkmm/compile
48 93 1863 palindrome-gtkmm/src/palindrome_gtkmm.ui
38 61 606 palindrome-gtkmm/src/Makefile.am
710 2627 22344 palindrome-gtkmm/src/Makefile.in
74 135 1470 palindrome-gtkmm/src/main.cc
157 553 4435 palindrome-gtkmm/autogen.sh
47717 170042 1499668 total
$ find palindrome-gtk \( \( -iname \*anjuta\* -o -iname \*cache\* \) -prune \) -o \( -type f -print0 \) | xargs -r0 wc
0 0 0 palindrome-gtk/intltool-extract.in
508 2024 15155 palindrome-gtk/install-sh
0 0 0 palindrome-gtk/intltool-merge.in
30 61 468 palindrome-gtk/Makefile.am
0 0 0 palindrome-gtk/intltool-update.in
82 356 2184 palindrome-gtk/config.h.in
791 3616 23566 palindrome-gtk/depcomp
1813 4667 36144 palindrome-gtk/config.sub
15857 54335 475701 palindrome-gtk/configure
0 0 0 palindrome-gtk/AUTHORS
0 0 0 palindrome-gtk/README
215 965 6872 palindrome-gtk/missing
920 3429 28927 palindrome-gtk/Makefile.in
0 0 0 palindrome-gtk/NEWS
11156 38744 324404 palindrome-gtk/ltmain.sh
44 46 724 palindrome-gtk/configure.ac
1441 4808 43499 palindrome-gtk/config.guess
0 0 0 palindrome-gtk/COPYING
370 2284 15752 palindrome-gtk/INSTALL
11136 42009 408576 palindrome-gtk/aclocal.m4
3 9 68 palindrome-gtk/po/POTFILES.in
2 8 48 palindrome-gtk/po/LINGUAS
221 860 7150 palindrome-gtk/po/Makefile.in.in
0 0 0 palindrome-gtk/po/ChangeLog
2 0 2 palindrome-gtk/ChangeLog
347 1107 7333 palindrome-gtk/compile
40 63 615 palindrome-gtk/src/Makefile.am
133 324 2752 palindrome-gtk/src/main.c
736 2701 23043 palindrome-gtk/src/Makefile.in
52 103 2093 palindrome-gtk/src/palindrome_gtk.ui
157 553 4435 palindrome-gtk/autogen.sh
46056 163072 1429511 total 2) Facilidade, tempo e consumo de recursos durante a compilaçãoAntes de cada compilação, eu limpei totalmente os caches de disco, a fim de ter medidas relevantes.
sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches' &&Os números acima podem ser resumidos na seguinte tabela comparativa.
/usr/bin/time sh -c 'cd palindrome-qt5
exec >/tmp/output 2>/tmp/errors
qmake &&
make' &&
wc -l /tmp/output && wc -l /tmp/errors
4.10user 0.41system 0:09.03elapsed 50%CPU (0avgtext+0avgdata 265660maxresident)k
104824inputs+176outputs (244major+171034minor)pagefaults 0swaps
6 /tmp/output
0 /tmp/errors
sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches' &&
/usr/bin/time sh -c 'cd palindrome-gtkmm
exec >/tmp/output 2>/tmp/errors
./configure &&
make' &&
wc -l /tmp/output && wc -l /tmp/errors
3.70user 0.70system 0:13.47elapsed 32%CPU (0avgtext+0avgdata 380384maxresident)k
199344inputs+10040outputs (417major+529936minor)pagefaults 0swaps
112 /tmp/output
0 /tmp/errors
$ sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches' &&
/usr/bin/time sh -c 'cd palindrome-gtk
exec >/tmp/output 2>/tmp/errors
./configure &&
make' &&
wc -l /tmp/output && wc -l /tmp/errors
1.61user 0.38system 0:11.65elapsed 17%CPU (0avgtext+0avgdata 61640maxresident)k
129288inputs+6768outputs (276major+407585minor)pagefaults 0swaps
131 /tmp/output
0 /tmp/errors
+--------+--------+--------+3) Tamanho e complexidade do código gerado
| Qt5 | Gtkmm | GTK+ |
+-----------------------------+--------+--------+--------+
| Tempo de compilação (s) | 9.03 | 13.47 | 11.65 |
| Ocupação de CPU (%) | 50 | 32 | 17 |
| Tempo×Ocupação (s) | 4.52 | 4.31 | 1.98 |
| Consumo de memória (MiB) | 259.43 | 371.47 | 60.195 |
| Leituras em disco (blocos) | 104824 | 199344 | 129288 |
| Escritas em disco (blocos) | 176 | 10040 | 6768 |
| Mensagens de saída (linhas) | 6 | 112 | 131 |
+-----------------------------+--------+--------+--------+
+--------+--------+--------+4) Execução
| Qt5 | Gtkmm | GTK+ |
+-------------------------------+--------+--------+--------+
| Tamanho not stripped (bytes) | 28032 | 141576 | 22792 |
| Tamanho stripped (bytes) | 18984 | 31976 | 10600 |
| Tamanho do XML da UI (bytes) | -- | 1863 | 2903 |
| Bibliotecas de dependências | 43 | 79 | 71 |
| Tamanho das bibliotecas (MiB) | 56.121 | 36.602 | 28.363 |
| Total de arquivos | 44 | 81 | 73 |
| Total em disco (MiB) | 56.141 | 38.452 | 30.419 |
+-------------------------------+--------+--------+--------+
+--------+--------+--------+
| Qt5 | Gtkmm | GTK+ |
+------------------------------+--------+--------+--------+
| Consumo de memória (MiB) | 58.156 | 36.047 | 27.734 |
| Leituras em disco (blocos) | 65688 | 67160 | 51232 |
| Arquivos consultados | 1395 | 736 | 728 |
| Arquivos abertos com sucesso | 1302 | 682 | 674 |
+------------------------------+--------+--------+--------+
5. Re: GUI em GTK é código puro e no QT é só desenhar no QTcreator???
Enviado em 09/10/2017 - 22:20h
Realmente seu artigo é muito interessante.
eu me pego no dilema de escolher um desses dois tookits para começar.
O Qt parece realmente facilitar as coisas para o novo aprendiz, o que não me atrai é o moc.
O Gtk me agrada mais só que tem limites para a quantidade de plataformas (moveis e desktops) que existem hoje.
Mas qual desses você utiliza para criar softwares?
eu me pego no dilema de escolher um desses dois tookits para começar.
O Qt parece realmente facilitar as coisas para o novo aprendiz, o que não me atrai é o moc.
O Gtk me agrada mais só que tem limites para a quantidade de plataformas (moveis e desktops) que existem hoje.
Mas qual desses você utiliza para criar softwares?
6. Re: GUI em GTK é código puro e no QT é só desenhar no QTcreator???
Enviado em 10/10/2017 - 18:08h
lyumar escreveu:
Realmente seu artigo é muito interessante.
eu me pego no dilema de escolher um desses dois tookits para começar.
Se a escolha é entre esses dois, eu recomendo o Qt, com o aviso de que tem muito de gosto pessoal nessa recomendação.Realmente seu artigo é muito interessante.
eu me pego no dilema de escolher um desses dois tookits para começar.
O Qt parece realmente facilitar as coisas para o novo aprendiz, o que não me atrai é o moc.
Como eu disse acima, nem a mim. Se fosse possível fazer em C++ puro, seria melhor, na minha opinião.Mas, comparando com as alternativas, o MOC vira um alívio. O GTK+ “puro” em C recorre tão pesadamente a macros que virou quase uma outra linguagem. E essa “quase outra linguagem” é tão cabalística que se decidiu criar efetivamente uma outra linguagem, chamada Vala, que é usada como front-end para gerar o código C do GTK+.
Front-end por front-end, o MOC acaba sendo menos intrusivo, eu acho. Algumas palavras a mais no meio de um código que é essencialmente C++. Com GTK+, para programar em “C puro”, sou obrigado a encher o código de macros pouco legiveis, ou a aprender uma linguagem completamente nova.
O Gtk me agrada mais só que tem limites para a quantidade de plataformas (moveis e desktops) que existem hoje.
O agrado é um fator relevante, especialmente se você não gosta de C++ nem de QML e se não pretende colocar sua aplicação em múltiplas plataformas.Outro fator em favor de GTK+ seria a possibilidade, desejo ou necessidade de usar para desenvolvimento uma linguagem para a qual não existam bindings do Qt.
Contudo, se C++ não for um problema e se você vislumbra ter suas aplicações rodando em algo que não seja um desktop (e Unix-like, especificamente, já que mesmo o suporte a Windows parece não ser lá essas coisas), eu não vejo muitas razões para preferir GTK+.
Mas qual desses você utiliza para criar softwares?
Eu quase nunca uso GUI, e não trabalho corriqueiramente com desenvolvimento de aplicações, porque minha área de atuação é infraestrutura. Meus desenvolvimentos são mais de ferramentas para automatização de procedimentos e processos do que para interação com usuário.Entretanto, nas poucas vezes em precisei de GUI, usei Qt, e com sucesso.
Responder tópico
Entre na sua conta para responder.