Versão Linux do Google Chrome agendada para junho, com Gtk
O Google divulgou sua intenção de lançar as versões para Mac e Linux de seu navegador Chrome em junho, segundo informado pelo Newsforge.
E a versão para Linux deve usar o Gtk, colocando em prática a decisão de desenvolver a interface para usuário separadamente em cada uma das plataformas que o navegador irá suportar. (via osnews.com)
Saiba mais (osnews.com).
Veja também o texto enviado pelo ASF (antoniosfonsecaΘyahoo·com) – referência (antoniofonseca.wordpress.com).
• Publicado por Augusto Campos em
2009-02-16
@brlinuxblog
Feed RSS
“E a versão para Linux deve usar o Gtk, colocando em prática a decisão de desenvolver a interface para usuário separadamente em cada uma das plataformas que o navegador irá suportar.”
Resumindo, os usuários linux vão ficar com um subproduto do desenvolvimento que continuará a ser windows-centric.
Os diálogos do GTK+ são feios. Com o Qt 4.x agora sendo LGPL, não vejo porque a Google não optou por usá-lo e assim fazer uma versão com o código da GUI comum a todas as plataformas. Não sei como não optaram por usar a libwine, como já fizeram em outros de seus produtos.
Felizmente já existem pelo menos 2 projetos de navegadores usando o mesmo engine webkit do Chrome e GTK+ ou Qt 4 e sem ficar coletando dados do usuário
http://code.google.com/p/arora/
http://liquidat.wordpress.com/2008/05/27/arora-a-webkit-browser-in-qt/
http://www.twotoasts.de/index.php?/pages/midori_summary.html
Para ver o porque, os links dados a partir da referência do OSNews são um bom começo. Cabe mencionar que a mesma decisão de desenvolver a interface gráfica independentemente também está valendo para o Mac OS X.
E me parece que este comportamento, oposto ao anterior (de usar a libwine) me parece uma grande evolução quanto à política anterior, de desenvolver pensando exclusivamente no Windows e aí se limitar a usar o mínimo de camadas de compatibilidade possíveis para rodar em outras plataformas também.
“Com o Qt 4.x agora sendo LGPL, não vejo porque a Google não optou por usá-lo e assim fazer uma versão com o código da GUI comum a todas as plataformas”
O Qt 4.x ainda é muito lento no Windows. Bom, não sei se o Gtk é melhor. Aliás, não sei se esse foi o critério.
Obrigado, Augusto. Agora eu li a discussão em
http://groups.google.com/group/chromium-dev/msg/f3507e2ded99b354?pli=1
e a explicação está no que disse o Ben Goodger.
O Chrome será triplataforma em vez de multiplataforma: para windows, para macosx e para o linux e o resto dos Unices (GTK+).
Mas ainda assim não explica porque preferiram o GTK+ ao Qt 4.x no build específico para linux, já que para windows e mac a decisão já havia sido a de não usar nenhum toolkit. Na minha opinião, mesmo que sendo usado somente na versão linux ainda valeria a pena.
Creio que o principal motivo seja o de que o Qt agora é da Nokia, concorrente do Google no mercado de sistemas operacionais para celulares. Ela deve ter ficado com medo dessa dependência.
Manoel, e se eles gostam mais de programar em GTK+ do que QT?
O GTK fica feio no KDE e no Windows assim como aplicações KDE ficam horriveis no GNOME. Mas pra quem usa GNOME como eu fica lindo!
Porque o Google deveria escolher qt, só pra agradar os poucos usuários do KDE?
O Google esta mais que certo em usar GTK, tem agradar a maioria.
Só lembrando que na QT se pode usar o estilo QGTKStyle que usa GTK+ para renderizar os widgets de aplicações QT. Eu já uso aqui no Ubuntu e fica simplesmente perfeito e, segundo sei, será o padrão na QT 4.5 quando esta estiver rodando em ambiente gnome. Ou seja, essa de que aplicações Qt ficariam feias no gnome não seria motivo.
Quanto ao fato de programadores do Google gostarem de GTK+, vale lembrar que o Google Earth é feito em QT. Acho que a motivação não tem nada a ver com gosto pessoal de empregados. Acredito mais na hipótese de concorrência com a Nokia, aventada pelo comentarista mais acima.
Será que o google não poderia ajudar o pessoal do GTK no desenvolvimento do gtk+ 3? Ai aproveitaria e desenvolveria o seu browser utilizando esta tecnologia. Seria uma via de mão dupla :-)
O GTK precisa de uma boa modernizada, principalmente em se tratando do visual e “peso”, já que está começando a parecer mais pesado que Qt.
E pessoal, eu estou com muito medo desta nova guerra dos navegadores, pois aqui não está mais em jogo o controle da Internet (na década de 90 a o mundo não dependia da grande rede), mas o controle do Mundo!
O pessoal do google já está deixando a fundação mozilla de lado, o pessoal da Apple está investindo muito no webkit (tanto que é a engine mais compatível com os padrões e ao que parece a mais rápida), o google está com essa de chrome e o resto do povo (konqueror, opera, etc) está comendo pelas bordas. E também tem o ainda dominante Internet Exploder que ainda é ruim pra caramba mas que será o dominante por um bom tempo. Não sei onde este mundo vai parar…
@ziriguidum, o google earth no Linux parece usar wine (ou libwine). Talvez seja Qt no Windows, o que seria bastante estranho já que Qt é bastante usado no Linux :-)
Eu acho que o fato do QT ser da NOKIA, apesar da licenca livre é um dos motivos do Google não querer usar o QT.
Neste ponto concordo com o Manoel. Acho tambem que este navegador do Google vai ter o peso que o Gtalk teve para os softwares de mensagem instantanea ou seja praticamente nada.
Acho que em breve o Firefox vai liderar o segmento.
QT mais leve que GTK? tenchi, tenho que discordar de você neste ponto.
Admito que o QT foi uma revolução em muitos aspectos, tanto visuais como técnicos. Porém, o GTK, continua sendo exemplo de “leveza”. Aí está o XFCE que não me deixa mentir.
Não tinha realizado, mas depois que nosso amigo falou sobre a relação GTK-QT e Nokia-Google, acho que ficou bem claro o motivo da escolha do GTK.
Bem que eles poderiam revolucionar novamente e lançar uma tookit nova para o Chrome que valeria para qualquer plataforma.
Muito mais prático e rápido do que utilizar uma para cada sistema e poderiamos ter uma versão nova do navegador a cada instante em qualquer plataforma.
Agora, deixar como triplataforma, já limita alguns sistemas que não citados no Google e leva a uma demora para cada sistema.
Mas ainda bem que tem o código fonte :)
Google Earth é feito em Qt sim:
http://www.qtsoftware.com/qt-in-use/story/app/google-earth
Não acredito que use wine na versão para linux. Olhando o diretório lib da google earth, encontro várias bibliotecas Qt mas nada de libwine. Se o Google Earth rodasse sobre wine e dado que nele não está presente a libwine, isso significaria que o Google Earth teria como dependência o wine instalado a parte, via repositório da própria distribuição. Como o Google Earth aparentemente não depende de nada, concluo que é uma aplicação nativa, que usa sua própria versão da Qt, em vez daquela empacotada nas distribuições.
Pow…. acho que ninguém aqui seguiu a recomendação de ler a fonte de referência.
Pelo que eu entendi foi o seguinte: No Qt não daria para ter um desenvolvimento mais profundo, haveria limitações. Seria algo como programação de alto e baixo nivel. Se eu estiver errado me corrijam… Eu não sou lá essas coisas em inglês.
Então vai ser somente um “Firefox by Google”?
O Google usou a libwine no Picasa para Linux. No Google Earth eu também acho que não usou – e sei que usou Qt.
O google earth é feito em Qt
http://www.qtsoftware.com/qt-in-use/story/app/google-earth
e portanto a Google até agora já tinha mais experiência com Qt e winelib nas versões de seus softwares para linux.
O GTK+ ainda tem muita cara de Motif, a biblioteca gráfica mais usada nos Unices comerciais antigamente e usada no CDE. Tanto, que o XFce (que usa GTK+) é parecidíssimo no uso e na aparência geral.
Essa “leveza” é muito relativa porque depende muito de que ambiente a pessoa está rodando no momento. Se estiver no KDE a biblioteca do Qt já estará na memória e um aplicativo Qt irá parecer mais rápido. Idem para o Gnome/GTK+ ou XFce/GTK+.
A leveza do GTK acaba na hora em que se abrem 3 programas de peso que fazem uso desse toolkit. Já com QT, o “peso” inicial é levemente maior, mas não aumenta ao se abrirem vários aplicativos.
Adoraria ver o Chrome usando Qt, infelizmente vou continuar usando o Opera, que é o ótimo navegador mas me deixa sem opções no KDE. O Konqueror (do KDE 3.5 ao menos) é pouco compatível com páginas e ele dá umas “engasgadas” de segundos, além de que não se dá muito bem com várias abas usando Flash (o Firefox também não, mas no Konqueror é pior).
“Admito que o QT foi uma revolução em muitos aspectos, tanto visuais como técnicos. Porém, o GTK, continua sendo exemplo de “leveza”. Aí está o XFCE que não me deixa mentir.”
O fato do XFCE ser leve não é prova, pois deve-se em muito ao fato de ter poucos recursos. Creio que se criássemos um ambiente como o XFCE usando Qt o resultado seria o mesmo (ou melhor).
E por outro lado, o KDE parece ser mais leve que o Gnome desde 2006. Veja: http://ktown.kde.org/~seli/memory/desktop_benchmark.html . Não encontrei um teste mais novo tão completo como este, mas este benchmark veio em uma época que todos achavam que o Gnome era mais leve. A versão usada era o KDE 3.5.x e o Gnome era o 2.12. O Gnome passou por melhorias de performance em versões mais atuais, mas não sei dizer se está melhor que o KDE em consumo de memória atualmente, ainda mais com a versão 4.2.
O que não prova nada, pois existe muito software leve escrito sobre o GTK+ e sobre o Qt também. Além do mais, o Qt é bem mais do que somente um arcabouço gráfico.
Provavelmente a escolha do GTK+ deve ter algo a ver com integração à biblioteca gráfica Skia do Android, mas isto é só um palpite…
Por que não fazem com os dois (Qt e GTK+)? Assim o desempenho e compatibilidade seria 100% com o KDE, GNOME e XFCE (que são os 3 mais amigáveis).
O Firefox 3.1 será em Qt e GTK+, correto?
Não fazem com ambos porque escolheram um! E se escolhessem ambos, ou um terceiro, também haveria descontentes, com certeza. E estes, como de hábito, têm a opção de usar outros programas, ou mesmo de fazer sua própria versão a partir do código aberto pelo autor original.
O chato é que como será feito com GTK, aumenta a possibilidade de ter o jeitão do Firefox. Seria legal se o google desse uma “tunada” no GTK para ficar mais distante daquele look-and-feel já manjado.
Não conheço a API do GTK, talvez era seja mais maleável para isto.
E num é que é mesmo. É Qt4… Que coisa, havia instalado a versão 5 num notebook com ubuntu e parecia muito com os programas em wine (como o picasa, também instalado no mesmo note), por isso vi de relance e achei que era libwine tbm, mas instalei agora no meu pc e vi que ficou bonitinho com o tema plastik :-)
Então penso: minha nossa, porque o google não usa Qt para tudo? Qt é multiplataforma, estável, bonito, bem documentado, open source…
Pois é, como já usam Qt, poderiam continuar nele nos outros produtos, diminuindo esforço e facilitando o uso de bibliotecas comuns.
As explicações mais viáveis até agora são alguma limitação do Qt para o que eles precisam, alguma integração do gtk com tecnologia que eles devem usar ou o relacionamento com a Nokia, como imagina o Manoel.
Ainda bem que vai ser em GTK!!!
QT4 fica bem no GNOME mas não como a GTK+.
Viva o GTK que é lindo!!!!!
Viva o GTK+ !!
Deixando várias viúvas
beatas do QT pasmas :-)
O motivo da escolha do Gtk é simples. Os desenvolvedores que estão no projeto do Chrome são mais experientes com Gtk. E eles também justificaram a escolha dizendo que seu principal concorrente (o Firefox) já usa o Gtk.
O Gtk só vai ser usado nos diálogos de preferências e coisas do gênero, para que eles tenham visual “nativo”. A renderização de páginas em si vai usar a mesma engine Skia que é usada no Windows e no Mac. Isso significa que será muito fácil portar o Chrome para Qt ou qualquer outro toolkit que você desejar.
Aliás, tudo isso está no FAQ do Chrome desde cerca de 1 semana depois que ele foi lançado para o Windows, bem antes de sair essa notícia no OSNews.
Não. São outras equipes dentro da Google que usam Qt. A equipe do Chrome não tem praticamente nenhuma experiência com Qt, pelo menos foi isso o que eles escreveram no FAQ do Chrome. Lembre-se que a Google é uma empresa bem grande (que contém várias equipes diferentes dentro).
Então eles não estão usando Qt por um motivo muito simples: seria matar uma formiga com um canhão. O Qt tem um motor de renderização próprio, mas isto a Skia também já tem. Eles só precisam de componentes gráficos. Vale lembrar que tanto a Skia quanto o GTK+ usam Cairo para desenhar os gráficos, gerando menos dependências…
O Qt já superou em desempenho o GTK faz um tempinho, agora superar a “feiura” das caixas de dialogos do GTK é quase que impossivel. E digo isso com qualquer ambiente, KDE ou Gnome.
O Skia não usa Cairo para desenhar os gráficos. Muito pelo contrário, ela substitui o Cairo.
E se usasse Cairo, seria péssimo, pois o Cairo é muito lento comparado com Skia, AGG e outras engines de renderização concorrentes.
P.S.: Pessoal, vou pedir um favor. Por favor, dêem uma olhada no código ou então procurem se informar ao invés de fazer esse tipo de suposição. Já está muito chato a quantidade de informações incorretas que está surgindo e sendo espalhada por aqui.
Substituir o Cairo não faria sentido se o objetivo fosse fazer um aplicativo multiplataforma. Até onde eu sei, a Skia tem backends tanto para Cairo como para GDI. Se você quiser brincar de semântica e discutir quem literalmente “desenha” os gráficos, isso é outra história… :P
Este símbolo do Chrome lembra o Genius.