Por que não há mais aplicativos de desktop escritos com Qt? [fechadas]

Tanto quanto sei e entendi na minha experiência com o Qt, é uma biblioteca muito boa e fácil de aprender. Possui uma API muito bem projetada e é multiplataforma, e esses são apenas dois dos muitos recursos que a tornam atraente. Estou interessado em saber por que mais programadores não usam o Qt. Existe uma deficiência que fale contra isso? Qual recurso torna outras bibliotecas melhores que o Qt? O problema está relacionado ao licenciamento?

Não pretendo realmente que seja uma resposta contundente, mas essas são as razões pelas quais não uso pessoalmente o Qt. Há muitas coisas boas a dizer sobre isso - a saber, que a API funciona na maior parte do tempo e faz a ponte entre plataformas. Mas eu não uso Qt, porque:

1. Em alguns casos, simplesmente não se parece com programas nativos. O design de uma interface do usuário única para todas as plataformas inerentemente não parecerá correto quando movido de máquina para máquina, por vários motivos de estilo visual. Por exemplo, em máquinas Mac, as barras divididas geralmente são relativamente grossas e os botões são pequenos e arredondados com ícones. Nas máquinas Windows, as barras divididas geralmente são estreitas e os botões são mais textuais, com mais desenhos quadrados. Só porque você pode escrever uma interface do usuário para todas as plataformas não significa que você deve fazer para a maioria dos aplicativos.
2. Qt não é uma biblioteca C ++. Requer uma etapa de compilação separada, o que torna o processo de criação muito mais complicado quando comparado com a maioria das outras bibliotecas.
3. Como resultado de (2), IDEs e ferramentas C ++ podem sinalizar expressões Qt como erros, porque eles não entendem as especificidades de Qt. Isso quase força o uso do QtCreator ou de um editor apenas de texto vim.
4. Qt é uma grande quantidade de fontes, que deve estar presente e pré-instalada em qualquer máquina usada antes da compilação. Isso pode tornar a configuração de um ambiente de construção muito mais entediante.
5. Está disponível apenas na LGPL, o que dificulta o uso da implantação binária única quando é necessário liberar sob uma licença mais restritiva ou menos restritiva.
6. Ele produz binários compilados extremamente grandes quando comparados com "aplicativos nativos simples", escritos da mesma forma (exceto os aplicativos escritos para o KDE).

Como as pessoas dizem, cada ferramenta se adapta a cada problema e situação ...

Mas se você é programador em C ++, o Qt é sua estrutura. Sem rival.

Desenvolvemos uma aplicação comercial complexa de imagens médicas, e o Qt permanece.

Não digo que os "contras" que as pessoas dizem sobre isso sejam falsos, mas tenho a sensação de que eles não experimentam o Qt há muito tempo (está melhorando continuamente a cada nova versão ...) E, principalmente todos os problemas que eles comentam não são um problema se você tomar cuidado.

Inconsistência na plataforma da interface do usuário: somente se você usar os widgets da interface do usuário 'como estão', sem personalização ou arte customizada.

Sobrecarga do pré-processador Qt: Somente se você abusar do mecanismo do slot de sinal ou da herança do QObject, quando não houver realmente necessidade.

A propósito, ainda escrevemos aplicativos em C # .NET e fazemos isso há muito tempo. Então, eu acho que tenho uma perspectiva positiva.

Como eu disse, cada ferramenta para cada situação,

mas Qt é sem dúvida uma estrutura consistente e útil.

De todas as coisas que eu não gosto no Qt, o fato de ele não funcionar bem com modelos me incomoda mais. Você não pode fazer isso:

template < typename T >
struct templated_widget : QWidget
{
  Q_OBJECT;

public signals:
  void something_happened(T);
};

Também não funciona bem com o pré-processador. Você não pode fazer isso:

#define CREATE_WIDGET(name,type) \
struct name ## _widget : QWidget \
{ \
  Q_OBJECT; \
\
public signals: \
  void something_happened(type); \
}

Isso, misturado ao fato de que tudo o que responde a um sinal precisa ser um Q_OBJECT, torna o Qt difícil de trabalhar para um programador de C ++. As pessoas acostumadas à programação no estilo Java ou Python provavelmente se saem melhor na verdade.

Na verdade, gastei muito tempo e esforço pesquisando e desenvolvendo uma maneira de recuperar a segurança de tipo e conectar um sinal Qt a qualquer objeto funcionador: http://crazyeddiecpp.blogspot.com/2011/01/quest-for-sane-signals -in-qt-step-1.html

O tipo de coisa que eu quero fazer é o desenvolvimento básico e diário de C ++, quase impossível de ser feito pelo Qt moc ... que por si só é totalmente desnecessário nos dias de hoje, se é que realmente foi.

Francamente, eu estou preso a isso, porque se você quiser fazer testes automatizados de interface do usuário, o Qt é praticamente o único jogo na cidade com exceção do MFC ... que é tão 1980 (é uma droga trabalhar muito nessa merda). Alguns podem dizer WX, mas há problemas ainda mais sérios. O GTKmm teria sido a minha primeira escolha, mas, como tudo é feito pelo proprietário e não faz acessibilidade ... não pode ser conduzido pelo software de teste padrão do setor. O Qt é bastante difícil nesse sentido ( mal funciona quando você modifica o plug-in de acessibilidade).

Um motivo para não usar o Qt é que, se você escrever apenas para uma arquitetura, como o Windows, convém usar C # /. NET (ou Cocoa no Mac), porque eles sempre poderão tirar proveito dos mais recentes sinos - e assobios do sistema operacional.

Se você estiver escrevendo aplicativos de plataforma cruzada, já poderá estar fortemente investido em outra tecnologia, como Java (ou seja, você trabalha em uma "Java Shop"). Sua escolha de tecnologia pode ser ditada pelo ecossistema em que você está desenvolvendo, como APIs específicas de idioma. Nesses tipos de casos, minimizar o número de tecnologias pode ser benéfico.

Uma terceira razão pela qual consigo pensar é que o Qt é baseado em C ++, e C ++ é uma linguagem relativamente difícil / perigosa para se programar. Acho que é uma linguagem para profissionais. Se você precisa ter o melhor desempenho e é capaz de ser meticuloso, o C ++ ainda é provavelmente o melhor jogo da cidade. Na verdade, o Qt melhora muitos problemas de gerenciamento de memória se você configurar as coisas para ficar fora do escopo. Além disso, o próprio Qt faz um bom trabalho isolando o usuário de muitos dos problemas desagradáveis ​​de C ++. Toda linguagem e estrutura tem seus prós e contras. É uma questão muito, muito complicada, que geralmente pode ser resumida pelo ditado frequentemente visto nos clientes: velocidade, qualidade e preço (mas você pode escolher apenas duas).

Embora as regras digam que devo manter o foco em responder à pergunta, quero refutar algumas das questões levantadas por Billy ONeal, que acho que faz um bom trabalho resumindo os motivos mais citados para não usar o Qt:

1. Qt é de fato uma biblioteca C ++ / framework / arquivos de cabeçalho. É aumentadopor um processador de macro (moc) que permite sinais e slots, entre muitas outras coisas. Ele transforma comandos de macro adicionais (como Q_OBJECT) para que as classes tenham introspecção e todos os tipos de outras vantagens que você pode considerar adicionando a funcionalidade Objective-C ao C ++. Se você sabe o suficiente sobre C ++ para se ofender com essa falta de pureza, ou seja, você é um profissional, então 1) não use Q_OBJECT e sua classe ou 2) seja grato por isso, e programe em casos muito limitados onde isso causa um problema. Para as pessoas que dizem "Use o Boost para sinais e slots!" então eu diria que você está trocando um "problema" por outro. O Boost é enorme e tem seus próprios problemas comumente citados, como documentação ruim, API horrenda e horrores de plataforma cruzada (pense em compiladores antigos como o gcc 3.

2. Para suporte ao editor, isso também segue de 1, eu concordo um pouco. Na verdade, o Qt Creator é o IMHO o melhor editor gráfico de C ++, ponto final, mesmo que você não use o material do Qt. Muitos programadores profissionais usam emacs e vim. Além disso, acho que o Eclipse lida com a sintaxe adicional. Portanto, não há problemas com as macros Qt (Q_OBJECT) ou com adições de sinais / slots. Você provavelmente não encontrará essas macros no Visual Studio, porque (eu admito) elas são adições ao C ++. Mas, em geral, o pessoal do C # /. NET não utilizará o Qt de qualquer maneira, devido ao fato de que eles têm grande parte da funcionalidade coberta por suas próprias técnicas proprietárias.

3. Quanto ao tamanho da fonte Qt, desde que seja compilada da noite para o dia, quem se importa? Compilei o Qt 4 no meu Macbook dual core em "menos que da noite para o dia". Eu certamente espero que não seja isso que esteja motivando sua decisão de usar ou não uma tecnologia específica. Se isso for realmente um problema, você poderá fazer o download dos SDKs pré-compilados para Mac, Linux e Windows no site da Qt.

4. O licenciamento está disponível em três opções: 1) Licença proprietária no caso de você desejar modificar o Qt ITSELF e não compartilhar, ou ocultar o fato de que alguém está usando o Qt e não está disposto a atribuir (pode ser muito importante para a marca e a imagem!) 2 ) GPL e 3) LGPL. Sim, há problemas com a vinculação estática (rolando todo o Qt no binário) - mas acho que é mais porque não se pode espiar por dentro e perceber que você está usando o Qt (atribuição!). Tentei comprar uma licença proprietária da Digia e eles me disseram "pelo que você está fazendo, você realmente não precisa". Uau. De uma empresa que está vendendo licenças.

5. O tamanho do binário / pacote é porque você precisa distribuir o material Qt para as pessoas que não o possuem: o Windows já possui? o material do Visual Studio ou você precisa instalar o tempo de execução. O Mac já vem com o enorme cacau e pode ser vinculado dinamicamente. Embora eu não faça muita distribuição, nunca encontrei muito problema em distribuir o arquivo estático de ~ 50 megabytes (que eu posso tornar ainda menor com alguns dos utilitários binários de stripper / compactação como o UPX). Eu simplesmente não me importo o suficiente para fazer isso, mas se a largura de banda fosse um problema, eu adicionaria uma etapa UPX ao meu script de construção.

6. O que define "Aparência e sensação nativas?" Eu acho que "a maioria" concorda que o Mac se aproxima mais da aparência unificada. Mas aqui estou, olhando para o Safari, iTunes, Aperture, Final Cut Pro, Pages, etc. e eles não se parecem em nada, apesar do fato de serem feitos pelo fornecedor do SO. Eu acho que o aspecto "sentir" é mais relevante: estilo do widget, capacidade de resposta, etc. Se você se preocupa com a capacidade de resposta, aqui está um bom motivo para usar C ++ em vez de Java, ou alguma outra linguagem altamente dinâmica. (O objetivo C também é ótimo, mas estou tentando dissipar mitos sobre o Qt)

Em resumo, é uma questão complicada. Mas gostaria de salientar que acho que há menos razões para "não usar o Qt", como se poderia pensar com base em mitos e informações desatualizadas de uma década.

Parte disso é licenciamento. Consulte https://en.wikipedia.org/wiki/Qt_(software)#Licensing para obter um pouco do histórico de licenciamento. Até 2000, pessoas que se preocupavam muito com o código aberto, não usavam o Qt. Período. (De fato, essa era a motivação original para o desenvolvimento do Gnome.) Até 2005, as pessoas que queriam lançar o software livre para Windows não usavam o Qt. Mesmo após essa data, as pessoas que queriam software livre sob algo diferente da GPL, simplesmente não tinham a opção de usar o Qt. Portanto, qualquer projeto de software livre anterior a essas datas não poderia usar o Qt. E, é claro, as pessoas que escrevem código proprietário tiveram que pagar pelo privilégio.

Além disso, não é como se houvesse escassez de outras opções. Por exemplo , WxWidgets , GTK + e Tk são todos kits de ferramentas de código aberto e plataforma cruzada.

Além disso, por muito tempo, o Windows era tão dominante na área de trabalho que muitos softwares estavam contentes em rodar apenas no Windows. Se você instalar o conjunto de ferramentas da Microsoft, é mais fácil usar as coisas proprietárias da Microsoft do que se preocupar com qualquer outra coisa, e muitos programadores fizeram exatamente isso.

Eu concordo com quase todas as razões discutidas acima, no entanto, muitas pessoas aqui disseram que não usariam o Qt por causa da sobrecarga extra que isso traz consigo. Eu discordo disso porque todas as linguagens mais comuns hoje em dia (Java, C # e Python) carregam uma grande quantidade de sobrecarga.

Em segundo lugar, o Qt torna a programação com C ++ tão fácil e direta que compensa os recursos extras que usa. Eu me deparei com vários aplicativos de console escritos em Qt, em vez de C ++ padrão, devido à facilidade com que eles podem ser escritos.

Eu diria que a produtividade do Qt é maior que a do C / C ++, mas menor que as linguagens como Python.

Isso realmente não é uma tentativa de iniciar uma guerra de chamas, eu só queria abordar alguns dos pontos.

Provavelmente, o motivo real pelo qual o Qt não é mais amplamente usado é o C ++ e menos pessoas usam o c ++ para aplicativos de desktop.

Qt não é uma biblioteca C ++. Requer uma etapa de compilação separada, o que torna o processo de criação muito mais complicado quando comparado com a maioria das outras bibliotecas.

O vs-addin para visual studio faz isso automaticamente, assim como o próprio processo de criação de linha de comando do Qt. O compilador de recursos usado para criar as caixas de diálogo para o MFC também é uma etapa separada, mas ainda é c ++.

Qt é uma grande quantidade de fontes, que deve estar presente e pré-instalada em qualquer máquina usada antes da compilação. Isso pode tornar a configuração de um ambiente de construção muito mais entediante.

Há um download binário para cada versão do visual studio e a compilação a partir da fonte é um único comando. Eu não vejo o tamanho da fonte do SDK hoje em dia. O Visual Studio agora instala todas as bibliotecas C ++ em vez de permitir que você escolha, como resultado, o tamanho da instalação do compilador é> 1 GB.

Está disponível apenas na LGPL, o que dificulta o uso da implantação binária única quando é necessário liberar sob uma licença mais restritiva ou menos restritiva.

A LGPL se aplica apenas à lib, não afeta o seu código. Sim, significa que você precisa enviar DLLs em vez de um único binário (a menos que você pague), mas em um mundo em que você precisa baixar um tempo de execução Java ou uma atualização .Net para um pequeno utilitário, isso não é um problema. Também é menos problemático em plataformas com uma única ABI, para que outros aplicativos Qt possam compartilhar as bibliotecas.

Em alguns casos, simplesmente não se parece com programas nativos. O design de uma interface do usuário única para todas as plataformas inerentemente não parecerá correto quando movido de máquina para máquina, por vários motivos de estilo visual.

É suposto usar widgets e temas nativos. Devo admitir que faço principalmente aplicativos técnicos, para que meus usuários não se preocupem muito com estilo. Especialmente no Windows, a nova moda de ter todo o estilo de widget de smartphone significa que existe cada vez menos um padrão.

O motivo é simples: ele não possui boas ligações para todos os idiomas comuns e nem sempre é magicamente apropriado para o trabalho em questão.

Use a ferramenta certa para o trabalho. Se estou escrevendo um aplicativo de linha de comando simples, por que eu iria inchar o Qt apenas por isso?

Como uma resposta mais geral (que eu posso dar porque sou relevante aqui), alguns programadores simplesmente nunca experimentaram e decidiram usá-lo. Em alguns casos, não há outra razão específica a não ser que o programador nunca tenha encontrado uma necessidade e a tenha analisado.

Frameworks como Qt são apropriadas quando você está mais preocupado com o seu produto procurando o mesmo em todas as plataformas do que com o seu produto de vista direita em todas as plataformas. Hoje em dia, cada vez mais, esses tipos de aplicativos estão migrando para tecnologias baseadas na Web.

Concordo que o Qt é uma estrutura legal para se trabalhar. Ainda assim, tenho vários problemas com ele:

1. Está escrito em C ++, que é realmente uma linguagem de baixo nível. Só o fato de ser C ++ tornará cada programador Qt significativamente menos produtivo em comparação com os Frameworks escritos em outras linguagens. Meu principal problema com o C ++ como linguagem de desenvolvimento da GUI é que ele quase não tem noção de gerenciamento automático de memória, o que torna o processo de desenvolvimento muito mais propenso a erros. Não é introspectivo, o que torna a depuração muito mais difícil. A maioria dos outros kits de ferramentas principais da GUI possui alguma noção de gerenciamento e introspecção automáticos de memória.
2. Todo kit de ferramentas de plataforma cruzada sofre com o problema de que apenas pode implementar o denominador menos comum de todas as plataformas suportadas. Isso e as diferentes diretrizes de interface do usuário em plataformas diferentes questionam muito a conveniência das GUIs de plataforma cruzada como um todo.
3. O Qt está muito centrado na codificação de toda a sua interface do usuário. Mesmo que você possa usar o QtDesigner para criar algumas partes da sua interface do usuário, falta muito em comparação com, por exemplo, o Construtor de Interface (Cocoa / Obj-C) ou as ferramentas .Net.
4. Embora o Qt inclua muitas funcionalidades de aplicativos de baixo nível, ele não pode ser comparado a ter uma estrutura personalizada para uma determinada plataforma. As bibliotecas nativas do sistema operacional para Windows e OSX são significativamente mais poderosas que as implementações do Qt. (Pense em estruturas de áudio, acesso ao sistema de arquivos de baixo nível etc.)

Dito isto, adoro usar o PyQt para prototipagem rápida de aplicativos ou aplicativos internos. Usar o Python para fazer toda a codificação alivia as preocupações com o C ++ e torna o Qt um local muito agradável.

Edite, em resposta a alguns comentários:

Quando escrevi sobre o Qt sendo escrito em C ++, não estava reclamando tanto do próprio Qt, mas mais do ambiente em que ele vive. É verdade que o Qt gerencia seus próprios recursos muito bem, mas todas as suas GUI relacionadas a O código não-Qt também deve ser escrito em C ++. Mesmo lá, o Qt fornece muitas ferramentas legais, mas, no final das contas, você precisa lidar com o C ++ nesse nível. O Qt torna o C ++ suportável, mas ainda é o C ++.

Quanto à introspecção, o que quero dizer é o seguinte: os casos mais difíceis de depurar são quando você tem um ponteiro para algum objeto que não se comporta da maneira que você pensa que deveria. Com o C ++, seu depurador pode procurar um pouco dentro do objeto (se houver informações de tipo no ponto thwt), mas mesmo isso nem sempre funciona. Tome, por outro lado, cacau na mesma situação. No Cocoa / Obj-C, você seria capaz de enviar mensagens ('funções de chamada') para um objeto dentro do depurador. Você pode alterar o estado dos objetos, consultar seus atributos, solicitar seu tipo e nome de função ... Isso pode tornar a depuração muito mais conveniente. Qt / C ++ não tem nada nem perto disso.

Eu realmente gosto do Qt, mas é um pouco pesado para muitas aplicações. Às vezes você simplesmente não precisa desse nível de complexidade. Às vezes, você só precisa de algo simples, sem toda a sobrecarga do Qt. Nem todo aplicativo precisa ser orientado a eventos e o C ++ fornece um conjunto razoável de modelos. O Boost fornece outro conjunto muito bom e inclui muitas das funcionalidades de baixo nível (arquivo, soquete, ponteiros gerenciados, etc.) que o QT fornece.

Outras aplicações têm requisitos de licenciamento que não se adaptam bem à licença comercial da GPL, LGPL ou Qt. A GPL é inadequada para software comercial. A LGPL é inadequada para software vinculado estaticamente e a licença comercial custa dinheiro - algo que muitos não estão dispostos a pagar.

Alguns têm considerações de segurança ou estabilidade que não permitem bibliotecas complexas como o Qt.

Você precisa executar o moc para pré-processar suas fontes. Esse não é um problema enorme, mas pode ser assustador para o novo usuário. Muitos programadores acham que você precisa usar o qmake com o Qt, mas isso é um nome impróprio. É possível conectar o Qt em outros sistemas de compilação facilmente.

Alguns destinos têm muita memória ou restrição de CPU.

Existem algumas dicas específicas da plataforma. A maioria dessas pegadinhas não tem documentos. Crie um aplicativo suficientemente grande e você os encontrará e se perguntará o que está acontecendo (aviso de isenção de responsabilidade, a última vez que usei o Qt com raiva foi há mais de 18 meses, por isso pode ter melhorado).

É apenas C ++. Existem outras associações de idioma, mas elas tendem a ocultar ou a expor mal muitas funcionalidades para as quais você deseja o Qt.

Existem muitas razões para não usar o Qt, é por isso que existem alternativas. Se tudo o que você tem é um martelo, todo problema parecerá um prego.

A coisa mais importante, mas não mencionada. No grande projeto, uma coisa causa muitos problemas e código não necessário. Os mecanismos de slot de sinal do Qt são ineficientes. Os widgets Qt não fornecem sinais necessários para widgets simples de eventos. Por exemplo, você não pode definir sinais para onHover, onMouseEnter, onMouseLeave, onKeyReleased, onLostFocus, onGainFocus e etc. Até o widget mais complexo, como o QTreeWidget, fornece um ou dois sinais inúteis ultra simples.

Sim, você pode usar eventos MAS !!! você criou uma nova classe para cada widget com evento customizado. Isso é enorme eficiência perdida;

• Você reescreve cada evento de objeto de widget customizado; há pequenas alterações.
• Você perde todas as coisas do Qt Designer. Você precisa promover todos os widgets com eventos personalizados.
• O projeto ficou maior e difícil de manter.
• Você começou a não gostar do qt por causa disso. E começando a falar sobre como o .net fornece delegados, como é muito, muito mais melhor do que o slot de sinal, como os componentes .net (widgets) geralmente fornecem todos os eventos que você pode imaginar. E etc.

Um membro da minha faculdade escreveu uma nova classe de caixa de combinação para cada widget de caixa de combinação, porque ele teve que usar algum evento sem sinal. História real...

No entanto, o Qt é a melhor estrutura de interface do usuário C ++ até agora, com baixos e altos.

na minha opinião, aprender programação C ++ é mais simples do que cair em outras linguagens que escondem sua complexidade, e o programador não sabe o que realmente acontece em segundo plano. O Qt, por outro lado, adiciona alguns benefícios sobre o C ++, para torná-lo mais alto que o C ++ nativo. Portanto, o Qt C ++ é uma ótima estrutura para quem deseja desenvolver tarefas de baixo nível, ou de alto nível, da mesma maneira. C ++ é (por algumas práticas) uma linguagem complexa e simples. Complexo para quem não quer desafiar, simples para quem gosta. Não deixe por sua complexidade!

O motivo real não é técnico.

As pessoas são diferentes. Então, são as escolhas deles. A uniformidade não é uma característica humana.