Perché non ci sono più app desktop scritte con Qt? [chiuso]

Per quanto ne so e ho capito nella mia esperienza con Qt, è una libreria molto buona e facile da imparare. Ha un'API molto ben progettata ed è multipiattaforma, e queste sono solo due delle molte caratteristiche che la rendono attraente. Sono interessato a sapere perché più programmatori non usano Qt. C'è una carenza che parla contro di essa? Quale caratteristica rende le altre librerie migliori di Qt? Il problema è legato alle licenze?

Non intendo davvero che questa sia una risposta sconcertante, ma questi sono i motivi per cui non uso personalmente Qt. Ci sono molte cose buone da dire al riguardo - vale a dire che l'API funziona la maggior parte del tempo e che collega perfettamente le piattaforme. Ma non utilizzo Qt, perché:

1. In alcuni casi, non sembra proprio come i programmi nativi. Progettare una singola interfaccia utente per tutte le piattaforme intrinsecamente non avrà un bell'aspetto quando viene spostato da una macchina all'altra, per vari motivi di stile visivo. Ad esempio, sui computer Mac, le barre divise sono in genere relativamente spesse e i pulsanti sono piccoli e arrotondati con icone. Su macchine Windows, le barre divise sono generalmente strette e i pulsanti sono più testuali, con disegni più quadrati. Solo perché puoi scrivere un'interfaccia utente per ogni piattaforma non significa che dovresti farlo per la maggior parte delle applicazioni.
2. Qt non è una libreria C ++. Richiede una fase di compilazione separata, che rende il processo di compilazione molto più complicato rispetto alla maggior parte delle altre librerie.
3. Come risultato di (2), gli IDE e gli strumenti C ++ possono contrassegnare le espressioni Qt come errori, perché non comprendono le specifiche di Qt. Questo quasi forza l'uso di QtCreator o di un editor solo testuale come vim.
4. Qt è una grande quantità di sorgente, che deve essere presente e preinstallata su qualsiasi macchina utilizzata prima della compilazione. Ciò può rendere molto più noiosa la configurazione di un ambiente di costruzione.
5. È disponibile solo con LGPL, il che rende difficile utilizzare la distribuzione binaria singola quando è necessario rilasciare con una licenza più restrittiva o meno restrittiva.
6. Produce binari compilati di dimensioni estremamente grandi rispetto a "applicazioni native semplici" scritte in modo simile (ad eccezione delle applicazioni ovviamente scritte per KDE).

Come si suol dire, ogni strumento si adatta a ogni problema e situazione ...

Ma se sei programmatore C ++, Qt è il tuo framework. Nessun rivale.

Sviluppiamo una complessa applicazione commerciale di imaging medico e Qt resiste.

Non dico che i "contro" che la gente dice a riguardo sono falsi, ma ho la sensazione che non abbiano provato Qt per molto tempo (il suo miglioramento continuo su ogni nuova versione ...) E, soprattutto tutte le questioni che commentano non sono un problema se ti prendi cura di te.

Incoerenza della piattaforma dell'interfaccia utente: solo se si utilizzano i widget dell'interfaccia utente "così come sono", senza personalizzazione o grafica personalizzata.

Sovraccarico del preprocessore Qt: solo se si abusa del meccanismo dello slot del segnale o dell'ereditarietà QObject, quando non è realmente necessario.

A proposito, scriviamo ancora applicazioni in C # .NET e lo facciamo da molto tempo. Quindi penso di avere una prospettiva.

Come ho detto, ogni strumento per ogni situazione,

ma Qt è senza dubbio un quadro coerente e utile.

Di tutte le cose che non mi piacciono di Qt, il fatto che non giochi bene con i template mi infastidisce di più. Non puoi farlo:

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

public signals:
  void something_happened(T);
};

Inoltre, non funziona bene con il preprocessore. Non puoi farlo:

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

Ciò, unito al fatto che tutto ciò che risponde a un segnale deve essere un Q_OBJECT, rende Qt difficile da lavorare per un programmatore C ++. Le persone abituate alla programmazione in stile Java o Python probabilmente in realtà sono piuttosto migliori.

In realtà ho speso molto tempo e fatica a ricercare e ideare un modo per recuperare la sicurezza del tipo e collegare un segnale Qt a qualsiasi oggetto funzione: http://crazyeddiecpp.blogspot.com/2011/01/quest-for-sane-signals -in-qt-step-1.html

Il tipo di cosa che voglio fare è lo sviluppo C ++ di base e quotidiano reso quasi impossibile dal motto Qt ... che di per sé non è assolutamente necessario oggi, se mai lo fosse.

Francamente, però, sono bloccato perché se vuoi fare test UI automatizzati, Qt è praticamente l'unico gioco in città a corto di MFC ... che è così 1980 (fa schifo lavorare in quella merda davvero difficile). Qualcuno potrebbe dire WX ma ha problemi ancora più gravi. GTKmm sarebbe stata la mia prima scelta, ma dal momento che è tutto disegnato dal proprietario e non fa accessibilità ... non può essere guidato da software di test standard del settore. Qt è abbastanza difficile in tal senso ( funziona a malapena quando si modifica il plug-in di accessibilità).

Uno dei motivi per non usare Qt è che se scrivi solo per un'architettura, come Windows, potresti voler usare C # /. NET (o Cocoa su Mac) perché invariabilmente saranno in grado di sfruttare le ultime campane e fischi del sistema operativo.

Se stai scrivendo app multipiattaforma, potresti già essere fortemente investito in un'altra tecnologia come Java (ovvero lavori in un "Negozio Java"). La tua scelta di tecnologia potrebbe essere dettata dall'ecosistema in cui stai sviluppando, come le API specifiche della lingua. In questi casi, può essere utile ridurre al minimo il numero di tecnologie.

Un terzo motivo che mi viene in mente è che Qt è basato su C ++ e C ++ è un linguaggio relativamente difficile / pericoloso in cui programmare. Penso che sia un linguaggio per professionisti. Se devi avere le massime prestazioni e essere meticoloso, allora C ++ è probabilmente il miglior gioco in città. In realtà, Qt migliora molti problemi di gestione della memoria se si impostano le cose per non rientrare nell'ambito. Inoltre, Qt stesso fa un buon lavoro isolando l'utente da molti dei cattivi problemi di C ++. Ogni lingua e quadro ha i suoi pro e contro. È un problema molto, molto complicato che di solito può essere sintetizzato dall'aggiunta spesso vista nei commensali: velocità, qualità e prezzo (ma puoi sceglierne solo due).

Anche se le regole dicono che dovrei rimanere concentrato sulla risposta alla domanda, voglio confutare alcune delle questioni sollevate da Billy ONeal, che penso faccia un buon lavoro riassumendo i motivi comunemente citati per non usare Qt:

1. Qt è in effetti una libreria C ++ / framework / file header. È aumentatoda un processore macro (moc) che abilita segnali e slot, tra le altre cose. Trasforma ulteriori comandi macro (come Q_OBJECT) in modo che le classi abbiano introspezione e ogni sorta di altre chicche che potresti pensare di aggiungere funzionalità C-Objective a C ++. Se conosci abbastanza C ++ per essere offeso da questa mancanza di purezza, ovvero sei un professionista, allora 1) non usare Q_OBJECT e il suo simile o 2) essere grato che lo faccia e programmare intorno a casi angolari molto limitati dove questo causa un problema. Per la gente che dice "Usa Boost per segnali e slot!" poi replicai che stai scambiando un "problema" con un altro. Il boost è enorme e ha i suoi problemi comunemente citati come scarsa documentazione, API orrende e orrori multipiattaforma (pensa ai vecchi compilatori come gcc 3.

2. Per il supporto dell'editor, anche questo segue da 1, sono abbastanza d'accordo. In realtà, Qt Creator è l'IMHO il miglior editor grafico C ++, punto, anche se non usi le cose Qt. Molti programmatori professionisti usano emacs e vim. Inoltre, penso che Eclipse gestisca la sintassi aggiuntiva. Pertanto, nessun problema con le macro Qt (Q_OBJECT) o le aggiunte di segnali / slot. Probabilmente non troverai queste macro in Visual Studio, perché (concedo) sono aggiunte al C ++. Ma in generale, la gente di NET # #. NET non utilizzerà comunque Qt, a causa del fatto che hanno molte funzionalità coperte con le proprie tecniche proprietarie.

3. Per quanto riguarda le dimensioni della fonte Qt, purché si compili durante la notte, a chi importa? Ho compilato Qt 4 sul mio Macbook dual core in "meno di una notte". Spero sicuramente che questo non sia ciò che sta guidando la tua decisione di utilizzare o meno una particolare tecnologia. Se questo è veramente un problema, puoi scaricare gli SDK precompilati per Mac, Linux e Windows dal sito Web Qt.

4. Le licenze sono disponibili in tre opzioni: 1) Licenza proprietaria nel caso in cui si desideri modificare Qt ITSELF e non condividere, o nascondere il fatto che si sta utilizzando Qt e non si desideri dare attribuzione (potrebbe essere molto importante per il branding e l'immagine!) 2 ) GPL e 3) LGPL. Sì, ci sono problemi con il collegamento statico (rotolare tutto Qt nel binario) - ma penso che sia più perché non si può sbirciare dentro e notare che si sta usando Qt (attribuzione!). Ho provato ad acquistare una licenza proprietaria da Digia e mi hanno detto "per quello che stai facendo, davvero non ne hai bisogno". Wow. Da un'azienda che si occupa di vendere licenze.

5. La dimensione del binario / bundle è perché devi distribuire le cose Qt alle persone che non ce l'hanno: Windows lo ha già? le cose di Visual Studio o devi installare il runtime. Il Mac arriva già con l'enorme cacao e può essere collegato dinamicamente. Anche se non faccio molta distribuzione, non ho mai trovato molti problemi con la distribuzione del file statico da ~ 50 megabyte (che posso rendere ancora più piccolo con alcune delle utilità binarie di stripper / compressione come UPX). Semplicemente non mi interessa abbastanza per farlo, ma se la larghezza di banda fosse un problema, aggiungerei un passaggio UPX al mio script di build.

6. Cosa definisce "Native Look and Feel?" Penso che "la maggior parte" sarebbe d'accordo sul fatto che il Mac si avvicini di più all'aspetto e all'aspetto unificati. Ma qui mi siedo, guardando Safari, iTunes, Aperture, Final Cut Pro, Pages, ecc. E non assomigliano per niente al fatto che siano realizzati dal venditore del sistema operativo. Penso che l'aspetto "feel" sia più rilevante: stile del widget, reattività, ecc. Se ti interessa la reattività, ecco un buon motivo per usare C ++ piuttosto che Java, o qualche altro linguaggio altamente dinamico. (Anche l'Obiettivo C oscilla, ma sto cercando di dissipare i miti su Qt)

In sintesi, è un problema complicato. Ma vorrei sottolineare che penso che ci siano meno ragioni per "non usare Qt", come si potrebbe pensare basandosi su miti e informazioni obsolete di un decennio.

Alcuni di questi sono licenze. Vedi https://en.wikipedia.org/wiki/Qt_(software)#Licensing per parte della cronologia delle licenze. Fino al 2000, le persone che si preoccupavano fortemente dell'open source non usavano Qt. Periodo. (Questa era, in effetti, la motivazione originale per lo sviluppo di Gnome.) Fino al 2005, le persone che volevano essere in grado di rilasciare software gratuito per Windows non utilizzavano Qt. Anche dopo quella data le persone che volevano software libero con qualcosa di diverso dalla GPL, semplicemente non avevano la possibilità di usare Qt. Quindi qualsiasi progetto di software libero che è più vecchio di quelle date, non potrebbe usare Qt. E, naturalmente, le persone che scrivono codice proprietario hanno dovuto pagare per il privilegio.

Inoltre non è come se mancassero altre opzioni. Ad esempio WxWidgets , GTK + e Tk sono tutti toolkit open source e multipiattaforma.

Inoltre per molto tempo Windows è stato così dominante sul desktop che molti software erano contenuti da eseguire solo su Windows. Se installi la toolchain di Microsoft, è più semplice usare le cose proprietarie di Microsoft che preoccuparsi di qualsiasi altra cosa, e molti programmatori hanno fatto proprio questo.

Sono d'accordo con quasi tutti i motivi discussi sopra, tuttavia molte persone qui hanno detto che non avrebbero usato Qt a causa del sovraccarico aggiuntivo che comporta. Non sono d'accordo con questo perché tutti i linguaggi più comuni oggi (Java, C # e Python) portano un bel po 'di sovraccarico.

In secondo luogo, Qt rende la programmazione con C ++ così semplice e diretta da compensare le risorse extra che utilizza. Mi sono imbattuto in parecchie applicazioni console scritte in Qt piuttosto che in C ++ standard a causa della facilità con cui possono essere scritte.

Direi che la produttività di Qt è maggiore di quella di C / C ++ ma inferiore a linguaggi come Python.

Questo non è davvero un tentativo di iniziare una guerra di fiamma, volevo solo affrontare alcuni dei punti.

Probabilmente il vero motivo per cui Qt non è più ampiamente usato è che è C ++ e meno persone usano c ++ per le app desktop.

Qt non è una libreria C ++. Richiede una fase di compilazione separata, che rende il processo di compilazione molto più complicato rispetto alla maggior parte delle altre librerie.

Il componente aggiuntivo vs per Visual Studio lo fa automaticamente così come il processo della riga di comando di Qt. Il compilatore di risorse utilizzato per creare le finestre di dialogo per MFC è anche un passaggio separato, che è comunque c ++.

Qt è una grande quantità di sorgente, che deve essere presente e preinstallata su qualsiasi macchina utilizzata prima della compilazione. Ciò può rendere molto più noiosa la configurazione di un ambiente di costruzione.

Esiste un download binario per ogni versione di Visual Studio e la compilazione dal sorgente è un singolo comando. Al giorno d'oggi non vedo che la dimensione del sorgente SDK sia un grosso problema. Visual Studio ora installa tutte le librerie C ++ anziché lasciarti scegliere, di conseguenza la dimensione di installazione del compilatore è> 1Gb.

È disponibile solo con LGPL, il che rende difficile utilizzare la distribuzione binaria singola quando è necessario rilasciare con una licenza più restrittiva o meno restrittiva.

La LGPL si applica solo alla lib, non influenza il tuo codice. Sì, significa che devi spedire DLL piuttosto che un singolo binario (a meno che tu non paghi), ma in un mondo in cui devi scaricare un runtime Java o un aggiornamento .Net per un piccolo util questo non è un grosso problema. È anche meno un problema su piattaforme con una singola ABI in modo che altre app Qt possano condividere le librerie.

In alcuni casi, non sembra proprio come i programmi nativi. Progettare una singola interfaccia utente per tutte le piattaforme intrinsecamente non avrà un bell'aspetto quando viene spostato da una macchina all'altra, per vari motivi di stile visivo.

Dovrebbe usare widget e temi nativi. Devo ammettere che faccio principalmente app tecniche quindi i miei utenti non sono troppo preoccupati per lo stile. Soprattutto su Windows, la nuova moda per avere tutto lo stile come un widget per smartphone significa che c'è sempre meno uno standard comunque.

Il motivo è semplice: non ha buoni legami con tutte le lingue tradizionali e non è sempre magicamente appropriato per il lavoro da svolgere.

Usa lo strumento giusto per il lavoro. Se sto scrivendo una semplice applicazione da riga di comando, perché dovrei gonfiarlo con Qt solo per il gusto di farlo?

Come risposta più generale (che posso dare perché sono rilevante qui), alcuni programmatori semplicemente non ci hanno mai provato e hanno deciso di usarlo. In alcuni casi non esiste un motivo particolare se non il programmatore che non ne ha mai trovato bisogno e lo ha esaminato.

I frame come Qt sono appropriati quando ti preoccupi più che il tuo prodotto appaia lo stesso su tutte le piattaforme che con il tuo prodotto che appaia su tutte le piattaforme. Sempre più spesso in questi giorni, questi tipi di applicazioni si stanno spostando verso tecnologie basate sul web.

Concordo sul fatto che Qt sia un buon framework con cui lavorare. Tuttavia, ci sono una serie di problemi che ho con esso:

1. È scritto in C ++, che è un linguaggio di livello veramente basso. Il solo fatto che sia C ++ renderà ogni programmatore Qt significativamente meno produttivo rispetto ai Frameworks scritti in altre lingue. La mia principale mania con C ++ come linguaggio di sviluppo della GUI è che non ha quasi alcuna nozione di gestione automatica della memoria, il che rende il processo di sviluppo molto più soggetto a errori. Non è introspettivo, il che rende molto più difficile il debug. La maggior parte degli altri principali toolkit della GUI ha una nozione di gestione automatica della memoria e introspezione.
2. Ogni toolkit multipiattaforma soffre del problema di poter sempre e solo implementare il minimo comune denominatore di tutte le piattaforme supportate. Questo e le diverse linee guida dell'interfaccia utente su piattaforme diverse mettono in discussione la desiderabilità delle GUI multipiattaforma nel loro insieme.
3. Qt è molto incentrato sulla codifica dell'intera interfaccia utente. Anche se è possibile utilizzare QtDesigner per creare alcune parti dell'interfaccia utente, è gravemente carente rispetto, ad esempio, al Interface Interface (Cocoa / Obj-C) o agli strumenti .Net.
4. Anche se Qt include molte funzionalità applicative di basso livello, non può essere paragonato ad avere un framework su misura per una determinata piattaforma. Le librerie del sistema operativo nativo per Windows e OSX sono significativamente più potenti delle implementazioni di Qt. (Pensa a framework audio, accesso a file system di basso livello ecc.)

Detto questo, adoro usare PyQt per la prototipazione rapida di applicazioni o applicazioni interne. L'uso di Python per fare tutto il codice allevia le preoccupazioni con C ++ e rende Qt un posto molto piacevole.

Modifica, in risposta ad alcuni commenti:

Quando ho scritto che Qt è stato scritto in C ++, non mi sono lamentato tanto di Qt stesso, ma piuttosto dell'ambiente in cui vive. È vero che Qt gestisce le proprie risorse molto bene, ma tutte le tue GUI-correlate- anche il codice non Qt deve essere scritto in C ++. Anche lì, Qt offre molti strumenti interessanti, ma alla fine devi gestire C ++ a quel livello. Qt rende sopportabile C ++, ma è ancora C ++.

Per quanto riguarda l'introspezione, ciò che intendo è questo: i casi più difficili da eseguire il debug sono quando si ha un puntatore a un oggetto che non si comporta come si pensa che dovrebbe. Con C ++, il tuo debugger potrebbe essere in grado di guardare un po 'all'interno di quell'oggetto (se capita di avere informazioni sul tipo in questo punto), ma anche questo non sempre funziona. Prendi, invece, il cacao nella stessa situazione. In Cocoa / Obj-C, si sarebbe in grado di inviare messaggi ("funzioni di chiamata") a un oggetto direttamente nel debugger. Puoi cambiare lo stato degli oggetti, puoi interrogarlo per i suoi attributi, puoi chiederne il tipo e i nomi delle sue funzioni ... Questo può rendere il debugging molto più conveniente. Qt / C ++ non ha nulla di simile.

Mi piace molto Qt, ma è un po 'pesante per molte applicazioni. A volte non hai bisogno di quel livello di complessità. A volte hai solo bisogno di qualcosa di semplice senza tutto il sovraccarico di Qt. Non tutte le applicazioni devono essere guidate da eventi e C ++ fornisce una serie ragionevole di modelli. Boost fornisce un altro ottimo set e include molte funzionalità di basso livello (file, socket, puntatori gestiti, ecc.) Di QT.

Altre applicazioni hanno requisiti di licenza che non funzionano bene con la licenza commerciale GPL, LGPL o Qt. La GPL non è appropriata per i software commerciali. La LGPL è inappropriata per i software collegati staticamente e la licenza commerciale costa denaro, cosa che molti non sono disposti a pagare.

Alcuni hanno considerazioni di sicurezza o stabilità che non consentono librerie complesse come Qt.

Devi eseguire moc per pre-elaborare le tue fonti. Non è un grosso problema, ma può essere scoraggiante per il nuovo utente. Molti programmatori pensano che tu debba usare qmake con Qt, ma questo è un termine improprio. È possibile collegare abbastanza facilmente Qt ad altri sistemi di compilazione.

Alcuni target sono molto limitati dalla memoria o dalla CPU.

Ci sono alcuni gotcha specifici per la piattaforma. La maggior parte di quei gotcha non sono documentati. Costruisci un'applicazione sufficientemente grande e ti imbatterai in loro e ti chiederai cosa sta succedendo (dichiarazione di non responsabilità, l'ultima volta che ho usato Qt con rabbia è stato più di 18 mesi fa, quindi potrebbe essere migliorato).

È solo C ++. Esistono altri collegamenti linguistici, ma tendono a nascondere o esporre male molte delle funzionalità per cui vorresti Qt.

Ci sono molte ragioni per non usare Qt, ecco perché ci sono alternative. Se tutto ciò che hai è un martello, ogni problema sembrerà un chiodo.

La cosa più importante ma non menzionata. Nel grande progetto una cosa causa così tanti problemi e codice non necessario. I meccanismi di slot del segnale di Qt sono inefficienti. I widget Qt non forniscono i segnali necessari per i widget semplici per eventi. Ad esempio non è possibile impostare segnali per onHover, onMouseEnter, onMouseLeave, onKeyReleased, onLostFocus, onGainFocus e così via. Anche il widget più complesso come QTreeWidget fornisce uno o due segnali inutili ultra semplici.

Sì, puoi usare gli eventi MA !!! hai creato una nuova classe per ogni widget con evento personalizzato. Questa è un'enorme efficienza persa;

• Hai riscritto ogni evento di oggetto widget personalizzato con piccole modifiche.
• Perdi tutte le cose di Qt Designer. Devi promuovere ogni widget con eventi personalizzati.
• Il progetto è diventato più grande e difficile da mantenere.
• Hai iniziato a non amare qt per questo. E iniziando a parlare di come .net fornisce ai delegati, di come sia molto molto meglio dello slot di segnale, di come i componenti .net (widget) generalmente forniscono ogni evento che si possa immaginare. E così via.

Uno del mio college ha scritto una nuova classe di combo box per ogni widget di combo box perché ha dovuto usare qualche evento senza segnale. Storia vera...

Tuttavia, Qt è il miglior framework dell'interfaccia utente C ++ finora con bassi e alti.

secondo me, imparare la programmazione in C ++ è più semplice che cadere in altre lingue che nascondono la loro complessità, e il programmatore non sa cosa succede realmente in background. Qt d'altra parte, aggiunge alcuni vantaggi rispetto al C ++, per renderlo di livello superiore rispetto al C ++ nativo. Quindi Qt C ++ è un ottimo framework per chi vuole sviluppare compiti di basso livello, o di alto livello, con lo stesso modo. Il C ++ è (secondo alcune pratiche) un linguaggio complesso e semplice. Complesso per chi non vuole sfidarlo, semplice per chi gli piace. Non lasciarlo per la sua complessità!

Il vero motivo non è tecnico.

Le persone sono diverse. Quindi sono le loro scelte. L'uniformità non è una caratteristica umana.