Varför är ' inte fler skrivbordsappar skrivna med Qt? [stängd]

Jag tänker inte riktigt att detta ska vara ett bash svar, men det är anledningarna till att jag gör inte personligen använda Qt. Det finns gott om bra saker att säga om det – nämligen att API: n fungerar för det mesta och att det smidigt överbryggar plattformar. Men jag använder inte Qt, för:

1. I vissa fall ser det bara inte ut som inbyggda program ser ut. Att designa ett enda användargränssnitt för alla plattformar kommer inte att se bra ut när det flyttas från maskin till maskin, av olika visuella stylingsskäl. På Mac-maskiner är delade staplar vanligtvis relativt tjocka och knapparna är små och rundade med ikoner. På Windows-maskiner är delade staplar vanligtvis smala och knapparna är mer textuella med mer fyrkantiga mönster. Bara för att du kan skriva ett användargränssnitt för varje plattform betyder inte att du borde göra det för de flesta applikationer.
2. Qt är inte bara en länkbar uppsättning C ++ – bibliotek. Byggsystemet som används kräver översättning av vissa filer till extra källfiler, vilket gör byggprocessen mycket mer komplicerad jämfört med de flesta andra bibliotek.
3. Som ett resultat av (2), C ++ IDE: er och verktyg kan flagga Qt-uttryck som fel eftersom de inte förstår Qt: s detaljer. Detta tvingar nästan användning av QtCreator eller en textredigerare som vim.
4. Qt är en stor mängd källa som måste finnas och förinstalleras på alla maskiner du använder innan du kompilerar. Detta kan göra installationen av en byggmiljö mycket mer tråkig.
5. Delar är mestadels licensierade under LGPL, vilket gör det är svårt att använda en-binär distribution när man behöver släppa under en mer restriktiv eller mindre restriktiv licens.
6. Det producerar extremt stora kompilerade binärer jämfört med liknande skrivna " vanliga ol ”native applikationer " (med undantag för naturligtvis applikationsskriv tio för KDE).

Kommentarer

• @Dehumanizer: Det finns ' LGPL-licens och där ' är den kommersiella licensen. Den kommersiella licensen är tusentals dollar från licensinnehavarens sida och tillåter inte omfördelning etc. För open source-projekt under liberala licenser som BSD, MIT eller Boost, där författarna inte är ' t tjänar massor av pengar och de vill släppa sin kod under en liberal licens, ett beroende av LGPL är orimligt, men utvecklarna i fråga har i allmänhet inte råd med kommersiell licensiering.
• # 6 är den största anledning till att jag undviker det. Jag menar att jag inte ' inte vill ha ett stort, klumpigt program och jag vill inte ' vara bunden till en specifik licens, men det ' är verkligen bristen på en bra, inhemsk look-and-feel som ' är en affärsbrytare för mig.Nya versioner av OSX och Windows har specifikt gjort ett fantastiskt jobb med att göra sina egna gränssnitt vackra, snabba och funktionella, och jag ' vill hellre utnyttja allt arbete de ' har redan gjort för mig; Jag tycker att många program utan ett inbyggt utseende känns billiga och hackiga för mig (inte alltid, men det förvirrar mig lite).
• Ditt nummer 6 borde ha varit nummer 1. Detta är av långt det största problemet med Qt. I många fall använder den helt enkelt inte de inbyggda API: erna. Jag gillar att min programvara ser ut som infödd. Användare gillar det också. Jag ' har aldrig sett ett Mac-program skapat med Qt som såg ut som ett Mac-program. Inte heller har några andra Mac-användare, och de ' är noga med den typen av saker. Du förlorar alla fördelarna med att det är " tvärplattform " om du ' använder den bara för att skapa Linux-applikationer, vilket är ungefär det enda stället det ser ut som inbyggt eftersom det verkligen inte finns något inbyggt.
• utom problemet med ' native ' utseendet finns inte längre. Den gamla konsistensen av Windows-appar är nu en bastardisering av vad unika blobbar, glöd och animationer som WPF och silverlight låter dig ha. Ta en titt på Office eller Windows 7 ' Kontrollpanelen för att se hur jämn MS: s flaggskeppsprodukt har inkonsekvent GUI nuförtiden. Mac-användare – ja, du har mycket giltig punkt där.
• @TrevorBoydSmith: Tyvärr, men du ' har fel. Qt är det enda ramverket som använder förbehandling. Period. Kontrollera GNOME, FLTK, WX och vänner och visa mig ett förbehandlingssteg. Du vann ' att inte hitta en. Vissa andra bibliotek kommer med olika byggsystem, men i slutet av dagen är de C ++ – bibliotek som kan byggas av vilken C ++ – kompilator som helst. När det gäller " Raw win32 som inte finns i mina skäl ", det är närvarande i mina skäl som # 5 och # 6.

Som folk säger passar varje verktyg till varje problem och situation …

Men om du är C ++ – programmerare är Qt ditt ramverk. Ingen konkurrent.

Vi utvecklar en komplex kommersiell applikation för medicinsk bildbehandling och Qt håller kvar.

Jag säger inte det ”nackdelarna” som folk säger om det är falska, men jag har en känsla av att de inte har provat Qt under lång tid (det förbättras kontinuerligt för varje ny version …) Och mest alla frågor de kommenterar är inte ett problem om du tar hand.

UI-plattformens inkonsekvens: bara om du använder UI-widgetarna ”som de är”, utan anpassning eller anpassad konst.

Qt preprocessoröverbelastning : Endast om du missbrukar signal-slot-mekanismen eller QObject-arv, när det inte finns något egentligen behov.

Förresten, vi skriver fortfarande applikationer i C # .NET och har varit gör det länge. Så jag tror att jag har enouch perspektiv.

Som sagt, varje verktyg för varje situation,

men Qt är utan tvekan en konsekvent och användbar ram.

Kommentarer

• +1 Thaks! Jag ville bara skriva samma sak. Det mest nonsens är " argument utan öppen källkod / kommersiellt ". Häpnadsväckande, hur fel många människor förstår termen Open Source. Qt var öppen källkod eftersom jag använder den (1.4). Och det hade tidigare den mest rättvisa licensen: tjäna pengar med Qt – > pay.
• Åh och jag don verkligen inte ' t VIKTIGT om att lägga till 10 MB DLL-filer till applikationer som innehåller 50 MB konst och 200 MB till videoklipp och data 🙂
• Det utrymme som behövs för Qt är billigt idag.
• Detta matchar ganska mycket min upplevelse med Qt (widgetramverket, jag har inte ' inte använt QML / QtQuick för något seriöst hittills). Det är lämpligt att skriva stora applikationer med komplexa UI-krav. När du väl har lärt dig det kan du vara väldigt produktiv. Nämnda nackdelar (separat kompileringssteg för mocing, ui-filer osv.) Är inte ett problem om byggsystemet är korrekt inställt. Jag kan rekommendera antingen qmake eller cmake.
• från Qt 5.8 efteråt finns det ett projekt som heter Qt Lite som minimerar extremt Qt för dina specifika behov. detta är en kommersiell funktion;)

Av alla saker jag inte tycker om Qt, det faktum att det inte spelar bra med mallar stör mig mest. Du kan inte göra detta:

template < typename T > struct templated_widget : QWidget { Q_OBJECT; public signals: void something_happened(T); }; 

Det spelar inte heller bra med förprocessorn. Du kan inte göra detta:

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

Det, blandat med det faktum att allt som svarar på en signal måste vara en Q_OBJECT, gör Qt svårt att arbeta in för en C ++ -programmerare. Människor som brukade programmera Java eller Python-stil antagligen ganska bättre faktiskt.

Jag tillbringade faktiskt mycket tid och ansträngningar på att undersöka och utforma ett sätt att få typsäkerhet tillbaka och ansluta en Qt-signal till valfritt funktionsobjekt: http://crazyeddiecpp.blogspot.com/2011/01/quest-for-sane-signals-in-qt-step-1.html

Den typ av saker jag vill göra där är grundläggande, vardaglig C ++ – utveckling som nästan är omöjlig av Qt moc … som i sig är helt onödigt nu dagar, om det någonsin faktiskt var.

Uppriktigt sagt hänger jag fast med det för om du vill göra automatiserad UI-testning är Qt i stort sett det enda spelet i stan som inte är MFC. ..som är så 1980 (det suger att jobba i den där skiten riktigt hårt). Vissa kanske säger WX men det har fått ännu allvarligare problem. GTKmm skulle ha varit mitt första val, men eftersom det är alla ägare ritade och inte gör tillgänglighet … kan inte drivas av branschstandard testprogramvara. Qt är tillräckligt svårt i det avseendet ( knappt fungerar när du ändrar tillgänglighetsplugin).

Kommentarer

• Av intresse, vad ser du som de största problemen med WX?
• @Tom – dålig dokumentation, särskilt för de nya grejerna. AUI-komponenterna är knappt dokumenterade alls med stora delar saknas, vilket gör det svårt att använda i en produktionsmiljö. Dokumentationen för händelseprocessen är i grunden felaktig med avseende på den väg som följs, åtminstone på win32. Tillbringade mycket tid att skrika på datorn, " Detta borde fungera !!! " innan du går in i den djupa bearbetningskoden för att ta reda på att vad WX gör inte ' t att följa dokumenten och vad jag gjorde skulle ALDRIG fungera.
• Jag var störs också av godkännandet av fastighetsnätbiblioteket i huvudraden. Jag använde det biblioteket och det visade många grundläggande designfel utöver faktisk brist på kunskap på uppdrag av programmeraren som skrev det (till exempel kallade virtuella funktioner i konstruktörer). Det och AUI: s dåliga tillstånd visade en trend till sämre standarder. Jag ' Jag är inte heller ett stort fan av statiska händelsetabeller, men åtminstone finns det ' ett annat sätt att svara på händelser … till skillnad från MFC, vilken WX bara är för mycket att vara spännande ändå.
• Tack. Jag ' har bara använt det lite, och genom wxPython API, där det verkade ganska trevligt. Jag kan uppskatta att det skulle dölja en del av det onda, men också att jag bara inte har ' Jag blev djupt nog involverad för att ha stött på de allvarligare problemen. Något för mig att vara medveten om.
• Allt som svarar på en signal måste vara en Q_OBJECT, Nej nuförtiden … Nu kan statiska funktioner, funktioner och till och med lambdafunktioner svara på en signal (du kan använda funktionspekare som kortplatser). No-QObject-klasser kan också ha medlemsplatser om du ansluter till dem med en std :: bind för att konvertera förekomstmedlem till en funktionspekare.

En anledning att inte använda Qt är att om du bara skriver för en arkitektur, till exempel Windows, kanske du vill använda C # /. NET (eller kakao på Mac) eftersom de alltid kommer att kunna dra nytta av de senaste klockorna och visselpiporna i operativsystemet.

Om du skriver plattformsappar kan det hända att du redan är starkt belägen i en annan teknik som Java (dvs. du arbetar i en ”Java Shop”). Ditt val av teknik kan dikteras av det ekosystem som du utvecklar i, till exempel språkspecifika API: er. I sådana fall kan det vara fördelaktigt att minimera antalet tekniker.

En tredje anledning som jag kan tänka mig är att Qt baseras på C ++, och C ++ är ett relativt svårt / farligt språk att programmera på Jag tror att det är ett språk för proffs. Om du behöver ha högsta prestanda och kan vara noggrann, är C ++ nog det bästa spelet i stan. Egentligen förbättrar Qt många av minneshanteringsproblemen om du ställer in saker så att de faller utanför räckvidden. Qt själv gör också ett bra jobb med att isolera användaren från många otäcka C ++ – problem. Varje språk och ram har sina för- och nackdelar. Det är en mycket, mycket komplicerad fråga som vanligtvis kan sammanfattas av det tillägg som ofta ses hos diners: hastighet, kvalitet och pris (men du kan bara välja två).

Även om reglerna säger att jag ska hålla fokuserad på att svara på frågan vill jag motbevisa några av de frågor som tagits upp av Billy ONeal, som jag tycker gör ett bra jobb med att sammanfatta de vanliga skälen att inte använda Qt:

1. Qt är verkligen ett C ++ – bibliotek / ramverk / rubrikfiler. Det är förstärkt av en makroprocessor (moc) som möjliggör signaler och kortplatser, bland många andra saker. Det omvandlar ytterligare makrokommandon (som Q_OBJECT) så att klasserna har introspektion och alla möjliga andra godsaker som du kan tänka dig att lägga till Objective-C-funktionalitet till C ++. Om du vet tillräckligt om C ++ för att bli förolämpad av denna brist på renhet, dvs.du är en proffs, så 1) använd inte Q_OBJECT och dess liknelse eller 2) var tacksam för att det gör det, och programmera runt de mycket begränsade hörnfall där detta orsakar ett problem. För folk som säger ”Använd Boost för signaler och slots! ”då skulle jag svara på att du byter ut ett” problem ”mot ett annat. Boost är enormt, och det har sina egna vanliga problem som dålig dokumentation, fruktansvärda API och fasor över flera plattformar (tänk gamla kompilatorer som gcc 3.3 och stora järnkompilatorer som AIX).

2. För redaktörsstöd följer detta också från 1, jag är något överens. Faktiskt är Qt Creator IMHO den bästa grafiska C ++ -redigeraren, period , även om du inte använder Qt-grejerna. Många professionella programmerare använder emacs och vim. Jag tror också att Eclipse hanterar ytterligare syntax. Således inga problem med Qt-makron (Q_OBJECT) eller tillägg av signaler / kortplatser. Du kommer förmodligen inte att hitta dessa makron i Visual Studio, för (jag medger) de är tillägg till C ++. Men i stort sett kommer C # /. NET-människor inte att använda Qt ändå, på grund av att de har mycket av funktionaliteten som täcks av sina egna patenterade tekniker.

3. När det gäller storleken på Qt-källan, vem bryr sig så länge den kompileras över natten? Jag sammanställde Qt 4 på min dubbla kärn Macbook i ”mindre än över natten.” Jag hoppas verkligen att det inte är det som driver ditt beslut att använda eller inte använda en viss teknik. Om detta verkligen är ett problem kan du ladda ner de förkompilerade SDK: erna för Mac, Linux och Windows från Qt-webbplatsen.

4. Licensiering är finns i tre val: 1) Proprietär licens om du vill ändra Qt SJÄLV och inte dela, eller dölja det faktum att man använder Qt och inte är villig att ge tillskrivning (kan vara mycket viktigt för branding och bild!) 2) GPL och 3) LGPL Ja, det finns problem med statisk länkning (rullar hela Qt in i binären) – men jag tror att det är mer för att man inte kan kika in och märka att du är u sjung Qt (tillskrivning!). Jag försökte köpa en licens från Digia, och de sa till mig ”för vad du gör behöver du verkligen inte det.” Wow. Från ett företag som säljer licenser.

5. Storleken på binär / paketet beror på att du måste distribuera Qt-saker till människor som inte har det: Windows har redan? Visual Studio-grejerna eller så måste du installera körtiden. Mac kommer redan med den enorma kakao och kan kopplas dynamiskt. Även om jag inte distribuerar mycket, har jag aldrig hittat mycket problem med att distribuera den statiska filen ~ 50 megabyte (som jag kan göra ännu mindre med några av de binära stripper / komprimeringsverktygen som UPX). Jag bara inte bryr mig nog för att göra detta, men om bandbredd någonsin var ett problem, skulle jag lägga till ett UPX-steg i mitt byggskript.

6. Vad definierar ”Native Look and Feel?” Jag tror ”de flesta” håller med om att Mac kommer närmast enhetligt utseende. Men här sitter jag och tittar på Safari, iTunes, Aperture, Final Cut Pro, Pages, etc. och de ser ingenting ut trots att de är gjorda av OS-leverantören. Jag tycker att ”känsla” -aspekten är mer relevant: widget-styling, lyhördhet, etc. Om du bryr dig om lyhördhet är det här en bra anledning att använda C ++ snarare än Java eller något annat mycket dynamiskt språk. (Mål C stenar också, men jag försöker skingra myter om Qt).

Sammanfattningsvis är det en komplicerad fråga. Men jag vill påpeka att jag tror att det finns färre skäl att ”inte använda Qt” som man kan tro utifrån myter och föråldrad information.

Kommentarer

• Vad jag inte får ' är varför dessa plattformsbibliotek inte är ' t helt enkelt omslagsfunktioner , eller ännu bättre; om defs runt Cocoa, Win32, KDE / Gnome fungerar, vilket säkerställer det snyggaste användargränssnittet, med allt det ' s funktioner.
• @MarcusJ Skriv ett omslag runt ett verktygslåda är tydligt icke-trivialt, kom ihåg 4 eller fler – men om du tycker att det ' är så enkelt, är du ' välkommen att försöka. När det gäller tanken att detta skulle kunna uppnås med enbart villkorlig förbehandling … måste du skoja, eller hur?
• @MarcusJ libui är exakt det (men utan KDE-stöd).
• Jag vill lägga till att du nu kan använda Qt / QML med .NET. Du behöver inte ' röra C ++. github.com/qmlnet/qmlnet PS: Jag ' författaren.

En del av det är licensierat. Se https://en.wikipedia.org/wiki/Qt_(software) #Licensing för en del av licenshistoriken. Fram till 2000 använde personer som brydde sig mycket om öppen källkod inte Qt. Period. (Detta var faktiskt den ursprungliga motivationen för utvecklingen av Gnome.) Fram till 2005 använde personer som ville kunna släppa fri programvara för Windows inte Qt.Även efter det datumet hade människor som ville ha fri programvara under något annat än GPL helt enkelt inte möjlighet att använda Qt. Alla gratis programvaruprojekt som är äldre än dessa datum kunde inte använda Qt. Och naturligtvis måste personer som skriver egen kod betala för privilegiet.

Dessutom är det inte som om det finns en brist på andra alternativ. Till exempel WxWidgets , GTK + och Tk är alla öppen källkod, plattformsverktygssatser.

Dessutom var Windows under en lång tid så dominerande på skrivbordet att mycket programvara var innehåll för att bara köra på Windows. Om du installerar Microsofts verktygskedja är det lättare att bara använda Microsofts egna saker än att oroa sig för något annat, och många programmerare gjorde just det.

Kommentarer

• @btilly: GTK + är plattform. Till exempel är Pidgin IM-klienten skriven på GTK +.
• Okej, det är dock möjligt ' på något sätt ' att köra på Windows 🙂
• Installera bara GIMP på Windows och kolla.
• Ja, och GIMP fungerar bra på Windows, men det gör verkligen inte ' passar inte in i Windows 7 UI look & känsla.
• Pidgin är förmodligen ett bättre exempel på GTK i Windows. ' t gör något fint, men det passar in och har kanske i tio år eller mer?

Jag håller med nästan alla anledningar som diskuterats ovan men många människor här har sagt att de inte skulle vilja använda Qt på grund av den extra kostnad som det medför. Jag håller inte med med det eftersom alla de vanligaste språken idag (Java, C # och Python) har en hel del omkostnader själva.

För det andra gör Qt programmering med C ++ så enkelt och rakt fram att det kompenserar för extra resurser som den använder. Jag har stött på en hel del konsolapplikationer skrivna i Qt snarare än standard C ++ på grund av att de är enkla att skriva.

Jag skulle säga att produktiviteten för Qt är högre än för C / C ++ men mindre än språk som Python.

Kommentarer

• Jag antar att det ' är allt i förhållande till den enskilda ' s upplevelse, för jag kan koda OK i C ++ 14, men varje gång jag tittar på någon Qt-kod måste jag kasta mig hårt för att känna igen den som samma språk … så jag tänker verkligen inte ' ' är den enhälliga produktivitetsförstärkaren du ' antyder här.
• @underscore_d uppenbarligen om du känner till C ++ mycket bra och du inte ' t Qt, du blir inte mer produktiv med den senare. Men när du lär känna både C ++ och Qt gör ramverket verkligen många saker enklare och snabbare att implementera (C ++ 11, 14 etc fyller gapet, men inte helt än).

Detta är verkligen inte ett försök att inleda ett flammekrig, jag ville bara ta upp några av punkterna.

Förmodligen är den verkliga anledningen till att Qt inte används mer allmänt att det är C ++ och färre människor använder c ++ för stationära appar.

Qt är inte ett C ++ – bibliotek. Det kräver ett separat sammanställningssteg, vilket gör byggprocessen mycket mer komplicerad jämfört med de flesta andra bibliotek.

vs-addin för visual studio gör detta automatiskt liksom Qts egen kommandoradsprocess. Resurskompilatorn som används för att bygga dialogerna för MFC är också ett separat steg men det är fortfarande c ++.

Qt är en stor mängd källa, vilket måste vara närvarande och förinstallerat på vilken maskin du använder innan du kompilerar. Detta kan göra installationen av en byggmiljö mycket tråkigare.

Det finns en binär nedladdning för varje version av Visual Studio och build från källan är ett enda kommando. Jag ser inte att SDK-källstorleken är så mycket av en affär idag. Visual studio installerar nu alla C ++ libs snarare än att låta dig välja och välja, vilket innebär att kompilatorns installationsstorlek är> 1Gb.

It ” s endast tillgängligt under LGPL, vilket gör det svårt att använda en-binär-distribution när man behöver släppa under en mer restriktiv eller mindre restriktiv licens.

LGPL gäller bara lib, det påverkar inte din kod. Ja, det betyder att du måste skicka DLL-filer i stället för en enda binär (om du inte betalar), men i en värld där du behöver ladda ner en Java-runtime eller en .Net-uppdatering för ett litet utnyttjande är det inte så mycket. ”är också mindre problem på plattformar med en enda ABI så att andra Qt-appar kan dela libs.

I vissa fall gör det bara inte” t ser ut som inbyggda program ser ut.Att utforma ett enda användargränssnitt för alla plattformar i sig kommer inte att se bra ut när det flyttas från maskin till maskin, av olika visuella utformningsskäl.

Det antas att använda inbyggda widgetar och teman. Jag måste erkänna att jag gör mestadels tekniska appar så att mina användare inte är så bekymrade över stil. Särskilt på windows innebär det nya sättet att ha allt stil som en smarttelefonwidget att det finns mindre och mindre standard ändå.

Kommentarer

• Ganska många stora programvaruföretag bygger kommersiella applikationer i C ++ men jag ' är inte medveten om så många som använder QT. Så även om jag förstår att icke-C ++ – utvecklare kan undvika QT, det finns andra skäl att undvika QT även om du skriver en C ++ – app, det verkar. Faktum är att det verkligen inte finns ' t någon plattformsspråk och GUI-verktygslåda som jag ' inte kan hitta fel med. Det verkar som att plattformsutveckling är BARA PLATT HÅRD, och att det är aldrig enkelt eller gratis att göra det bra, och att löftet som QT ger (Skriv ditt GUI en gång och återanvänd det GUI överallt) är inte '
• De flesta C ++ -programvaror på skrivbordet finns antingen i MFC eftersom de startade för 20 år sedan eller använder en intern verktygslåda som startades för 20 år sedan för att undvika MFC (t.ex. MS-Office eller Autocad). Jag tvivlar mycket på att det skrivs i C ++ / CLR med WPF. Men även utan överväganden över flera plattformar tycker jag att Qt är det bästa (eller minst värsta!) Skrivbordsverktygssatsen. Som de flesta människor går vi mot en webby-frontend (möjligen i QtQuick / QML) och en C ++ server-backend – som förmodligen kommer att använda Qt-signaler / slots men ingen gui
• Jag håller med. Minst värst. Och även i Windows-appar bara ' vill jag felsöka QT-problem än MFC-problem.
• @WarrenP – ja jag gör inte ' missa inte att söka i kodprojekt efter alla saker som saknas i MFC. Men med MSFT ' s nyfunnna kärlek till inbyggd kod – de har ' inte gjort mycket för att göra skrivandet av en gui lättare.

Anledningen är enkel: den har inte bra bindningar till alla vanliga språk, och det är inte magiskt alltid lämpligt för jobbet.

Använd rätt verktyg för jobbet. Om jag skriver en enkel kommandoradsapplikation, varför skulle jag spränga upp det med Qt bara för det?

Som ett mer allmänt svar (som jag kan ge eftersom jag är relevant här ), vissa programmerare kommer helt enkelt aldrig att ge det en chans och bestämde sig för att använda den. I vissa fall finns det ingen särskild anledning förutom att programmeraren aldrig har funnit något behov av det och tittat på det.

Kommentarer

• Men Qt ger förmåga att bara skriva konsolapplikation. Är det inte '?
• @Dehumanizer: Jag har ingen aning. Men varför skulle jag använda den för ett litet verktygsverktyg? Vilken fördel skulle det ge mig när jag trivialt kan skriva applikationen i bara standard C ++? Verkar som att du ' söker efter en anledning att använda ett bibliotek , vilket är ett bakåtläge att programmera.
• @Dehumanizer: Som Jag sa att ' är bakåtgående. När du hittar ett behov av ett bibliotek vet du ', och sedan kan du testa några och se vad som passar dina behov bättre. Att försöka samla åsikter om ett bibliotek när du inte ' inte har ett användningsfall är en dårskap ' ärende.
• " Om jag ' skriver en enkel kommandoradsapplikation, varför skulle jag spränga upp det med Qt bara för det " finns det åtminstone ett mycket känt icke-gui-verktyg skrivet i Qt – Doxygen 🙂
• @Dehumanizer till exempel när du måste hantera filer, xml, unicode, json, regexp, concurency, databaser, etc, etc, mycket snabbt och inte ' t vill ladda ner, anta, underhålla dussin 3: e partibibliotek.

Ramar som Qt är lämpliga när du är mer intresserad av att din produkt ser ut samma på alla plattformar än med att din produkt ser rätt ut på alla plattformar. Allt oftare för närvarande flyttar sådana applikationer till webbaserad teknik.

enligt min mening är att lära mig C ++ programmering enklare än att falla på andra språk som döljer deras komplexitet, och programmerare vet inte vad verkligen händer i bakgrunden. Qt å andra sidan lägger till några fördelar jämfört med C ++, för att göra det högre än native C ++. Således är Qt C ++ ett bra ramverk för vem som vill utveckla lågnivåuppgifter eller högnivåuppgifter på samma sätt. C ++ är (enligt vissa metoder) ett komplext och enkelt språk. Komplex för vem som inte vill utmana med det, enkelt för den som gillar det.Lämna det inte för komplexiteten!

Jag håller med om att Qt är en trevlig ram att arbeta med. Det finns fortfarande ett antal problem jag har med det:

1. Det är skrivet i C ++, vilket är ett riktigt lågt språk. Att det bara är C ++ kommer att göra alla Qt-programmerare betydligt mindre produktiva jämfört med Frameworks skrivna på andra språk. Mitt främsta nötkött med C ++ som ett GUI-utvecklingsspråk är att det nästan inte har någon uppfattning om automatisk minneshantering, vilket gör utvecklingsprocessen mycket mer benägen för fel. Det är inte introspektivt, vilket gör felsökning mycket svårare. De flesta av de andra stora GUI-verktygslådorna har en viss uppfattning om automatisk minneshantering och introspektion.
2. Varje plattformsverktygssats lider av problemet att den bara någonsin kan implementera den minst gemensamma nämnaren av alla stödda plattformar. Det och olika riktlinjer för användargränssnitt på olika plattformar ifrågasätter i hög grad önskvärdheten för gränssnitt över flera plattformar som helhet.
3. Qt är mycket centrerat om att koda upp alla dina användargränssnitt. Även om du kan använda QtDesigner för att bygga vissa delar av ditt användargränssnitt saknas det allvarligt i jämförelse med exempelvis (Cocoa / Obj-C) Interface Builder eller. Net-verktygen.
4. Även om Qt inte innehåller mycket applikationsfunktioner på låg nivå, kan det inte jämföras med att ha ett ramverk skräddarsytt för en viss plattform. De inbyggda operativsystembiblioteken för både Windows och OSX är betydligt kraftfullare än Qt: s implementeringar. (Tänk ljudramar, filnivååtkomst på låg nivå etc.)

Som sagt, jag älskar att använda PyQt för snabb applikationsprototypning eller interna applikationer. Att använda Python för att göra all kodning lindrar bekymmerna med C ++ och gör Qt till en mycket trevlig plats.