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.