Por que a Canonical está escolhendo o QT em vez do GTK para a próxima geração do Unity?

Tanta coisa foi escrita que estou meio confusa, 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 o qt.

Eu só queria saber as razões técnicas e / ou políticas que determinaram essa decisão e quais consequências isso poderia ter para os aplicativos de desktop Ubuntu atualmente existentes.

Você pode encontrar a resposta na lista de discussão e no blog de Mark Shuttleworth . Esta postagem do blog provavelmente responde melhor:

Como parte de nosso planejamento para o Natty + 1, precisaremos encontrar algum espaço no CD para bibliotecas Qt e avaliaremos os aplicativos desenvolvidos com o Qt para inclusão no CD e instalação padrão do Ubuntu.

Facilidade de uso e integração efetiva são os principais valores de nossa experiência do usuário. Preocupamo-nos que as aplicações que escolhemos sejam harmoniosas entre si e com o sistema como um todo. Historicamente, isso significa que demos uma forte preferência a aplicativos escritos usando o Gtk, porque, por padrão, uma certa harmonia vem do uso do mesmo kit de ferramentas do 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 o kit de ferramentas é apenas um meio para esse fim. Devemos avaliar os aplicativos com base em quão bem eles atendem ao requisito, sem prejudicá-los com base nas escolhas técnicas feitas pelo desenvolvedor.

Ao avaliar um aplicativo para a instalação padrão do Ubuntu, devemos perguntar:

• é software livre?
• é o melhor da classe?
• 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?
• parece consistente com o resto do sistema?

Obviamente, a escolha do Qt pelo desenvolvedor não influencia os 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 o Qt, é um kit de ferramentas muito capaz.

As configurações do sistema e prefs, no entanto, têm sido uma causa de atrito entre Qt e Gtk. A integração com as configurações e preferências do sistema é fundamental para o sentido de um aplicativo "pertencer" ao sistema. Isso 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ção e preferência que os usuários podem ter com o aplicativo. Tradicionalmente, esse é um problema com os aplicativos Qt / KDE no Ubuntu, porque todos os aplicativos Gtk usam uma loja de preferências gerenciável centralmente, e os aplicativos KDE fazem as coisas de maneira diferente.

Para resolver isso, a Canonical está impulsionando o desenvolvimento de ligações dconf para o Qt, para que seja possível escrever um aplicativo Qt que use a mesma estrutura de configurações que tudo o resto no Ubuntu. Contratamos com Ryan Lortie, que obviamente conhece o dconf muito bem, e ele trabalha com algumas pessoas da Canonical que usam o Qt para trabalhos de desenvolvimento personalizado para clientes. Estamos confiantes de que o resultado será natural para os desenvolvedores de Qt e uma expressão completa da semântica e estilo do dconf.

A equipe do Qt trabalha há muito tempo na comunidade mais ampla do Ubuntu - temos uma excelente representação do Qt na UDS a cada seis meses, a equipe do Kubuntu tem uma profunda experiência e interesse no empacotamento e manutenção do Qt, há muitas trocas técnicas boas 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 não pode se integrar facilmente à área de trabalho do Ubuntu como resultado. Portanto, não vamos propor ao Amarok substituir Banshee tão cedo! Mas acho que é totalmente plausível que o dconf, uma vez que tenha ótimas ligações Qt, seja considerado pela comunidade do KDE. Existem pessoas melhores para liderar essa conversa, se quiserem, então não vou levar a idéia adiante. No entanto, se um aplicativo do KDE aprender a falar sobre o dconf, além dos mecanismos padrão do KDE, que devem ser diretos, seria um candidato à 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 a colaboração com os desenvolvedores e membros do projeto. Talvez o próprio GNOME abraça o Qt, talvez não, mas se o fizer, nossa disposição 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 maneira canônica, por assim dizer. Nosso trabalho em design é centrado no GNOME, com configurações e preferências no foco atual à medida que avançamos para o GNOME 3.0 e o gtk3.

É claro que essa é uma oportunidade perfeita para quem zombaria desse relacionamento, mas, na minha opinião, o que mais importa é o sólido relacionamento que temos com pessoas que realmente escrevem aplicativos sob o banner do GNOME. Queremos ser a melhor maneira de fazer com que o trabalho duro desses desenvolvedores de software livre seja importante , com o que queremos dizer, a melhor maneira de garantir que faça uma diferença real em milhões de vidas todos os dias e a melhor maneira de conectá-los a seus usuários.

Para o pessoal da Trolltech, agora Nokia, que fez do Qt um ótimo kit de ferramentas - obrigado. Para desenvolvedores que desejam usá-lo e fazer parte da experiência do Ubuntu - bem-vindo.

O GTK + não suporta independência de resolução. Os dispositivos móveis modernos têm densidades de pixel ultra altas. Se você executar um aplicativo GTK + em uma tela móvel, todos os elementos da interface do usuário serão tão pequenos que não poderão ser utilizados.

Esse é um bug aberto no GTK + desde 2008, até que foi fechado em 2014 com "nós temos suporte à escala hi-dpi agora - 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 de adicionar independência de resolução, porque eles estavam quebrando a compatibilidade de qualquer maneira. Eles escolheram não fazê-lo, e agora é realmente tarde demais para eles.

No Roteiro GTK + , a independência da resolução está planejada para o lançamento após a versão 4.0, para que eles lançem a versão 4.0 e, em seguida, a versão principal. Se eles se mantiverem nesse plano, mesmo o GNU / Linux para desktop terá que abandonar o GTK + porque os monitores de desktop com alto DPI e os laptop já estão disponíveis e estão prestes a se tornar o novo normal.

Minha opinião sobre os motivos técnicos / pragmáticos: a Nokia comprou a Trolltech e investiu muito no QT. É leve e tem anos de otimização em direção à plataforma móvel. Independentemente de suas opiniões atuais da 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.

O blog do Matt Cimmerman, CTO do Ubuntu, também é informativo:

É nesse espírito que tenho pensado sobre o Qt recentemente. Queremos tornar rápido, fácil e fácil o desenvolvimento de aplicativos para o Ubuntu, e o Qt é uma opção que vale a pena explorar para os desenvolvedores de aplicativos. Ao pensar nisso, percebi que há um pouco de semelhança entre os pontos fortes do Qt e algumas das novas direções no Ubuntu:

• O Qt tem um longo histórico de uso no ARM e no x86 , por ser popular em dispositivos embarcados. Os produtos de consumo foram criados usando o Qt no ARM há mais de 10 anos. Estamos disponibilizando produtos Ubuntu para ARM há quase dois anos, e a 10.10 suporta mais placas ARM do que nunca, incluindo placas de referência da Freescale, Marvell e TI. A Qt está adicionando otimizações do ARMv7 para beneficiar os mais recentes chips ARM. Fazemos isso para oferecer aos OEMs uma opção de hardware, sem sacrificar a escolha do software. O Qt preserva essa mesma opção para desenvolvedores de aplicativos.
• O Qt é uma estrutura de aplicativos multiplataforma , com portas oficiais para Windows, MacOS e mais, e portas experimentais da comunidade para Android, iPhone e WebOS. O forte suporte de plataforma cruzada foi um dos princípios originais do Qt e mostra a maturidade dos portos oficiais. Com o Ubuntu Light sendo instalado em computadores com Windows e o Ubuntu One chegando no Android e no iPhone, precisamos de interoperabilidade com outras plataformas. Há também uma grande população de desenvolvedores que já sabem como direcionar o Windows, que também podem alcançar os usuários do Ubuntu escolhendo Qt.
• O Qt possui um sistema de entrada de toque bastante maduro , que agora oferece suporte a vários toques e gestos (incluindo QML), embora esteja completo apenas no Windows 7 e no Mac OS X 10.6. Enquanto isso, a Canonical vem trabalhando com a comunidade para desenvolver uma estrutura multi-touch de baixo nível para Linux e X11, para o benefício do Qt e outros kits de ferramentas. Esses esforços acabarão se encontrando 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á possui aplicativos populares de plataforma cruzada como o VLC, sem mencionar toda a distribuição do Kubuntu. Eu senti falta disso quando isso aconteceu no ano passado, mas o Qt agora está disponível sob o LGPL 2.1 ou o GPL 3.0, o que deve torná-lo adequado para praticamente qualquer aplicativo Ubuntu. Possui forte apoio comercial, além de uma grande comunidade de desenvolvedores. Nenhuma solução única atenderá às necessidades de todos os 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 caminho a seguir.

Um artigo da Ars Technica discutindo esta postagem do blog fornece algumas informações:

Qt pode trazer desenvolvedores de terceiros para Linux

Embora o Gtk + ainda tenha valor e haja várias razões para continuar usando-o na criação de software Linux nativo, o Qt agora é a escolha óbvia para os ISVs que têm como alvo várias plataformas. O Qt facilita excepcionalmente a conformidade com a aparência nativa da plataforma subjacente ou a construção de uma interface com o usuário totalmente personalizada, ideal para um dispositivo ou fator de forma de destino.

Como a Nokia e a Intel trazem o MeeGo para uma ampla gama de dispositivos, atrairá alguns dos principais fornecedores de software comercial. Seria relativamente fácil para essas empresas de software trazer seus aplicativos móveis de Qt para a área de trabalho do Linux usando o mesmo código que eles usam no MeeGo. O Qt foi projetado especificamente para facilitar isso. Isso seria uma grande vitória para o Linux para desktop, pois traria aplicativos de terceiros que, de outra forma, não estariam disponíveis.

Vale a pena notar que alguns importantes fornecedores 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 porta experimental baseada em Qt de seu aplicativo popular, com o objetivo de trazê-lo ao MeeGo.

O autor do artigo é o criador do aplicativo Gwibber IM, portanto ele tem alguma experiência no desenvolvimento de GUIs para Linux.