A única barreira: Sinceramente era a única coisa que a QT poderia fazer para não ser atropelada pela GTK, considerando que os maiores sucessos opensources (Openoffice,Firefox/Thunderbird) para a plataforma Windows eram GTK (com um motivo claro), seria lógico pensar que no Desktop Linux essa biblioteca iria ganhar mais respaldo e alcance.
Agora é esperar para que apareçam bom aplicativos Qt para a plataforma Windows(K3b ?), ao contrário de uns e outros acho que este processo é muito frutífero.

opa!: Peralá! Gosto muito do GTK, mas não acho que seja verdadeiro que Firefox/Thunderbird e muito menos o OpenOffice o utilizem na versão Windows.

Sim, GTK é o backend gráfico padrão do Firefox no Linux, mas também há uns loucos portando-o para Qt, para melhor integração e look-and-feel e blablabla com o ambiente KDE.

O OpenOffice nem pensar! É um projeto completamente à parte e autocontido, usando seu próprio framework de componentes, widgets e até fontes.

Que eu saiba, o único aplicativo open-source que roda no Windows com o GTK mesmo é o GIMP. Bem, Gnumeric também está chegando e outros aplicativos Gnome Office... tem também o Inkscape, excelente para criação de gráficos vetoriais em formato SVG padrão.

Quanto ao Qt4... aos Trolls, o que eles merecem... huhuhu...

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

Dúvida: Agora fiquei na dúvida, se bem que nunca compilei para saber a verdade, mas como no linux a compilação do Firefox/Thunderbird era com GTK imaginei que no Windows seria o mesmo(seria o caminho mais fácil), se não é esta qual é a biblioteca ?(resquício do Netscape ?)
Quanto ao Openoffice, so sorry.
No entato,mesmo em quantidade menor, ainda não desqualifica o argumento.

Trolls?: > Quanto ao Qt4... aos Trolls, o que eles merecem... huhuhu...

Hehehe, esse foi um comentário digno de um Troll Nemessis. :)

Lembre-se meu jovem que nada serve para tudo. GTK pode ser o toolkit perfeito para você, mas de repente nem todos pensam assim. Uma dica: Quando for tecer algum tipo de comentário ou crítica, tente basear-se em bon argumentos técnicos e não em gostos pessoais, por que senão fica feio. ;)

[]s

lmvaz

--
"Quem come de tudo está sempre mastigando" --XSandro

Respondendo a dúvida: Segue o link para o requerimento de compilação do Firefox no windows:
http://www.mozilla.org/build/win32.html
Sem GTK :-(
Parece que usam o SDK da Microsoft *eka* ;-D.

certo, vou morder a isca: Eu estava só fazendo referência ao nome da empresa... juro... ;)

De qualquer modo: GTK é mais rápido, leve e flexível ( principalmente para desenvolvimento com outras linguagens ) do que Qt. Não é um bloatware kitchen-sink e com visual pirulito a la WINXP...

ficou bom? :)

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

ERRADO "opa!": "Que eu saiba, o único aplicativo open-source que roda no Windows com o GTK mesmo é o GIMP."

Isso é totalmente errado, existem MUITOS software p windows feitos em GTK. Só procurar no google

Hmmm: Ficou sim, embora você exagere de vez em quando nos adjetivos. De qualquer forma ficou divertido. :)

[]s

lmvaz


--
"Quem come de tudo está sempre mastigando" --XSandro

-: O GTK popularizou-se muito no linux, a ponto de usuarios KDE sempre recorrerem a aplicativos GTK e ter aquela horrenda composição de fontes e botoes que não se combinam (widgets QT vs GTK com temas diferentes).

Tenho visto softwares fechados usando GTK como realplayer, helix (ok, é opensource), acrobat reader, vmware (interessante que 1 anos atras usava QT), nerolinux,... a licença atual da QT ainda é comercial para estas empresas e não mudará muita coisa.

A quantidade de aplicativos GTK que uso é tão grande que passaria a usar o GNOME se ele nao fosse tao lerdo (já melhorou muito) e tão pobre em recursos de painel de controle (video, impressao, mouse) como o do KDE. Aplicativos QT que me fariam falta : konqueror e k3b.

Deviam era portar o KDE para GTK e dispensar o gnome :))))))
Se ficaria a mesma coisa nós não sabemos...

É isso mesmo. : É isso mesmo.

Tem o Gaim que eu saio por aí, instalando, onde quer que deixem, pra usar no lugar do MSN Messenger.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Carlos Wagner - São Luís / MA

Odeio "trollices" como esta. : Odeio "trollices" como esta.

Sei que estou alimentando um flame, mas, faz parte da vida...

Vamos lá!

Creio que quem critica o Qt é porque nunca programou com ele. Ou talvez nem saiba programar, e tenha sua vida limitada a baixar programinhas e digitar configure; make; make install, e depois criticar duramente tais programas.

Mas vamos lá aos verdadeiros argumentos técnicos que demontram a superioridade do projeto Qt em relação a :

- Pra começar, Qt É UM TOOLKIT DE VERDADE. Quando digo isto, me refiro ao fato de que ele fornece classes (ah vc não sabia? Sim, é orientado a objetos) para N+1 funcionalidades modulares. Veja mais em: http://www.trolltech.com/products/qt/editions.html.

- A orientação a objetos é nativa, sem o uso de wrappers, ao contrário de muitos outros toolkits.

- Com o Qt você possui um loop de eventos que permite a criação de rotinas assíncronas ao seu programa, graças ao simples mecanismo signal/slot. Quer ser avisado quando um botão é clicado? Basta conectar a sua função slot ao sinal do botão. E este mecanismo é análogo para eventos de rede (sockets, HTTP, DNS, ...), arquivos, etc, etc, etc... Nada de callbacks que tornam o seu código uma verdadeira macarronada.

- Qt pode ser utilizado não apenas para aplicações gráficas. Ou seja, serve também para CLI. E com todo o mecanismo de eventos.

- Mais classes, desde as básicas: String, List, File, às avançadas: SQL, XML, e até mesmo OpenGL.

- O suporte a temas é autamente extensível.

- Excelente ferramental para i18n.

- Dual license: GPL e commercial.

- Multi plataforma. Caso sua aplicação não utilize funções do SO, quase nenhuma adaptação precisa ser feita.

- Entre muitos outros...

Lembro-vos que a Trolltech começou bem pequena, disponibilizando o Qt com a QPL license e a comercial. Hoje possui uma versão de seu toolkit especificamente para embedded devices (Qtopia), como alguns celulares.

Sem querer desmerecer outras ferramentas "similares", mas caiam na real e saibam valorizar o que realmente merece!

A Trolltech merece muitas congratulações por este excelente trabalho.

Por fim: não, não trabalho para a Trolltech e não tenho a versão comercial. Utilizo a GPL, e sem dúvidas vou estar utilizando (mais uma vez) este toolkit para o desenvolvimento de aplicações open source, ao contrário de alguns que só colocam defeito sem moverem uma palha.

Desculpem pelo desabafo...

Abraços a todos.

"De qualquer modo: GTK é mai: "De qualquer modo: GTK é mais rápido, leve e flexível"

Mais rápido não é =/, só se quando tu usas QT já cai na swap logo de cara ;)

Faz uma tabela de 1000 x 1000 em GTK e depois otra em QT... aí tu ver quem é mais rápido! Talvez com a mudança pra Cairo GTK deixe de ser tão lerdo pra renderização comparado à QT e qualquer outra biblioteca de Widgets(apesar de que QT é bem mais que isso), mas no momento é praticamente a biblioteca pra Linux mais lerda que existe :P

PS: costumo usar apps em GTK pois a maioria dos em QT leva o "bloat" do KDE junto(não que eu ache o KDE ruim, mas não gosto de usar)

Feiúra é pecado: GTK é horroroso. Só o Motif é pior que aquilo. Em caso de interface gráfica, esse pecado é grave.

então pq tmb trolla?: "Qt É UM TOOLKIT DE VERDADE. Quando digo isto, me refiro ao fato de que ele fornece classes"

"A orientação a objetos é nativa"

oh! tinha esquecido como o pessoal adestrado a pensar orientado a objetos é fundamentalista! isso vem de berço... mas tem cura! Eu recomendo uma dose de Haskell e um pouco de Python para clarear as idéias... ^_^

Então, Tcl/Tk e Gtk não são toolkits?! E Gtk é sim um framework orientado-a-objetos, completo com hierarquias de classes, métodos static, sinais e callbacks. Falta apenas syntatic sugar, mas isso é apenas uma frescura redundante...

"Com o Qt você possui um loop de eventos que permite a criação de rotinas assíncronas ao seu programa, graças ao simples mecanismo signal/slot."

como em gtk_main_loop()?
ou g_signal_connect( gobject, sinal, callback, extraops )?

"Nada de callbacks que tornam o seu código uma verdadeira macarronada."

Se vc puder me explicar de forma racional de que forma a tal função "slot" difere de um callcack além de terminologia, posso até pensar em concordar com vc...

"Qt pode ser utilizado não apenas para aplicações gráficas. Ou seja, serve também para CLI. E com todo o mecanismo de eventos."

Pra que vc acha que serve o framework GLib e GObject, base para Gtk ou aplicativos CLI?

"Mais classes,"

meu filho, nem só de OO viverá o homem. Orientação-a-objetos não é o fim último da tecnologia da informação. É apenas mais uma técnica para se estruturar programas e modelar regras de negócio. Não necessariamente a melhor. Modularização e encapsulamento é que são a alma do negócio para controle da complexidade de sistemas. E esses não são conceitos exclusivos de OO...

É muito mais simples para muitos projetos open-source rapidamente criarem uma API de funções do que um framework OO. E o resultado vai ser o mesmo, quer proponentes OO queiram ou não.

"O suporte a temas é autamente extensível."

Pelo visto, alguém realmente não conhece muito GTK e quer tacar pedras em quem não conhece Qt. e tmb não conhece muito português...

"GPL e commercial"

LGPL. em outras palavras, irrestrita para projetos open-source ou proprietários.

"Multi plataforma."

Gtk e Qt rodam em *nix e Win*. Tcl/Tk também roda no Mac. :)

"A Trolltech merece muitas congratulações por este excelente trabalho."

oh, sem dúvida! Como toda empresa que contribui significativamente com produtos open-source.

"Sem querer desmerecer outras ferramentas "similares", mas caiam na real e saibam valorizar o que realmente merece!"

Qt, Gtk, Tk, Fox, wxWidgets, XUL, XForms, html e Swing sempre vão receber meu apoio quando se trata de projetos de interfaces gráficas abertas e independentes da infraestrutura MFC do grande monopólio...

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

GTK is not a real toolkit: " oh! tinha esquecido como o pessoal adestrado a pensar orientado a objetos é fundamentalista! isso vem de berço... mas tem cura! Eu recomendo uma dose de Haskell e um pouco de Python para clarear as idéias... ^_^ "

Certo, mestre. Prometo aprender Smalltalk também.

" Então, Tcl/Tk e Gtk não são toolkits?! E Gtk é sim um framework orientado-a-objetos, completo com hierarquias de classes, métodos static, sinais e callbacks. Falta apenas syntatic sugar, mas isso é apenas uma frescura redundante... "

Não. São apenas frameworks gráficos. Onde estão as classes (ou módulos) com funcionalidade de rede, XML, SQL, OpenGL, etc, etc, etc...?

E caso esteja com medo do Qt ser um "bloatware kitchen-sink", dê uma olhada na separação de módulos da nova versão.

Sobre o "suporte nativo" a C++ do GTK, qual o motivo da existência do gtkmm?

" como em gtk_main_loop()?
ou g_signal_connect( gobject, sinal, callback, extraops )? "

Mesmo na CLI? Oops, acho que não né? Eu dependo do loop de eventos do X11, no UNIX? Que tal algo mais inteligente como um simples select()?

Não fico dependente do mundo GUI quando o último parâmetro da chamada QApplication::QApplication ( int & argc, char ** argv, bool GUIenabled ) é FALSE.

" Se vc puder me explicar de forma racional de que forma a tal função "slot" difere de um callcack além de terminologia, posso até pensar em concordar com vc... "

Me desculpe, o que é um callcack?

" Pra que vc acha que serve o framework GLib e GObject, base para Gtk ou aplicativos CLI? "

Nada mais que um conjunto de funções, similar ao STL do C++.

" meu filho, nem só de OO viverá o homem. Orientação-a-objetos não é o fim último da tecnologia da informação. É apenas mais uma técnica para se estruturar programas e modelar regras de negócio. Não necessariamente a melhor. Modularização e encapsulamento é que são a alma do negócio para controle da complexidade de sistemas. E esses não são conceitos exclusivos de OO... "

Ok, mestre. Se preferir, vou refazer a minha frase do post anterior:

- Mais funções, desde as básicas de manipulação de Strings, Listas, Files, às avançadas: SQL, XML, e até mesmo OpenGL.

Ou seja, o ponto desta afirmativa não era em defesa da orientação a objetos, e sim funcionalidade.

Mas, já que você tocou no assunto, gostaria de te perguntar: se OO é tão ruim assim, por que raios Java e PHP, e até mesmo Ruby estão tão "na moda" ultimamente? Tudo bem, concordo que talvez não seja esse o motivo, mas já que modularização e encapsulamento são tão importantes, por que não utilizar um ferramental que já me forneça isso por padrão? Pra que ficar criando wrappers ou whatever, ficar reinventando a roda usando structs e criando funções ***_new() se temos classes, construtores / destrutores? Além de muitos outros pontos...

" É muito mais simples para muitos projetos open-source rapidamente criarem uma API de funções do que um framework OO. E o resultado vai ser o mesmo, quer proponentes OO queiram ou não. "

Sem dúvida que o resultado vai ser o mesmo. Porém tenho minhas dúvidas se a dificuldade e o tempo da modelagem OO é tão grande quanto você diz. Talvez seja pelo pouco tempo destinado ao startup (projeto e modelagem) que muitos aplicativos open-source não vingam. E isso se reflete não só no mundo open-source.

" > O suporte a temas é autamente extensível."
" Pelo visto, alguém realmente não conhece muito GTK e quer tacar pedras em quem não conhece Qt. e tmb não conhece muito português... "

Reconheço meu erro de português. Entendido então, mestre. Você me corrige no português e eu te ajudo com conceitos básicos de toolkits, OO, programação, etc...

"Gtk e Qt rodam em *nix e Win*. Tcl/Tk também roda no Mac. :)"

Pois é, Qt pode ser utilizado em Unix, Windows e Mac. Veja http://www.trolltech.com/products/qt/index.html

"Qt, Gtk, Tk, Fox, wxWidgets, XUL, XForms, html e Swing sempre vão receber meu apoio quando se trata de projetos de interfaces gráficas abertas e independentes da infraestrutura MFC do grande monopólio..."

Que bom.

Kommander...: Gosto mais do GTK, o QT em geral so funciona bem dentro do KDE, existem excessões como o Opera.

Mas falta um programa como o Kommander para se fazer interfaces simples com GTK

Graphical Toolkits: "Prometo aprender Smalltalk também."

Mas aí, vai continuar um fundamentalista OO ferrenho. ;)

"São apenas frameworks gráficos. Onde estão as classes (ou módulos) com funcionalidade de rede, XML, SQL, OpenGL, etc, etc, etc...?"

Cacete! É um toolkit gráfico! Um widget toolkit! Seria como a VCL do Delphi, sem todas as palhetas de ferramentas extras dos produtos comerciais. Putz! Se você quer um sistema operacional completo, ou outro Java ou .Net, ( ou ainda um Emacs ), você sabe onde encontrar...

Onde estão os módulos com a funcionalidade? Estão nos paths padrão para bibliotecas, geralmente /usr/lib! Ora essa!

E é bom que o projeto seja bem focalizado assim. Quando desenvolvedores perdem as rédeas do propósito projeto, ele começa a ser tudo e nada. É a tal filosofia do *nix: faça seus programas fazerem apenas uma coisa, e bem.

"Mesmo na CLI?"

Sim. Tá vendo no que dá falar sem saber?

"Eu dependo do loop de eventos do X11, no UNIX?"

De forma alguma. Caso contrário, vc não teria GIMP no Windows.

"Que tal algo mais inteligente como um simples select()?"

A opção de API é sua: basta implementar uma em função das primitivas disponíveis.

"Não fico dependente do mundo GUI quando o último parâmetro da chamada QApplication::QApplication ( int & argc, char ** argv, bool GUIenabled ) é FALSE."

É claro que, se sua aplicação _for_ dependente de uma GUI, o último parâmetro como FALSE não vai fazer milagres. Simplesmente vai encerrar a execução e dar uma desculpa esfarrapada qualquer na CLI...

"Me desculpe, o que é um callcack?"

É quando um sujeito inventa uma desculpa qualquer para não dar uma resposta que ele sabe ser impossível. :)

"o ponto desta afirmativa não era em defesa da orientação a objetos, e sim funcionalidade."

Agora entendo pq vc se amarra no bloatware Qt: ele é o mesmo que Java ou .Net, ou seja, uma camada extra de redundância acima do sistema operacional, reimplementando de forma +- portátil e padronizada um porrilhão de funcionalidade amplamente disponível na plataforma subjacente. Vc vê muito disso em projetos de empresas comerciais querendo lhe vender a-solução-mais-integrada-para-seus-problemas. é só mais outro peixe...

Bem, Gtk é um toolkit gráfico, que se vale de seu framework de base chamado GLib e GObject para implementar OO, sinais, loops de eventos e alguns ADTs de conveniência, como coletâneas, para construção de GUIs. Ele não tem uma empresa comercial por trás bancando seu desenvolvimento, por isso recursos são limitados.

Mas isso é bom, pois o projeto se concentra em fazer o que se espera que faça ( ser um widget toolkit ), não perder tempo reimplementando funcionalidade de outros projetos open-source, como libxml para processamento XML ou libpgsql, para acesso a banco-de-dados PostgreSQL...

"se OO é tão ruim assim, por que raios Java e PHP, e até mesmo Ruby estão tão 'na moda' ultimamente?"

só se por ultimamente vc se referir aos últimos 15 anos, pelo menos.

OO é amplamente usado na indústria por vários motivos. Primeiro, pq é uma boa técnica para simulações. Modelar regras de negócios ou interfaces gráficas, por exemplo.

Há outro componente importante para sua popularização, da qual se valem vendedores de ferramentas de desenvolvimento: sistemas OO frequentemente se transformam em um amálgama de hierarquias profundas e para lidar com essa complexidade poderosos navegadores de código e parsers online foram integrados ao ambiente de desenvolvimento, permitindo rápida inspeção de métodos e atributos de um objeto. Isso por sua vez tornou muito fácil desenvolver software OO, com bastante agilidade, mesmo por pessoas sem grandes conhecimentos ou habilidade. Enfim, criou um mercado barato de programadores estúpidos facilmente substituíveis... isso agradou às gerências, que por fim, demandaram mais e mais OO...

Concorda com meus argumentos? eu acho que é +- fiel a realidade...

"já que modularização e encapsulamento são tão importantes, por que não utilizar um ferramental que já me forneça isso por padrão?"

Não vou discutir os motivos dos desenvolvedores GTK, mas eles citam no FAQ que um dos motivos principais é que C é bem mais facilmente portável...

"Porém tenho minhas dúvidas se a dificuldade e o tempo da modelagem OO é tão grande quanto você diz."

O problema não é esse. Eu estava me referindo a integração de APIs de outros projetos, se isso ocorresse, claro. Quis dizer que seria bem mais fácil simplesmente implementar uma API wrapper que simplesmente refletisse a API de, digamos, libxml, com funções, do que criar toda uma hierarquia OO para esse propósito...

"Talvez seja pelo pouco tempo destinado ao startup (projeto e modelagem) que muitos aplicativos open-source não vingam."

Pode ser. Um pouco de planejamento não faz mal a ninguém. Mas ficar só em planejamentos ambiciosos e nunca pôr a mão na massa, ou quando pôr, sentir o peso de decisões erradas de projeto, talvez atrapalhe mais que isso. Vide o kernel do GNU, HURD...

"Você me corrige no português e eu te ajudo com conceitos básicos de toolkits, OO, programação, etc..."

eu acho que não. vc parece meio equivocado com alguns conceitos... mas obrigado pela intenção, mesmo assim! :)

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

> Creio que quem critica o Qt: > Creio que quem critica o Qt é porque nunca programou com ele. Ou talvez nem saiba programar, e tenha sua vida limitada a baixar programinhas e digitar configure; make; make install, e depois criticar duramente tais programas.

Começou a argumentação com uma falácia e ataque pessoal. Diria que é justamente o contrário do que você disse, quem já programou (ou conhece) é que realmente está apto a criticar.

> Pra começar, Qt É UM TOOLKIT DE VERDADE. Quando digo isto, me refiro ao fato de que ele fornece classes (ah vc não sabia? Sim, é orientado a objetos) para N+1 funcionalidades modulares.

O Qt está mais para um framework gráfico do que toolkit (acho que você confundiu os termos). Em suma um framework tende a incluir classes/bibliotecas além do propósito principal da biblioteca gráfica/toolkit. Este é mais ou menos o caso do Qt, que fornece além de classes relativas aos widgets também funcionalidades como sockets, comunicação com base de dados, classes "úteis", por aí vai.

Isso tem um preço. À medida que o projeto decide por incluir essas classes a utilizar classes de terceiros, a ferramenta incha e seu desenvolvimento fica mais complexo.

> Com o Qt você possui um loop de eventos que permite a criação de rotinas assíncronas ao seu programa, graças ao simples mecanismo signal/slot. Quer ser avisado quando um botão é clicado? Basta conectar a sua função slot ao sinal do botão. E este mecanismo é análogo para eventos de rede (sockets, HTTP, DNS, ...), arquivos, etc, etc, etc... Nada de callbacks que tornam o seu código uma verdadeira macarronada.

Bom, primeiro você precisa provar que os callbacks tornam o código uma "macarronada", minha experiência com callbacks no FLTK demonstra que não --embora também seja possível usar o mecanismo signal/slot. Já usei o Qt (versão 2 ou 3) e fiquei chocaco com o uso intenso de macros (o próprio SIGNAL() e SLOT() são macros) e a gambiarra do "meta object compiler", vulgo MOC, necessitando um pré-processador para então se gerar o código efetivo em C++ (juntamente com as extensões próprias do Qt). Talvez tenha mudado na versão 4, mas não acredito.

> Sem querer desmerecer outras ferramentas "similares", mas caiam na real e saibam valorizar o que realmente merece!

Acho que você deveria compreender que existem gostos e necessidades diferentes. Sem dúvida o Qt é um grande toolkit/framework, e a TrollTech está de parabéns. O GTK é outro, inclusive mais popular. Eu já prefiro uma biblioteca gráfica que preza pela eficiência (em tempo e espaço), elegância (código limpo, C++ estrito) e flexibilidade, por isso uso o FLTK (FOX e TOAD também são outras mais ou menos nesse estilo). Certamente o toolkit não vem com centenas classes de "suporte" no pacote, mas geralmente encontra-se tais funcionalidades em classes de terceiros.

Agora, evite expressões como "quem critica o Qt é porque nunca programou com ele", "Ou talvez nem saiba programar", "vamos lá aos verdadeiros argumentos técnicos que demontram a superioridade", "Qt É UM TOOLKIT DE VERDADE" (esse até gritou), "ao contrário de muitos outros toolkits" e "caiam na real e saibam valorizar o que realmente merece!". Pois são argumentos apaixonados, carregados de emoção. E, claro, são parciais e enviesados.

Aproveitando, passo um link interessante (embora não seja muito recente) sobre comparações entre "toolkits": GUI Toolkits for The X Window System.

--
FLTK fltk.org (Fast Light C++ GUI Toolkit)

> Gosto mais do GTK, o QT em: > Gosto mais do GTK, o QT em geral so funciona bem dentro do KDE, existem excessões como o Opera.

Em tese nenhum aplicativo escrito em Qt (QT é quicktime :-)) requer ou funciona melhor no KDE. É claro que rodando o KDE, as bibliotecas gráficas do Qt já estariam carregadas (pelo menos grande parte), o que agilizaria o carregamento.

Acontece que muitos programadores acabam amarrando seus aplicativos (isso acontece no GTK/GNOME também) aos componentes do desktop, e acabam portanto dando a sensação de que aplicativos Qt funcionam melhor no KDE.

--
FLTK fltk.org (Fast Light C++ GUI Toolkit)

Não merecia resposta, mas...: Mude o tema então. Resolvido!
--
LinuxFUD, o TIRA-TEIMA dos ataques ao software livre: http://linuxfud.org

sinceramente GTK/Gnome são v: sinceramente GTK/Gnome são verdadeiras carroças, lentidão total, sem falar que não são muito bonito, e em geral os componentes do GTK ocupam muito espaço na tela, um mero botão toma quase um quinto da tela. Tava vendo o Gnome que vem com suse 9.3 e caras que coisa horrivel, no menu tudo é agigantadamente enorme, o menu ocupa um terço da tela :|
Não quero acabar com o Gnome/GTK, mas só de iniciar o gnome, já são 250m de ram usados!!! Eu hein, o linux sofre bastante com o problema de que seus aplicativos consomem grandes quantidades de ram, mas o Gnome/GTK parece piada. O que é o Cairo? Este novo Qt permite gráficos 3D, vamos ter um KDE 3D? Possui gráficos vetoriais?

falows

Tema, eficiência e desktop: Eu gosto mais do KDE, e o maior problema que já tive foi em relação aos temas: eu quase migrei para o Gnome por causa disso, porém, quando carreguei o K3b no Gnome, e vi o visual, bonito, porém completamente incompatível, cai fora :(
Estou tentando resolver isso, usando KDE, com um tema GTK agradável e parecido um pouco com o Plastik, o Clean Looks. Para minha muita sorte, o Fedora Core 4, vêm por padrão com esse tema, e concordemos, fica um visual bem limpo e compatível. Resta uma dúvida: nem posso imaginar quantas bibliotecas são carregadas a mais por isso, a eficiência do desktop, vai pro espaço!
Para mim, o maior problema dos SO/Linux são compatibilidade, e padronização, mas nesse caso, como resolveriam o problema?


A Física é tão subjetiva quanto qualquer outra empresa humana.
Albert Einstein

Putz!!!! : Putz!!!!

Este nemesis só fala trollice e asneira!!

Credo!!!

Hein? Muda o tema, oras, pois: Hein? Muda o tema, oras, pois pois...

--
Adam Victor Nazareth Brandizzi
Estudante de Ciência da Computação - UnB
Jabber: brandizzi@jabber.org
"Real programmers don't use Pascal; just integer ones can do it."

-: Colega, esse é um problema do KDE também. Tem momentos que preciso arrastar a janela da direita para esquerda porque a janela "vazou". Uso 1024x768 com o tema plastik e esse problema ocorre com frequencia, se altero o tamanho das fontes ajuda porque a maior parte dos vazamentos ocorre porque textos longos simplesmente nao fazem wrap.
Acho que estou desatualizado, KDE e GNOME foram feitos para 1280x1024.

GTK-QT: Vc conhece o GTK-QT ?
http://www.kde-look.org/content/show.php?content=20042

É bem legal, é uma engine que faz o gtk ficar com a aparencia do tema que vc está usando no qt.

Está em desenvolvimento, mas tenho usado e tido ótimos resultados.

O firefox não fica bom com GTK-QT, mas o xchat, o amule(versão GTK2), etc... ficam perfeitos.

Pra quem usa KDE, vale a pena testar.

Já usou o Gnome 2.10? Pois d: Já usou o Gnome 2.10? Pois deveria. Tem um ótimo sistema de gerenciamento de discos, redes, pastas compartilhadas(com extensão ao nautilus) e outras coisinhas mais legais. Sem falar nas preferências, que permitem um alto grau de personalização, o gconf-editor que é muito bom para fazer mudanças "profissionais". Que mal lhe pergunte, qual foi a ultima versão que usou do GNOME?

Quer gravar? Use o Nautilus. O queimador dele é de alta qualidade. Internet? Use o Epiphany, que tem como engine o Gecko.

Experimente que você vai gostar.

[]s!

Vinícius Medina
Usuário Linux 383765
É usuário de Linux? Mostre a sua cara!

-: Justamente o GNOME 2.10!
Ele é o padrao no ubuntu hoary. Não sei se é o Xorg ou se a distro é menos otimizado para 686 (p4), mas me parece + lento. Tudo que faço ou clico vejo a luz do HD acender, a reposta aos clicks é demorada, isto me fez baixar o kubuntu e instala-lo para fazer uma comparação e definitivemente o hd parou de fazer tantos acessos e parece estar mais rápido.
Parece ser um problema com o gnome, já que com o XFCE a coisa anda bem. Meu desktop na realidade era o XFCE, mas nos ultimos tempos por causa dum pessoal aqui que padronizou o KDE tenho usado mais este, mas quando viram as costas volto para o XFCE.

vcs é que estão confundindo termos!: "mais para um framework gráfico do que toolkit"

GTK ( Gimp ToolKit )
TCL/TK ( Tool Command Language ToolKit )
Qt ( q-sei-lá-das-quantas toolkit )
FLTK ( Fast-light toolkit )

Toolkit nada mais é que um conjunto de ferramentas. Pode significar praticamente qualquer coisa. Pode-se dizer que as ferramentas padrão dos *nix formam o seu toolkit. O batcinto é o toolkit do Batman. :)

No caso daquelas bibliotecas, está se referindo a um toolkit gráfico, um conjunto básico de rotinas para manipulação de widgets ( controles visuais ). É só isso. Aliás, um framework é a mesma porcaria. A terminologia muda para vendedores poderem vender seu peixe como se fosse algo inédito...

No caso de Qt, como eu disse, eles basicamente querem fazer o mesmo que Java, .Net ou o framework Delphi da Borland: recriar à sua própria maneira toda a funcionalidade já existente no SO de uma forma +- portátil e padronizada, para que possam vender a solução para tantas plataformas quanto possível...

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

GTK-QT: Realmente o pessoal não sabe moderar, eu só quis dar uma dica e me moderaram, lá vou eu de novo ;-)

Vc conhece o GTK-QT ?
http://www.kde-look.org/content/show.php?content=20042

É bem legal, é uma engine que faz o gtk ficar com a aparencia do tema que vc está usando no qt.

Está em desenvolvimento, mas tenho usado e tido ótimos resultados.

O firefox não fica bom com GTK-QT, mas o xchat, o amule(versão GTK2), etc... ficam perfeitos.

Pra quem usa KDE, vale a pena testar.

tente ClearLooks: disponível em
http://art.gnome.org

Visual mais claro e elegante que o Luna do XP...

mas o servidor está fora pois estão fazendo manutenção...

e não, nem com o tema normal, é impossível algo ser pior que Motiff...

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

GTK-QT: Já utilzei sim o gtk-qt, mas é justamente esse o problema: no firefox e em alguns outros programas ele fica esquesito!
Um conselho? Mude o tema gtk! Vc pode mudá-lo manualmente, ou utilizar um programa, o gtk-switch. Essa solução me agradou bem mais :)


A Física é tão subjetiva quanto qualquer outra empresa humana.
Albert Einstein

eu nao!: Eu vi que estava moderado, e coloquei seu comentário como "interessante".
Não sabem mesmo moderar! Parece preconceito oras!


A Física é tão subjetiva quanto qualquer outra empresa humana.
Albert Einstein

O problema, creio eu, é o GN: O problema, creio eu, é o GNOME. Depois que baixou o espírito de Redmond dele, ele ficou muito mais simples, mas começou a carregar uma penca de daemons. E dá-lhe servidor Samba, VFS, CUPS... Entretanto, você pode retirá-los.

--
Adam Victor Nazareth Brandizzi
Estudante de Ciência da Computação - UnB
Jabber: brandizzi@jabber.org
"Real programmers don't use Pascal; just integer ones can do it."

Apesar de todo flame à volta: Apesar de todo flame à volta deste comentário, e da ponta de exagero, devo concordar que Qt estava perdendo um espaço muito grande. Antigamente Qt era muito mais usada. Espero, então que esta guinada aumente sua popularidade para que, de uma tacada só, a Trolltech ganhe mais e continue financiando o software livre e a concorrência melhore tecnicamente tanto GTK+ quanto Qt.

Apesar de tudo, hoje é um belo dia :)

--
Adam Victor Nazareth Brandizzi
Estudante de Ciência da Computação - UnB
Jabber: brandizzi@jabber.org
"Real programmers don't use Pascal; just integer ones can do it."

acho que não!: Acho que ele estava se referindo a GTK puro, mesmo.

Não tive condições ainda de fazer o tal teste da tabela 1000 X 1000, por isso não vou comentar. Mas acho _possível_ ser mais lento, sim. Não por culpa de um renderizador bitmap ao invés de um vetorial, mas sim porque GTK é bem mais dinâmico e flexível do que Qt.

Isso é ótimo para se programar em outras linguagens que não C, principalmente linguagens dinamicamente tipadas como Python ou Perl, mas por outro lado tem um custo na performance por causa dos diversos casts em tempo de execução. Fazer o que, né? Não se pode ter tudo ao mesmo tempo.

Apesar disso, GTK _é_ mais leve ( em termos de memória ) e tem startup bem mais rápido que Qt. Mas ainda duvido que o resultado a que ele se refere seja tão ruim assim...

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

Acho que ele estava se referi: Acho que ele estava se referindo a GTK puro, mesmo.

E eu tenho certeza ;) só que acho que ele cometeu um erro técnico, e estou esclarecendo - ou pelo menos tentando.

Não tive condições ainda de fazer o tal teste da tabela 1000 X 1000, por isso não vou comentar. Mas acho _possível_ ser mais lento, sim. Não por culpa de um renderizador bitmap ao invés de um vetorial, mas sim porque GTK é bem mais dinâmico e flexível do que Qt.

Hein? Você escolheu as segunda e terceira palavras mais vazias do mundo do software (a primeira é "melhor" :)

Isso é ótimo para se programar em outras linguagens que não C, principalmente linguagens dinamicamente tipadas como Python ou Perl, mas por outro lado tem um custo na performance por causa dos diversos casts em tempo de execução.

Cast em tempo de execução?! Olha, até onde eu saiba, não existe isto em C, o compilador que faz os casts...

Fazer o que, né? Não se pode ter tudo ao mesmo tempo.

Bem, agora tenho de concordar ;)

Apesar disso, GTK _é_ mais leve ( em termos de memória ) e tem startup bem mais rápido que Qt. Mas ainda duvido que o resultado a que ele se refere seja tão ruim assim...

Isto depende muito do compilador, da máquina, das flags de compilação... Generalizar é "meio inválido" :)

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

Olha, convenhamos: tem uma gota de fogo na sua mensagem, mas quem pode resistir a relevar um post com uma lambda form na assinatura? :D

--
Adam Victor Nazareth Brandizzi
Estudante de Ciência da Computação - UnB
Jabber: brandizzi@jabber.org
"Real programmers don't use Pascal; just integer ones can do it."

Ainda bem que trollaram: Nem toda trollagem é improdutiva. Olha só, a trollagem nessa notícia aqui rendeu uma bela discussão técnica.

Força à QT e à GTK. Ainda bem que temos escolha, duplicação de funcionalidade à parte. ;)
--
LinuxFUD, o TIRA-TEIMA dos ataques ao software livre: http://linuxfud.org

"as segunda e terceira palavr: "as segunda e terceira palavras mais vazias do mundo do software"

Não concordo. Acho que dinâmico e flexível expressam de forma bastante razoável as qualidades de linguagens com late-binding como Python, Scheme ou Ruby. E estático e inflexível são bem a cara de C++ ou Pascal.

"Cast em tempo de execução?! Olha, até onde eu saiba, não existe isto em C, o compilador que faz os casts..."

Talvez eu tenha escolhido o termo errado. Mas o fato é que você pode dinamicamente criar e posicionar widgets e na maior parte do tempo eles são tratados como widgets genéricos. A tipagem é em tempo de execução, na chamada de funções específicas para cada classe de widgets. E isso obviamente incorre em alguma penalidade para a performance...

"depende muito do compilador, da máquina, das flags de compilação..."

E do bloat agregado, claro! ;)

Seu sign tmb não é nada mal! :D

BSB, hein? estou por aí...

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

"as segunda e terceira palavr: "as segunda e terceira palavras mais vazias do mundo do software"

Não concordo. Acho que dinâmico e flexível expressam de forma bastante razoável as qualidades de linguagens com late-binding como Python, Scheme ou Ruby. E estático e inflexível são bem a cara de C++ ou Pascal.

Expressam suficientemente bem pra não significarem nada em especial. Eu *concordo* com você, o problema é quem não acha isto de Python, Scheme ou Ruby :) Mas, enfim, isto é off-topic demais até para mim :)

"Cast em tempo de execução?! Olha, até onde eu saiba, não existe isto em C, o compilador que faz os casts..."

Talvez eu tenha escolhido o termo errado. Mas o fato é que você pode dinamicamente criar e posicionar widgets e na maior parte do tempo eles são tratados como widgets genéricos. A tipagem é em tempo de execução, na chamada de funções específicas para cada classe de widgets. E isso obviamente incorre em alguma penalidade para a performance...

Hmmm... Eu realmente duvido: com todas aquelas macros de casting, eu realmente duvido que, em tempo de compilação, o código não saiba que tipo é qual...

"depende muito do compilador, da máquina, das flags de compilação..."

E do bloat agregado, claro! ;)

Tsc.

Seu sign tmb não é nada mal! :D

BSB, hein? estou por aí...

Oh, obrigado. O chato é que quase ninguém o compreende em toda a sua magnitude. Tem de ter lido muito Jargon File (ou Datamotion :D) para entender a "diqualé" deste "Real programmers don't use Pascal" ;)

--
Adam Victor Nazareth Brandizzi
Estudante de Ciência da Computação - UnB
Jabber: brandizzi@jabber.org
"Real programmers don't use Pascal; just integer ones can do it."

que?: "quem não acha isto de Python, Scheme ou Ruby"

Quem não acha isso ou não conhece ou não bate bem. Pois são tudo menos estáticas e inflexíveis.

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

Clearlooks ainda é muito cinzento: O Clearlooks ainda é muito cinzento, prefiro o nuvola.Temas cinzentos são feios desde que o mundo é mundo, as pessoas gostam de azul, branco são as comibnações que agradam.

O conceito usual de framework: O conceito usual de framework é o de uma (conjunto de) biblioteca mais completa, cobrindo vários componentes, como o gráfico (GUI), redes (sockets, estrutura cliente/servidor), acesso a base de dados, entre outros. Basicamente, usando-se um framework, a aplicação do usuário "encaixa-se" ali, se ajustando àquela estrutura. Diferentemente, em uma biblioteca (como a gráfica), a aplicação do usuário "faz uso" dos componentes da biblioteca, no caso os widgets (na programação OO geralmente vêm na forma de classes).

GUI Toolkit é quase sinônimo de biblioteca gráfica, porque diz respeito somente aos recursos gráficos. Portanto, o Qt não é exatamente um GUI Toolkit, pois é difuso e agrega mais do que isso --embora ainda seja um toolkit no sentido literal de "kit de ferramentas".

--
FLTK fltk.org (Fast Light C++ GUI Toolkit)

Conceito desconhecido: O conceito usual de framework é o de uma (conjunto de) biblioteca mais completa, cobrindo vários componentes, como o gráfico (GUI), redes (sockets, estrutura cliente/servidor), acesso a base de dados, entre outros. Basicamente, usando-se um framework, a aplicação do usuário "encaixa-se" ali, se ajustando àquela estrutura. Diferentemente, em uma biblioteca (como a gráfica), a aplicação do usuário "faz uso" dos componentes da biblioteca, no caso os widgets (na programação OO geralmente vêm na forma de classes).

Não é este o conceito que conheço, embora muito próximo. Segundo pelo menos von Staa (no livro "Programação Modular") framework é um conjunto de ferramentas e bibliotecas utilizados no desenvolvimento de software que ditam a estrutura do programa que o utilizará. Parecem até definições sinônimas, mas é possível que um framework dite a estrutura de uma aplicação sem conceder e.g. o sistema de permanência utilizado, do mesmo modo que podemos ter um conjunto de bibliotecas que podem ser utilizados sem ditar a estrutura da aplicação. Por outro lado, a definição da Wikipedia é mais próxima da sua, embora ainda não traga o mesmo nível de implicação que você vê.

De qualquer forma, também vejo Qt como um framework. GTK+ poderia ser também um (já que implica pontos importantes da arquitetura de um programa), mas esta já é uma definição mais polêmica - e, EMHO, esta é uma polêmica desnecessária. De qualquer forma, pelo caráter mais "uníxico" de GTK+, é natural que ela não suporte tudo que Qt suporta: ela prefere delegar certas missões para outras bibliotecas, como libxml2 (muito boa!), libgdbm, libbonobo, ORBit... Eu diria que o GNOME, este sim, seria um framework no sentido em que estão falando. Por outro lado, Qt parece ter uma influência bem mais pesada do padrão Windows de desenvolvimento, oferecendo tudo de uma vez só. Aproximando grosseiramente: Qt ~ GTK+ + libxml2 + liborbit...

No fundo, isto não implica que este ou aquele é melhor (ou pelo menos é isto que eu acho). São modelos diferentes, cada um com seu valor.

GUI Toolkit é quase sinônimo de biblioteca gráfica, porque diz respeito somente aos recursos gráficos. Portanto, o Qt não é exatamente um GUI Toolkit, pois é difuso e agrega mais do que isso --embora ainda seja um toolkit no sentido literal de "kit de ferramentas".

Depende muito da definição, mas... bem, eu pessoalmente gostei muito desta explicação :)

--
Adam Victor Nazareth Brandizzi
Estudante de Ciência da Computação - UnB
Jabber: brandizzi@jabber.org
"Real programmers don't use Pascal; just integer ones can do it."

Qt4 e GCC-4.0: Alguém sabe se o Qt4 compila sob o GCC-4.0? Eu sei que o KDE não compilava (pelo menos não totalmente), mas estou curioso quanto ao Qt, especialmente o Qt4, que foi lançado após o GCC-4.0.

--
FLTK fltk.org (Fast Light C++ GUI Toolkit)

Não adianta: Não adianta mudar o tema. Ele continua desajeitado e horroroso. Muita coisa teria que ser refeita para o GTK ficar bom.

Olha, eu estou assumindo que: Olha, eu estou assumindo que você esperimentou cada tema. Pelo menos no meu XFce, com o SphereCrystal, ficou supimpa, com uma fascinante aparência que lembrou bem (mas não copiou) a aparência do MacOS X :)

Ademais, falta muito para o GTK+ ficar bom *para você*. Para mim, não falta quase nada ;)

--
Adam Victor Nazareth Brandizzi
Estudante de Ciência da Computação - UnB
Jabber: brandizzi@jabber.org
"Real programmers don't use Pascal; just integer ones can do it."

No meu debian unstable bagun: No meu debian unstable bagunçado funcionou bem e tenho um p4 tb! Tenho 400 e pouco de RAM.

[]s!

Vinícius Medina
Usuário Linux 383765
É usuário de Linux? Mostre a sua cara!

Isso :) : Isso :)

Na verdade em GTK acredito eu que mal dá pra fazer tal tabela ;), estoura a memória facinho se colocar algo dentro, em QT tu defines pros elementos da tabela se criarem e se apagarem "por demanda" caso necessário, se tem como fazer em GTK não está documentado devidamente.

E olha, o resultado é ruim sim, principalmente em GTK+2, atualmente não posso mais notar, mas antes pra mim era extremamente incômodo, eu não conseguia com os drivers da nvidia mais antigos(44 alguma coisa) pegar aceleração 2D no X e GTK ficava praticamente inutilizável enquanto outras bibliotecas de widgets ficavam satisfatórias, nessa época eu costumava usar o driver aberto pra nvidias(que tinha um desempenho 2D bem melhor) pra poder usar apps GTK(que eram e continuam sendo os que eu mais uso) e voltava pro oficial pra jogar Enemy Territory e emuladores :)

Não sou muito fan de OO mas acho que pra interface gráfica é bem mais agradável programar QT com C++ do que GTK com C, GTK com outras linguagens ainda não tive a oportunidade de programar algo :P

Why use Qt?: Ao invés de partimos para discussões agitadas, talvez fosse interessante ouvir dos próprios criadores o que eles tem a dizer:

(Trecho obtido aqui.)

Why use Qt instead of any other toolkit?
Java: Given the nature of Java, it can't run natively on any given platform. There are speed and memory issues associated with Java that Qt does not have.

MFC: Two main advantages. Qt is cross-platform, and, given our customers/users feedback, much more intuitive and easy to code with.

Gtk: Although Gtk is on Windows as well as X, Qt has a far better cross platform implementation. Qt is written in C++, instead of C, has a company standing behind it, and needs much less code to write the same app.


No entanto não encontrei nada similar no FAQ do GTK.

Alguém?

--
Marcelo de Souza
http://www.marcelosouza.eti.br

Então nos diga o quê: Luc, então só pra demonstrar pra gente que você não está trollando, pode dizer exatamente o quê? Ou pelo menos alguns exemplos.

Se você acha o KDE bonito, seria ideal então você comparar a aparência dele pra dizer o que fica pior no GTK+. Se for alguma coisa relativa às molduras de tela ou aos controles, acho que você vai ficar sem argumentos, pois existe uma equivalência enorme entre KDE e Gnome nisso e há até temas portados de um para o outro.
--
LinuxFUD, o TIRA-TEIMA dos ataques ao software livre: http://linuxfud.org

alguém: "Qt is written in C++, instead of C,"

e daí?

"has a company standing behind it,"

e daí? ah, claro! é mais profissional, né? o sistema operacional mais bugado e medíocre que existe também tem uma companhia por trás...

"and needs much less code to write the same app."

Use Python ou Perl. Vai usar ainda menos...

"No entanto não encontrei nada similar no FAQ do GTK. "

É que os desenvolvedores "não profissionais" por trás do GTK preferem gastar o pouco tempo livre que têm para o projeto em desenvolvimento ao invés de marketing.

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

Companhia: "has a company standing behind it,"

e daí? ah, claro! é mais profissional, né? o sistema operacional mais bugado e medíocre que existe também tem uma companhia por trás...

De qualquer jeito é importante que eles citem isso, pois pelo menos para algumas pessoas, isso é importante (no quesito suporte, provavelmente).

Poderíamos dizer o mesmo de citar a característica "é livre": e daí? Para algumas pessoas isso não faz a mínima diferença. Mas é vantagem pra outras.

Um caso mais complicado seria citar uma característica que para algumas pessoas fosse vantagem e para outras desvantagem... =)
--
LinuxFUD, o TIRA-TEIMA dos ataques ao software livre: http://linuxfud.org

re:: "(no quesito suporte, provavelmente)"

ou no quesito não-sei-fazer-nada-sozinho-e-preciso-de-uma-babá...

" a característica 'é livre': e daí? Para algumas pessoas isso não faz a mínima diferença."

Faz, embora não percebam ou reconheçam. Só de estarem usando um produto robusto, livre e gratuito já faz pelo menos uma diferença no bolso.

"uma característica que para algumas pessoas fosse vantagem e para outras desvantagem..."

essa é fácil! Usar Windows, por exemplo: é muito vantajoso e lucrativo para o grande monopólio e seus asseclas, e custoso e sacrificante para seus milhões de usuários depender do mesmo...

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

Marketing não importa pra você?: É que os desenvolvedores "não profissionais" por trás do GTK preferem gastar o pouco tempo livre que têm para o projeto em desenvolvimento ao invés de marketing.

O argumento de que GTK possui desenvolvedores muito ocupados não é muito válido, pois centenas de outros projetos possuem programadores tão ocupados quanto, e sem uma empresa por trás, e mesmo assim destinam parte do seu tempo a certas questões importantíssimas, como marketing.

Isso mesmo: marketing. Quem foi que disse que open source não precisa disso?

Adianta alguma coisa, por exemplo, eu ficar o dia inteiro em casa programando e não fazer nem ao menos uma paginazinha decente na Internet para o meu projeto?

Por quê vocês acham que certas empresas monopolizam o mercado hoje? Única e exclusivamente por mérito? Não. Isso se chama marketing. E marketing pode ser mais barato do que se imagina, ainda mais para empresas grandes. Vejam o exemplo mais visível do mercado, vocês acham que eles querem o fim da pirataria do produto deles? Não, pois pirataria acaba ajudando a eles!

Voltando ao ponto inicial, creio que o que foi dito e o que ocorre é uma falta de visão. Este é um problema sério (infelizmente) no mundo open source. Se eu desenvolvo um software, tenho um objetivo: que ele seja usado, e usado pelo maior número de pessoas possível, que de alguma forma ficaram sabendo do produto. E como se consegue isso? Com marketing, que pode ser feito de diversas formas, até mesmo com uma boa documentação bem escrita.

Antes que pensem, não sou da área de marketing. Sou da área de TI, e creio que o mundo open source poderia estar bem melhor com mais divulgação, pois mérito já sabemos que existe. O problema é que os outros não sabem disso... ;-)

Por fim, vou repetir a pergunta do post anterior:

... não encontrei nada similar no FAQ do GTK. Alguém? (Ou seja, alguém poderia citar algo similar sobre GTK em algum lugar?)

--
Marcelo de Souza
www.marcelosouza.eti.br