Tanta coisa foi escrita que estou meio confuso, mas se não me engano a Canonical está construindo a próxima geração do Unity para dispositivos móveis com Qt, e em um futuro próximo o desktop também será migrado para qt.
Eu só queria saber as razões técnicas e/ou políticas que levaram a esta decisão e quais consequências isso poderia significar para os aplicativos de desktop Ubuntu existentes atualmente.
Responder1
Você pode encontrar a resposta na lista de discussão e emBlog de Mark Shuttleworth. Esta postagem do blog provavelmente responde melhor:
Como parte do nosso planejamento para o Natty+1, precisaremos encontrar algum espaço no CD para bibliotecas Qt e avaliaremos os aplicativos desenvolvidos com Qt para inclusão no CD e instalação padrão do Ubuntu.
Facilidade de uso e integração eficaz são valores fundamentais em nossa experiência de usuário. Nos preocupamos que os aplicativos que escolhemos sejam harmoniosos entre si e com o sistema como um todo. Historicamente, isso significa que demos uma preferência muito forte a aplicações escritas usando Gtk, porque uma certa harmonia vem por padrão do uso do mesmo kit de ferramentas de desenvolvedor. Dito isto, com o OpenOffice e o Firefox presentes desde o início, o Gtk claramente não é um requisito absoluto. O que estou argumentando agora é que são os valores que são importantes e que o kit de ferramentas é apenas um meio para atingir esse fim. Devemos avaliar as aplicações com base na forma como cumprem os requisitos e não prejudicá-las com base nas escolhas técnicas feitas pelo criador.
Ao avaliar um aplicativo para instalação padrão do Ubuntu, devemos perguntar:
- é software livre?
- é o melhor da categoria?
- ele se integra às configurações e preferências do sistema?
- ele se integra a outros aplicativos?
- é acessível para pessoas que não podem usar mouse ou teclado?
- ele parece consistente com o resto do sistema?
É claro que a escolha do Qt pelo desenvolvedor não tem influência nos dois primeiros. O próprio Qt está disponível sob a GPL há muito tempo e, mais recentemente, tornou-se disponível sob a LGPL. E há muitos softwares de primeira linha escritos com Qt, é um kit de ferramentas muito capaz.
As configurações e preferências do sistema, entretanto, têm sido uma causa de atrito entre Qt e Gtk. A integração com as configurações e preferências do sistema é crítica para a sensação de “pertencimento” de um aplicativo ao sistema. Afeta a capacidade de gerenciar esse aplicativo usando as mesmas ferramentas usadas para gerenciar todos os outros aplicativos e os tipos de experiência de configurações e preferências que os usuários podem ter com o aplicativo. Tradicionalmente, isso tem sido um problema com aplicativos Qt/KDE no Ubuntu, porque todos os aplicativos Gtk usam um armazenamento de preferências gerenciável centralmente e os aplicativos KDE fazem as coisas de maneira diferente.
Para resolver isso, a Canonical está conduzindo o desenvolvimento de ligações dconf para Qt, para que seja possível escrever um aplicativo Qt que use a mesma estrutura de configurações de todo o resto no Ubuntu. Contratamos Ryan Lortie, que obviamente conhece muito bem o dconf, e ele trabalhará com algumas pessoas da Canonical que usam o Qt para trabalhos de desenvolvimento customizados para clientes. Estamos confiantes de que o resultado será natural para os desenvolvedores Qt e uma expressão completa da semântica e do estilo do dconf.
A equipe do Qt trabalha bem há muito tempo na comunidade mais ampla do Ubuntu - temos uma grande representação do Qt na UDS a cada seis meses, a equipe do Kubuntu tem profunda experiência e interesse no empacotamento e manutenção do Qt, há muitas boas trocas técnicas entre o Qt upstream e vários partes da comunidade Ubuntu, incluindo Canonical. Por exemplo, o pessoal do Qt está trabalhando para integrar o uTouch.
Eu faria uma distinção entre “Qt” e “KDE” nos lugares óbvios. Um aplicativo KDE não sabe nada sobre a configuração do sistema dconf e, como resultado, não pode ser facilmente integrado ao desktop Ubuntu. Portanto, não vamos propor o Amarok para substituir o Banshee tão cedo! Mas acho totalmente plausível que o dconf, uma vez que possui ótimas ligações ao Qt, seja considerado pela comunidade KDE. Existem pessoas melhores para conduzir essa conversa, se quiserem, então não vou aprofundar a ideia aqui. No entanto, se um aplicativo do KDE aprender a falar do dconf além dos mecanismos padrão do KDE, o que deve ser simples, ele seria um candidato para a instalação padrão do Ubuntu.
A decisão de estar aberto ao Qt não é de forma alguma uma crítica ao GNOME. É uma celebração da diversidade e complexidade do software livre. Esses valores de facilidade de uso e integração continuam sendo valores compartilhados com o GNOME e uma excelente base para colaboração com desenvolvedores GNOME e membros do projeto. Talvez o próprio GNOME adote o Qt, talvez não, mas se o fizer, então a nossa vontade de abrir esse caminho seria uma contribuição na liderança. É muito mais fácil criar um ecossistema vibrante se você aceitar uma certa divergência da forma canônica, por assim dizer. Nosso trabalho em design está centrado no GNOME, com configurações e preferências sendo o foco atual à medida que avançamos para o GNOME 3.0 e gtk3.
Claro, esta é uma oportunidade perfeita para aqueles que zombam desse relacionamento, mas na minha opinião o que mais importa é o relacionamento sólido que temos com pessoas que realmente escrevem aplicativos sob a bandeira do GNOME. Queremos ser a melhor maneira de facilitar o trabalho árduo dos desenvolvedores de software livrematéria, com isso queremos dizer a melhor maneira de garantir que isso faça uma diferença real em milhões de vidas todos os dias e a melhor maneira de conectá-los aos seus usuários.
Ao pessoal da Trolltech, agora Nokia, que fez do Qt um ótimo kit de ferramentas – obrigado. Aos desenvolvedores que desejam utilizá-lo e fazer parte da experiência Ubuntu – bem-vindos.
Responder2
GTK + não suporta independência de resolução. Dispositivos móveis modernos têm densidades de pixels ultra-altas. Se você executar um aplicativo GTK+ em uma tela móvel, todos os elementos da interface do usuário seriam tão pequenos que seriam inutilizáveis.
Isto tem sidoum bug aberto no GTK+desde 2008 até ser fechado em 2014 com o comentário "agora temos suporte à escala de alta dpi - não é exatamente a mesma coisa, mas perto o suficiente para tornar esse bug obsoleto".
Quando o GTK+3 foi lançado, o projeto teve a oportunidade perfeita para adicionar independência de resolução, porque eles estavam quebrando a compatibilidade de qualquer maneira. Eles optaram por não fazê-lo e agora é tarde demais para eles.
NoRoteiro GTK +, a independência de resolução está planejada para o lançamento após o 4.0, então eles lançarão o 4.0 e o lançamento principal depois disso o terá. Se eles seguirem esse plano, até mesmo o GNU/Linux para desktop terá que abandonar o GTK+ porque monitores de desktop e monitores de laptop com alto DPI já estão disponíveis e estão prestes a se tornar o novo normal.
Responder3
CTO do UbuntuBlog de Matt Zimmermantambém é informativo:
É com esse espírito que tenho pensado recentemente no Qt. Queremos tornar o desenvolvimento de aplicativos para Ubuntu rápido, fácil e fácil, e Qt é uma opção que vale a pena explorar para desenvolvedores de aplicativos. Ao pensar sobre isso, percebi que há muitos pontos em comum entre os pontos fortes do Qt e algumas das novas direções do Ubuntu:
- Qt tem uma longa história de uso emARM, bem como x86, em virtude de ser popular em dispositivos embarcados. Os produtos de consumo têm sido desenvolvidos usando Qt em ARM há mais de 10 anos. Temos disponibilizado produtos Ubuntu para ARM há quase dois anos, e a versão 10.10 suporta mais placas ARM do que nunca, incluindo placas de referência da Freescale, Marvell e TI. Qt está adicionando otimizações ARMv7 para beneficiar os chips ARM mais recentes. Fazemos isso para oferecer aos OEMs uma escolha de hardware, sem sacrificar a escolha de software. O Qt preserva essa mesma escolha para desenvolvedores de aplicativos.
- Qt é ummultiplataformaestrutura de aplicativos, com portas oficiais para Windows, MacOS e muito mais, e portas de comunidade experimentais para Android, iPhone e WebOS. O forte suporte multiplataforma foi um dos princípios originais do Qt, e isso fica evidente na maturidade das portas oficiais. Com o Ubuntu Light sendo instalado em computadores com Windows e o Ubuntu One chegando ao Android e ao iPhone, precisamos de interoperabilidade com outras plataformas. Há também uma grande população de desenvolvedores que já sabem como atingir o Windows, que também podem alcançar usuários do Ubuntu escolhendo o Qt.
- Qt tem um ambiente bastante maduroentrada de toquesistema, que agora tem suporte para multitoque e gestos (incluindo QML), embora só esteja completo no Windows 7 e Mac OS X 10.6. Enquanto isso, a Canonical tem trabalhado com a comunidade para desenvolver uma estrutura multitoque de baixo nível para Linux e X11, para benefício do Qt e de outros kits de ferramentas. Esses esforços acabarão por se encontrar no meio.
No geral, acho que o Qt tem muito a oferecer às pessoas que desejam desenvolver aplicativos para (e no) Ubuntu, principalmente agora. Ele já alimenta aplicativos populares de plataforma cruzada como o VLC, sem mencionar toda a distribuição do Kubuntu. Eu perdi quando isso aconteceu no ano passado, mas o Qt agora está disponível na LGPL 2.1 ou na GPL 3.0, o que deve torná-lo adequado para praticamente qualquer aplicativo Ubuntu. Possui forte apoio comercial, bem como uma grande comunidade de desenvolvedores. Nenhuma solução única atenderá a todas as necessidades dos desenvolvedores, é claro, e o Ubuntu suporta vários kits de ferramentas e estruturas por esse motivo, mas o Qt parece ser uma ótima ferramenta para ter em nossa caixa de ferramentas para o futuro.
UmArtigo da Ars Technicadiscutir esta postagem do blog fornece alguns insights:
Qt pode trazer desenvolvedores terceirizados para Linux
Embora o Gtk+ ainda tenha valor e haja uma série de razões para continuar a usá-lo para construir software Linux nativo, o Qt é agora a escolha óbvia para ISVs que têm como alvo múltiplas plataformas. O Qt torna excepcionalmente fácil a adaptação à aparência nativa da plataforma subjacente ou a construção de uma interface de usuário totalmente personalizada que seja ideal para um dispositivo ou formato de destino.
À medida que a Nokia e a Intel levam o MeeGo para uma ampla gama de dispositivos, isso atrairá alguns dos principais fornecedores de software comercial. Seria relativamente fácil para essas empresas de software trazer seus aplicativos móveis Qt para o desktop Linux usando o mesmo código que usam no MeeGo. O Qt foi projetado especificamente para tornar isso fácil. Isso seria uma grande vitória para o Linux para desktop porque traria aplicativos de terceiros que de outra forma não estariam disponíveis.
Vale a pena notar que alguns fornecedores proeminentes de software móvel já estão adotando ansiosamente o Qt devido ao suporte da Nokia ao kit de ferramentas. A empresa de streaming de vídeo móvel Qik, por exemplo, está trabalhando em uma versão experimental baseada em Qt de seu popular aplicativo com o objetivo de trazê-lo para o MeeGo.
O autor do artigo é o criador do aplicativo Gwibber IM, portanto, ele tem alguma experiência no desenvolvimento de GUIs para Linux.
Responder4
Minha opinião sobre as razões técnicas/pragmáticas: a Nokia comprou a Trolltech e investiu muito na QT. É leve e tem anos de otimização para plataforma móvel. Independentemente da sua opinião atual sobre a Nokia, o N900 estava anos à frente de seu tempo... e era baseado em Debian/QT... mas caro. No entanto, não tenho conhecimento real das decisões.