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 do nosso planejamento para o Natty + 1, precisaremos encontrar algum espaço no CD para as bibliotecas do 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 valores-chave em nossa experiência do usuário. Nós nos importamos que as aplicações que escolhemos sejam harmoniosas entre si e com o sistema como um todo. Historicamente, isso significa que damos uma preferência muito strong a aplicativos escritos usando o Gtk, porque uma certa quantidade de harmonia vem, por padrão, do uso do mesmo kit de ferramentas do desenvolvedor. Dito isto, com o OpenOffice e o Firefox tendo estado lá 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 isso. Devemos avaliar os aplicativos com base em quão bem eles atendem ao requisito, não os prejudicar 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 sua classe?
- integra-se às configurações e preferências do sistema?
- ele se integra a outros aplicativos?
- é acessível a pessoas que não podem usar mouse ou teclado?
- parece e é consistente com o resto do sistema?
É claro que a escolha de 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 best-in-class escritos com o Qt, é um kit de ferramentas muito capaz.
As configurações do sistema e as prefs, no entanto, têm sido uma causa de atrito entre o Qt e o Gtk. A integração com as configurações e preferências do sistema é fundamental para o sentido de uma aplicação “pertencente” ao sistema. Ela 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. Isso tem sido tradicionalmente um problema com os aplicativos Qt / KDE no Ubuntu, porque todos os aplicativos Gtk usam um repositório de preferências gerenciável centralmente, e os aplicativos do KDE fazem as coisas de maneira diferente.
Para resolver isso, a Canonical está conduzindo 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 de todo o resto do Ubuntu. Fizemos contrato com Ryan Lortie, que obviamente conhece muito bem o dconf, e ele trabalhará com algumas pessoas da Canonical que têm usado o Qt para o trabalho de desenvolvimento personalizado para os clientes. Temos certeza de que o resultado será natural para os desenvolvedores do Qt e uma expressão completa da semântica e do estilo do dconf.
A equipe do Qt tem trabalhado muito bem na ampla comunidade do Ubuntu - temos uma ótima representação Qt na UDS a cada seis meses, a equipe do Kubuntu tem profunda experiência e interesse em embalagem e manutenção do Qt, há muita troca técnica entre Qt upstream e várias partes da comunidade Ubuntu, incluindo a Canonical. Por exemplo, o pessoal da Qt está trabalhando para integrar o uTouch.
Eu faria uma distinção entre "Qt" e "KDE" nos lugares óbvios. Um aplicativo do KDE não sabe nada sobre a configuração do sistema dconf e, como resultado, não pode se integrar facilmente ao desktop do Ubuntu. Portanto, não proporemos o Amarok para substituir o Banshee em breve! Mas eu acho que é totalmente plausível que o dconf, uma vez que tenha ótimas ligações Qt, seja considerado pela comunidade KDE. Há pessoas melhores para conduzir essa conversa, se quiserem, por isso não vou aprofundar a ideia aqui. No entanto, se um aplicativo do KDE aprender a falar com o dconf além dos mecanismos padrão do KDE, que devem ser diretos, 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 permanecem valores compartilhados com o GNOME, e uma ótima base para colaboração com os desenvolvedores e membros do projeto do GNOME. Talvez o próprio GNOME abraça o Qt, talvez não, mas se isso acontecer, nossa disposição de abrir caminho será uma contribuição na liderança. É muito mais fácil criar um ecossistema vibrante se você aceitar uma certa divergência do modo canônico, por assim dizer. Nosso trabalho em design é centrado no GNOME, com configurações e preferências sendo o foco atual à medida que nos movemos para o GNOME 3.0 e gtk3.
É claro que essa é uma oportunidade perfeita para aqueles que zombam 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 o trabalho duro daqueles desenvolvedores de software livre importarem , 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 os bons amigos da Trolltech, agora Nokia, que fizeram da Qt um ótimo kit de ferramentas - obrigado. Para desenvolvedores que desejam usá-lo e fazer parte da experiência do Ubuntu - seja bem-vindo.