Waarom zijn ' niet meer desktop-apps geschreven met Qt? [gesloten]

Ik ben niet echt van plan dat dit een bashing-antwoord is, maar dit zijn de redenen waarom ik dat doe niet persoonlijk Qt gebruiken. Er zijn veel goede dingen over te zeggen – namelijk dat de API het grootste deel van de tijd werkt, en dat het naadloos overbrugt tussen platforms. Maar ik gebruik Qt niet, omdat:

1. In sommige gevallen ziet het er gewoon niet uit als native programmas. Het ontwerpen van een enkele gebruikersinterface voor alle platforms zal er inherent niet goed uitzien wanneer deze van machine naar machine wordt verplaatst, om verschillende visuele stylingredenen. Op Mac-machines zijn bijvoorbeeld gesplitste balken meestal relatief dik en zijn knoppen klein en afgerond met pictogrammen. Op Windows-machines zijn gesplitste balken doorgaans smal en zijn knoppen meer tekstueel, met meer vierkante ontwerpen. Het feit dat u één gebruikersinterface voor elk platform kunt schrijven, betekent niet dat u dit voor de meeste toepassingen zou moeten doen.
2. Qt is niet alleen een reeks C ++ -bibliotheken die kunnen worden gekoppeld. Het gebruikte bouwsysteem vereist de vertaling van bepaalde bestanden naar extra bronbestanden, wat het bouwproces veel gecompliceerder maakt in vergelijking met de meeste andere bibliotheken.
3. Als resultaat van (2), C ++ IDEs en tools kan Qt-expressies markeren als fouten, omdat ze de specifieke kenmerken van Qt niet begrijpen. Dit dwingt bijna het gebruik van QtCreator of een tekstuele editor zoals vim.
4. Qt is een grote hoeveelheid broncode, die aanwezig en vooraf geïnstalleerd moet zijn op elke computer die u gebruikt voordat u gaat compileren. Dit kan het opzetten van een build-omgeving veel vervelend maken.
5. Onderdelen zijn meestal gelicentieerd onder de LGPL, waardoor het is moeilijk om single-binary-deployment te gebruiken wanneer men moet uitgeven onder een meer beperkende of minder beperkende licentie.
6. Het produceert extreem grote gecompileerde binaries in vergelijking met op dezelfde manier geschreven " plain ol “native applications " (behalve natuurlijk tien voor KDE).

Reacties

• @Dehumanizer: Er ' is de LGPL-licentie, en er is ' de commerciële licentie. De commerciële licentie is duizenden dollars van de kant van de licentiehouder en staat geen herdistributie toe, enz. Voor open source-projecten onder liberale licenties zoals BSD, MIT of Boost, waar de auteurs ' t veel geld verdienen en ze willen hun code vrijgeven onder een liberale licentie, een afhankelijkheid van LGPL is onredelijk, maar de ontwikkelaars in kwestie kunnen zich over het algemeen geen commerciële licenties veroorloven.
• # 6 is de grootste reden waarom ik het vermijd. Ik bedoel, ik ' wil geen groot, onhandig programma, en ik vind ' niet graag gebonden aan een specifieke licentie, maar het ' is echt het gebrek aan een goede, native look-and-feel die ' een deal-breaker voor mij is.Recente versies van OSX en Windows hebben met name fantastisch werk geleverd door hun native interfaces mooi, snel en functioneel te maken, en ik ' zou liever al het werk gebruiken dat ze ' heb ik al gedaan; Ik vind dat veel programmas zonder een native look goedkoop en hacky aanvoelen (niet altijd, maar ik vind het een beetje raar).
• Je nummer 6 had nummer 1 moeten zijn. Dit is van ver het grootste probleem met Qt. In veel gevallen gebruikt het simpelweg niet de native APIs. Ik vind dat mijn software er native uitziet. Gebruikers vinden dat ook leuk. Ik ' heb nog nooit een Mac-applicatie gezien die gemaakt was met Qt en die eruitzag als een Mac-applicatie. Geen van beiden hebben andere Mac-gebruikers, en zij ' zijn kieskeurig over dat soort dingen. U verliest al het voordeel dat het " platformonafhankelijk " is als u ' opnieuw alleen gebruiken om Linux-applicaties te maken, wat ongeveer de enige plaats is waar het er native uitziet, omdat er echt niets native is.
• behalve het probleem van de ' native ' look is er niet meer. De oude consistentie van Windows-apps is nu een verbastering van wat voor unieke blobs, glows en animaties WPF en Silverlight je ook bieden. Kijk eens naar Office of Windows 7 ' s Configuratiescherm om te zien hoe zelfs het vlaggenschip van MSs tegenwoordig een inconsistente GUI heeft. Mac-gebruikers – nou, je hebt daar een heel geldig punt.
• @TrevorBoydSmith: Sorry, maar je ' vergist je. Qt is het enige framework dat gebruikmaakt van voorverwerking. Periode. Controleer GNOME, FLTK, WX en vrienden en laat me een voorverwerkingsstap zien. Je hebt ' er geen gevonden. Sommige andere bibliotheken worden geleverd met verschillende build-systemen, maar aan het eind van de dag zijn het C ++ -bibliotheken die door elke C ++ -compiler kunnen worden gebouwd. Wat betreft " Raw win32 niet aanwezig in mijn redenen ", het is aanwezig in mijn redenen als # 5 en # 6.

Zoals mensen zeggen, past elke tool bij elk probleem en elke situatie …

Maar als je C ++ programmeur bent, is Qt je raamwerk. Geen rivaal.

We ontwikkelen een complexe commerciële applicatie voor medische beeldvorming, en Qt houdt vol.

Dat zeg ik niet de nadelen die mensen erover zeggen, zijn onjuist, maar ik heb het gevoel dat ze Qt al een hele tijd niet hebben geprobeerd (het wordt voortdurend verbeterd bij elke nieuwe versie …) en meestal alle problemen die ze bespreken zijn geen probleem als je voorzichtig bent.

Inconsistentie van het UI-platform: alleen als je de UI-widgets gebruikt “zoals ze zijn”, zonder aanpassingen of aangepaste kunst.

Qt preprocessor overbelasting : Alleen als je misbruik maakt van het signal-slot-mechanisme, of QObject-overerving, wanneer dat niet echt nodig is.

Overigens schrijven we nog steeds applicaties in C # .NET, en het lange tijd doen. Dus ik denk dat ik een volledig perspectief heb.

Zoals ik al zei, elke tool voor elke situatie,

maar Qt is zonder twijfel een consistent en nuttig raamwerk.

Opmerkingen

• +1 Thaks! Ik wilde gewoon hetzelfde schrijven. De meest onzin is " niet-open source / commercieel argument ". Verbazingwekkend hoeveel mensen de term open source verkeerd begrijpen. Qt was open-source sinds ik het gebruik (1.4). En het had de meest eerlijke licentie: verdien geld met Qt – > betalen.
• Oh, en ik heb echt geen ' t GEEF over het toevoegen van 10 MB DLLs aan een applicatie met 50 MB aan kunst en 200 MB aan videozelfstudies en data 🙂
• De ruimte die nodig is voor Qt is tegenwoordig goedkoop.
• Dit komt vrijwel overeen met mijn ervaring met Qt (het widgets-framework, ik heb tot dusver ' geen QML / QtQuick gebruikt voor iets ernstigs). Het is geschikt om grote applicaties met complexe UI-vereisten te schrijven. Als je het eenmaal hebt geleerd, kun je erg productief zijn. De genoemde nadelen (aparte compilatiestap voor moc ing, ui-bestanden, enz.) Zijn geen probleem als het buildsysteem correct is ingesteld. Ik kan qmake of cmake aanbevelen.
• Vanaf Qt 5.8 daarna is er een project genaamd Qt Lite dat extreem Qt minimaliseert voor uw specifieke behoeften. dit is een commerciële functie;)

Van alle dingen die ik niet leuk vind aan Qt, het feit dat het niet goed speelt met sjablonen stoort me het meest. U kunt dit “niet doen:

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

Het werkt ook niet goed met de preprocessor. U kunt dit “niet doen:

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

Dat, vermengd met het feit dat alles wat op een signaal reageert een Q_OBJECT moet zijn, maakt Qt moeilijk om te werken in voor een C ++ programmeur. Mensen die gewend waren aan programmeren in Java- of Python-stijl, zijn waarschijnlijk beter eigenlijk.

Ik heb eigenlijk veel tijd en moeite gestoken in het onderzoeken en bedenken van een manier om typeveiligheid terug te krijgen en een Qt-signaal te verbinden met een functorobject: http://crazyeddiecpp.blogspot.com/2011/01/quest-for-sane-signals-in-qt-step-1.html

Het soort ding dat ik daar wil doen, is de alledaagse basisontwikkeling van C ++ die vrijwel onmogelijk is gemaakt door de Qt moc … die zelf Tegenwoordig helemaal niet meer nodig, als het ooit echt was.

Eerlijk gezegd blijf ik eraan vast, want als je geautomatiseerde UI-testen wilt doen, is Qt vrijwel het enige spel in de stad na MFC. ..wat zo 1980 is (het is echt rot om in die shit te werken) Sommigen zullen WX zeggen, maar het heeft nog serieuzere problemen. GTKmm zou mijn eerste keuze zijn geweest, maar aangezien het allemaal door de eigenaar is getekend en niet toegankelijk is … kan het niet worden aangestuurd door industriestandaard testsoftware. Qt is in dat opzicht al moeilijk genoeg ( nauwelijks werkt als je de toegankelijkheid plug-in aanpast).

Reacties

• Wat zijn volgens jou de belangrijkste problemen met WX? li>
• @Tom – slechte documentatie, vooral voor de nieuwe dingen. De AUI-componenten zijn nauwelijks gedocumenteerd en er ontbreken grote secties, waardoor het moeilijk te gebruiken is in een productieomgeving. De documentatie voor het evenementproces is fundamenteel fout met betrekking tot het pad dat wordt gevolgd, in ieder geval op win32. Besteed veel tijd aan het schreeuwen tegen de computer, " Dit zou moeten werken !!! " alvorens in de diepgaande verwerkingscode te duiken om erachter te komen dat wat WX doet niet ' is om de documenten te volgen en wat ik aan het doen was, zou NOOIT werken.
• Ik was ook gestoord door de acceptatie van de eigendomsrasterbibliotheek in de hoofdlijn. Ik heb die bibliotheek gebruikt en het vertoonde talrijke, fundamentele ontwerpfouten naast het feitelijke gebrek aan kennis namens de programmeur die het schreef (virtuele functies genoemd in constructors bijvoorbeeld). Het, en de slechte staat AUI, vertoonden een trend naar slechtere normen. Ik ' ben ook geen grote fan van statische gebeurtenistabellen, hoewel er in ieder geval ' een andere manier is om op gebeurtenissen te reageren … in tegenstelling tot MFC, waar WX gewoon te veel op lijkt om sowieso spannend te zijn.
• Bedankt. Ik ' heb het maar een beetje gebruikt, en via de wxPython API, waar het best aardig leek. Ik begrijp dat dat een deel van het kwaad zou verbergen, maar ook dat ik ' niet diep genoeg betrokken ben geraakt om de serieuzere problemen tegen te komen. Iets voor mij om op te letten.
• alles dat op een signaal reageert, moet een Q_OBJECT zijn, tegenwoordig nee … Nu kunnen statische functies, functies en zelfs lambda-functies een signaal beantwoorden (u kunt functiewijzers als slots gebruiken). No-QObject-klassen kunnen ook led-slots hebben als u er verbinding mee maakt met behulp van een std :: bind om het instantie-lid om te zetten in een functie-pointer.

Een reden om Qt niet te gebruiken is dat als je voor slechts één architectuur schrijft, zoals Windows, je misschien C # /. NET (of Cocoa op Mac) wilt gebruiken, omdat dit altijd kunnen profiteren van de nieuwste toeters en bellen van het besturingssysteem.

Als je platformonafhankelijke apps schrijft, ben je misschien al zwaar gebaat bij een andere technologie zoals Java (d.w.z. je werkt in een “Java Shop”). Uw technologiekeuze kan worden bepaald door het ecosysteem waarin u zich ontwikkelt, zoals taalspecifieke APIs. In dit soort gevallen kan het nuttig zijn om het aantal technologieën te minimaliseren.

Een derde reden die ik kan bedenken is dat Qt is gebaseerd op C ++, en C ++ is een relatief moeilijke / gevaarlijke taal om in te programmeren Ik denk dat het een taal is voor professionals. Als je topprestaties nodig hebt en in staat bent om nauwgezet te zijn, dan is C ++ waarschijnlijk nog steeds de beste game in de stad. In feite verlicht Qt veel van de geheugenbeheerproblemen als je dingen instelt om buiten het bereik te vallen. Ook doet Qt zelf goed werk om de gebruiker te isoleren van veel van de vervelende C ++ -problemen. Elke taal en elk raamwerk heeft zijn voor- en nadelen. Het is een heel, heel gecompliceerd probleem dat meestal kan worden samengevat door de toevoeging die vaak wordt gezien bij diners: snelheid, kwaliteit en prijs (maar je kunt er maar twee kiezen).

Hoewel de regels zeggen dat ik me moet houden gericht op het beantwoorden van de vraag, wil ik enkele van de problemen weerleggen die zijn opgeworpen door Billy ONeal, die volgens mij goed werk levert door de vaak genoemde redenen samen te vatten om Qt niet te gebruiken:

1. Qt is inderdaad een C ++ – bibliotheek / framework / header-bestanden. Het wordt aangevuld door een macroprocessor (moc) die onder andere signalen en slots mogelijk maakt. Het transformeert extra macro-opdrachten (zoals Q_OBJECT) zodat klassen introspectie hebben en allerlei andere goodies die je zou kunnen beschouwen als het toevoegen van Objective-C-functionaliteit aan C ++. Als je genoeg weet over C ++ om beledigd te zijn door dit gebrek aan zuiverheid, d.w.z.je bent een professional, dan 1) gebruik Q_OBJECT en zijn soortgelijk niet of 2) wees dankbaar dat het dit doet, en programmeer rond de zeer beperkte gevallen waarin dit een probleem veroorzaakt. Voor mensen die zeggen “Gebruik Boost voor signalen en slots! “, dan zou ik antwoorden dat je het ene” probleem “inruilt voor het andere. Boost is enorm, en het heeft zijn eigen vaak genoemde problemen, zoals slechte documentatie, gruwelijke API en platformonafhankelijke gruwelen (denk aan oude compilers zoals gcc 3.3 en grote ijzeren compilers zoals AIX).

2. Voor editorondersteuning volgt dit ook uit 1, daar ben ik het enigszins mee eens. Eigenlijk is Qt Creator IMHO de beste grafische C ++ -editor, punt uit , zelfs als u de Qt-dingen niet gebruikt. Veel professionele programmeurs gebruiken emacs en vim. Ik denk ook dat Eclipse de extra syntaxis afhandelt. Dus geen problemen met de Qt-macros (Q_OBJECT) of toevoegingen van signalen / slots. U zult deze macros waarschijnlijk niet vinden in Visual Studio, want (ik geef toe) het zijn toevoegingen aan C ++. Maar over het algemeen zullen C # /. NET-mensen “Qt toch niet gebruiken, vanwege het feit dat ze veel van de functionaliteit hebben gedekt door hun eigen gepatenteerde technieken.

3. Wat betreft de grootte van de Qt-bron, als het maar van de ene op de andere dag wordt gecompileerd, wat maakt het uit? Ik heb Qt 4 gecompileerd op mijn dual-core Macbook in “minder dan van de ene op de andere dag”. Ik hoop zeker dat dit niet uw beslissing is. een bepaalde technologie wel of niet gebruiken. Als dit echt een probleem is, kunt u de voorgecompileerde SDKs voor Mac, Linux en Windows downloaden van de Qt-website.

4. Licentieverlening is beschikbaar in drie keuzes: 1) Eigen licentie voor het geval je Qt ZELF wilt wijzigen en niet wilt delen, of het feit wilt verbergen dat iemand Qt gebruikt en niet bereid bent om attributie te geven (kan erg belangrijk zijn voor branding en afbeelding!) 2) GPL en 3) LGPL. Ja, er zijn problemen met statisch linken (alle Qt in het binaire bestand rollen) – maar ik denk dat dat meer is omdat je niet naar binnen kunt gluren en merkt dat je u zing Qt (attributie!). Ik probeerde een eigen licentie van Digia te kopen, en ze vertelden me “voor wat je doet, heb je die echt niet nodig”. Wauw. Van een bedrijf dat zich bezighoudt met het verkopen van licenties.

5. De grootte van het binaire bestand / de bundel is omdat je het Qt-materiaal moet distribueren naar mensen die het niet hebben: Windows heeft het al? de Visual Studio-dingen of je moet de runtime installeren. Mac wordt al geleverd met de enorme cacao en kan dynamisch worden gekoppeld. Hoewel ik niet veel aan distributie doe, heb ik nooit veel problemen ondervonden met het distribueren van het ~ 50 megabyte statische bestand (dat ik nog kleiner kan maken met enkele van de binaire stripper / compressie-hulpprogrammas zoals UPX). zorg genoeg om dit te doen, maar als bandbreedte ooit een probleem zou zijn, zou ik een UPX-stap aan mijn build-script toevoegen.

6. Wat definieert “Native Look and Feel?” Ik denk dat “de meesten” het ermee eens zijn dat Mac het dichtst bij een uniforme look en feel komt. Maar hier zit ik, kijkend naar Safari, iTunes, Aperture, Final Cut Pro, Pages, enz. En ze lijken in niets op elkaar ondanks het feit dat ze zijn gemaakt door de OS-leverancier. Ik denk dat het “gevoel” -aspect relevanter is: widget-styling, reactievermogen, enz. Als je om reactievermogen geeft, dan is hier een goede reden om C ++ te gebruiken in plaats van Java, of een andere zeer dynamische taal. (Objectief C rockt ook, maar ik probeer mythes over Qt te verdrijven)

Samenvattend is het een gecompliceerde kwestie. Maar ik zou erop willen wijzen dat er volgens mij minder redenen zijn om “Qt niet te gebruiken” dan men zou denken op basis van mythen en decennium-verouderde informatie.

Opmerkingen

• Wat ik niet ' snap, is waarom deze platformonafhankelijke bibliotheken ' niet simpelweg functies inpakken , of zelfs beter; if defs rond Cocoa, Win32, KDE / Gnome-functies, waardoor de best uitziende gebruikersinterface wordt gegarandeerd, met alle ' s functies.
• @MarcusJ Een wrapper rondschrijven één toolkit is duidelijk niet triviaal, laat staan 4 of meer – maar als je denkt dat het ' zo gemakkelijk is, ben je ' welkom proberen. Wat betreft het idee dat dit kan worden bereikt door alleen voorwaardelijke voorverwerking te gebruiken … je maakt een grapje, toch?
• @MarcusJ libui is precies dat (hoewel zonder KDE-ondersteuning).
• Ik wil hieraan toevoegen dat je nu Qt / QML kunt gebruiken met .NET. U hoeft niet ' C ++ aan te raken. github.com/qmlnet/qmlnet PS: ik ' m de auteur.

Een deel ervan is licentieverlening. Zie https://en.wikipedia.org/wiki/Qt_(software) #Licensing voor een deel van de licentiegeschiedenis. Tot 2000 gebruikten mensen die veel gaven om open source, Qt niet. Periode. (Dit was in feite de oorspronkelijke motivatie voor de ontwikkeling van Gnome.) Tot 2005 maakten mensen die gratis software voor Windows wilden vrijgeven geen gebruik van Qt.Zelfs na die datum hadden mensen die gratis software wilden onder iets anders dan de GPL, gewoon niet de mogelijkheid om Qt te gebruiken. Dus elk gratis softwareproject dat ouder is dan die datums, kon Qt niet gebruiken. En natuurlijk moesten mensen die propriëtaire code schreven voor het voorrecht betalen.

Verder is het niet alsof er een tekort aan andere opties. Bijvoorbeeld WxWidgets , GTK + en Tk zijn allemaal open source, platformonafhankelijke toolkits.

Bovendien was Windows lange tijd zo dominant op de desktop dat veel software content was om alleen te draaien op Windows. Als je de Microsoft-toolchain installeert, is het gemakkelijker om alleen de eigendomsrechten van Microsoft te gebruiken dan om je zorgen te maken over iets anders, en veel programmeurs deden precies dat.

Opmerkingen

• @btilly: GTK + is platformonafhankelijk. De Pidgin IM-client is bijvoorbeeld geschreven op GTK +.
• Oké, het is echter mogelijk ' ergens ' om op Windows te draaien 🙂
• Installeer GIMP gewoon op Windows en kijk eens.
• Ja, en GIMP werkt goed op Windows, maar het doet het zeker niet ' past niet in de Windows 7 UI-look & gevoel.
• Pidgin is waarschijnlijk een beter voorbeeld van GTK op Windows. Het doet niet ' iets speciaals, maar het past erin en heeft misschien wel 10 jaar of langer?

Ik ben het eens met bijna alle hierboven besproken redenen, maar veel mensen hier hebben gezegd dat ze “Qt niet zouden gebruiken vanwege de extra overhead die het met zich meebrengt. Ik ben het daar niet mee eens daarmee omdat alle meest voorkomende talen (Java, C # en Python) zelf behoorlijk wat overhead met zich meebrengen.

Ten tweede maakt Qt het programmeren met C ++ zo eenvoudig en ongecompliceerd dat het de extra bronnen die het gebruikt. Ik ben nogal wat console-applicaties tegengekomen die zijn geschreven in Qt in plaats van standaard C ++ vanwege het gemak waarmee ze kunnen worden geschreven.

Ik zou zeggen dat de productiviteit van Qt groter is dan die van C / C ++, maar minder dan talen zoals Python.

Reacties

• Ik denk dat het ' allemaal relatief is ten opzichte van de individuele ' s ervaring, omdat ik OK kan coderen in C ++ 14, maar elke keer als ik naar een Qt-code kijk, moet ik hard mijn ogen sluiten om het als dezelfde taal te herkennen … dus ik denk zeker niet ' ' is de unanieme productiviteitsboost die u ' hier suggereert.
• @underscore_d uiteraard als u C ++ heel goed kent en u ' t Qt, je zult niet productiever zijn met de laatste. Maar als je zowel C ++ als Qt leert kennen, maakt het framework een heleboel dingen echt gemakkelijker en sneller te implementeren (C ++ 11, 14 enz. Vullen de leemte op, maar nog niet volledig).

Dit is echt geen poging om een vlammenoorlog te beginnen, ik wilde alleen een aantal punten bespreken.

Waarschijnlijk is de echte reden dat Qt niet meer algemeen wordt gebruikt, dat het C ++ is en dat minder mensen c ++ gebruiken voor desktop-apps.

Qt is geen C ++ -bibliotheek. Het vereist een aparte compilatiestap, wat het bouwproces veel gecompliceerder maakt in vergelijking met de meeste andere bibliotheken.

De vs-addin voor Visual Studio doet dit automatisch, net als Qts eigen opdrachtregelproces. De broncompiler die wordt gebruikt om de dialoogvensters voor MFC te bouwen is ook een aparte stap, maar dat is nog steeds c ++.

Qt is een grote hoeveelheid broncode, die moet aanwezig en vooraf geïnstalleerd zijn op elke computer die je gebruikt voordat je gaat compileren. Dit kan het opzetten van een build-omgeving veel vervelend maken.

Er is een binaire download voor elke versie van visual studio en het bouwen vanaf de bron is een enkele opdracht. Ik zie niet dat de grootte van de SDK-bron tegenwoordig zo een deal is. Visual Studio installeert nu alle C ++ -libs in plaats van u te laten kiezen, met als resultaat dat de installatiegrootte van de compiler> 1Gb is.

It ” s alleen beschikbaar onder LGPL, wat het moeilijk maakt om single-binary-deployment te gebruiken wanneer men moet uitgeven onder een meer beperkende of minder beperkende licentie.

De LGPL is alleen van toepassing op de bibliotheek, het heeft geen invloed op uw code. Ja, het betekent dat je DLLs moet verzenden in plaats van een enkel binair bestand (tenzij je betaalt), maar in een wereld waar je een Java-runtime of een .Net-update moet downloaden voor een klein gebruik, is dit niet zon groot probleem. “is ook minder een probleem op platforms met een enkele ABI, zodat andere Qt-apps de libs kunnen delen.

In sommige gevallen doet het dat gewoon niet” Het ziet eruit als native programmas.Het ontwerpen van een enkele gebruikersinterface voor alle platforms zal er inherent niet goed uitzien wanneer het van machine naar machine wordt verplaatst, om verschillende visuele stijlredenen.

Het wordt verondersteld om native widgets en themas te gebruiken. Ik moet toegeven dat ik voornamelijk technische apps maak, zodat mijn gebruikers zich niet al te veel zorgen maken over stijl. Vooral in Windows betekent de nieuwe mode om alles zelf te laten stylen als een smartphonewidget dat er sowieso steeds minder een standaard is.

Reacties

• Heel wat grote softwarebedrijven bouwen commerciële applicaties in C ++, maar ik ' weet niet dat er heel veel QT gebruiken. Dus hoewel ik begrijp dat niet-C ++ ontwikkelaars QT zouden kunnen vermijden, zijn er andere redenen om QT te vermijden, zelfs als je een C ++ app schrijft, zo lijkt het. In feite is er echt geen ' geen platformonafhankelijke taal en GUI-toolkit waar ik ' geen fout in kan vinden. Het lijkt erop dat platformonafhankelijke ontwikkeling GEWOON DUIDELIJK IS, en dat het goed doen nooit gemakkelijk of gratis is, en dat de belofte die QT doet (schrijf je GUI een keer en gebruik die GUI overal opnieuw) niet ' t genoeg.
• De meeste desktop C ++ software is ofwel in MFC omdat het 20 jaar geleden is gestart of gebruikt een interne toolkit die 20 jaar geleden is gestart om MFC te vermijden (bijv. MS-Office of Autocad). Ik betwijfel of er veel wordt geschreven in C ++ / CLR met WPF. Maar zelfs zonder platformonafhankelijke overwegingen vind ik Qt de beste (of minst slechtste!) Desktop toolkit. Zoals de meeste mensen gaan we op weg naar een webby front-end (mogelijk in QtQuick / QML) en een C ++ server-backend – die waarschijnlijk Qt-signalen / slots zal gebruiken, maar geen gui
• Ik ben het ermee eens. Het minst ergste. En zelfs in apps die alleen Windows gebruiken, ' debug ik liever QT-problemen dan MFC-problemen.
• @WarrenP – ja dat doe ik niet ' zoek het codeproject niet te missen op al het spul dat ontbreekt in MFC. Maar met MSFT ' s nieuw gevonden liefde voor native code – ze hebben ' niet veel gedaan om het schrijven van een GUI gemakkelijker te maken.

De reden is simpel: het heeft geen goede binding met alle reguliere talen, en het is niet magisch altijd geschikt voor de klus.

Gebruik de juiste tool voor de klus. Als ik een eenvoudige opdrachtregeltoepassing aan het schrijven ben, waarom zou ik dat dan zomaar opblazen met Qt?

Als een meer algemeen antwoord (dat ik kan geven omdat ik hier relevant ben ), zullen sommige programmeurs het simpelweg nooit hebben geprobeerd en besloten het te gebruiken. In sommige gevallen is er geen andere reden dan dat de programmeur er nooit een behoefte aan heeft gevonden en ernaar heeft gekeken.

Opmerkingen

• Maar Qt biedt mogelijkheid om alleen console-applicatie te schrijven. Is het niet ' niet?
• @Dehumanizer: ik heb geen idee. Maar waarom zou ik het gebruiken voor een klein hulpprogramma? Welk voordeel zou dat voor mij opleveren als ik de applicatie triviaal kan schrijven in alleen standaard C ++? Het lijkt erop dat je ' opnieuw zoekt naar een reden om een bibliotheek te gebruiken , wat een achterwaartse manier is om te programmeren.
• @Dehumanizer: As Ik zei dat ' een achterwaartse benadering is. Wanneer je een bibliotheek nodig hebt, ' weet je het, en dan kun je er een paar gaan uitproberen en kijken wat het beste bij je past. Een mening proberen te verzamelen over een bibliotheek als je geen ' een use case hebt is een dwaas ' s boodschap.
• " Als ik ' een eenvoudige opdrachtregeltoepassing schrijf, waarom zou ik dat dan opzwellen? met Qt alleen ter wille ervan " is er tenminste één zeer beroemde niet-gui tool geschreven in Qt – Doxygen 🙂
• @Dehumanizer bijvoorbeeld als je te maken hebt met bestanden, xml, unicode, json, regexp, concurency, databases, etc, etc, erg snel en ' niet willen downloaden, adopteren, onderhouden dozijn 3e partijbibliotheken.

Frameworks zoals Qt zijn geschikt als u zich meer zorgen maakt over het uiterlijk van uw product hetzelfde op alle platforms, dan wanneer uw product er op alle platforms goed uitziet. Tegenwoordig gaan dit soort applicaties steeds vaker over op webgebaseerde technologieën.

naar mijn mening is het leren van C ++ programmeren eenvoudiger dan in andere talen te vallen die hun complexiteit verbergen, en de programmeur weet niet wat gebeurt echt op de achtergrond. Qt voegt daarentegen enkele voordelen toe ten opzichte van C ++, om het hoger te maken dan native C ++. Qt C ++ is dus een geweldig raamwerk voor wie taken op een laag niveau of op een hoog niveau op dezelfde manier wil ontwikkelen. C ++ is (volgens sommige praktijken) een complexe en eenvoudige taal. Complex voor wie er niet mee wil uitdagen, simpel voor wie het leuk vindt.Laat het niet los vanwege de complexiteit ervan!

Ik ben het ermee eens dat Qt een mooi raamwerk is om mee te werken. Toch zijn er een aantal problemen die ik ermee heb:

1. Het is geschreven in C ++, wat een zeer lage taal is. Alleen al het feit dat het C ++ is, zal elke Qt-programmeur aanzienlijk minder productief maken in vergelijking met Frameworks die in andere talen zijn geschreven. Mijn belangrijkste probleem met C ++ als GUI-ontwikkeltaal is dat het bijna geen notie heeft van automatisch geheugenbeheer, waardoor het ontwikkelingsproces veel gevoeliger is voor fouten. Het is niet introspectief, wat foutopsporing een stuk moeilijker maakt. De meeste andere grote GUI-toolkits hebben een idee van automatisch geheugenbeheer en introspectie.
2. Elke platformonafhankelijke toolkit lijdt aan het probleem dat het alleen de kleinste gemene deler van alle ondersteunde platforms kan implementeren. Dat, en verschillende UI-richtlijnen op verschillende platforms, stellen de wenselijkheid van platformonafhankelijke GUIs als geheel in vraag.
3. Qt is erg gericht op het coderen van al je gebruikersinterface. Hoewel u QtDesigner kunt gebruiken om bepaalde delen van uw gebruikersinterface te bouwen, ontbreekt het ernstig in vergelijking met bijvoorbeeld (Cocoa / Obj-C) Interface Builder of de .Net-tools.
4. Ook al bevat Qt veel low-level applicatiefunctionaliteit, het is niet te vergelijken met een framework dat met de hand op maat is gemaakt voor een bepaald platform. De native bibliotheken van het besturingssysteem voor zowel Windows als OSX zijn aanzienlijk krachtiger dan de implementaties van Qt. (Denk aan audioframeworks, toegang tot bestandssysteem op laag niveau, enz.)

Dat gezegd hebbende, ik gebruik graag PyQt voor snelle prototyping van applicaties of in-house applicaties. Door Python te gebruiken om alle codering uit te voeren, worden de zorgen met C ++ weggenomen en wordt Qt eigenlijk een zeer aangename plek.

Bewerken, in reactie op enkele opmerkingen:

Toen ik schreef dat Qt in C ++ werd geschreven, klaagde ik niet zozeer over Qt zelf , maar meer over de omgeving waarin het leeft. Het is waar dat Qt zijn eigen bronnen heel goed beheert, maar al uw GUI-gerelateerde-maar-niet-Qt-code moet ook in C ++ worden geschreven. Zelfs daar biedt Qt veel leuke tools, maar uiteindelijk heb je te maken met C ++ op dat niveau. Qt maakt C ++ draaglijk, maar het is nog steeds C ++.

Wat betreft introspectie, wat ik bedoel is dit: de moeilijkste gevallen om te debuggen zijn wanneer je een aanwijzer hebben naar een object dat zich niet gedraagt zoals u denkt dat het zou moeten. Met C ++ kan uw debugger misschien een beetje in dat object kijken (als het toevallig type-informatie op het punt heeft), maar zelfs dat werkt niet altijd. Neem daarentegen cacao in dezelfde situatie. In Cocoa / Obj-C zou je in staat zijn om berichten (“call-functies”) naar een object te sturen in de debugger. U kunt de status van het object wijzigen, u kunt het naar zijn attributen opvragen, u kunt het naar zijn type en zijn functienamen vragen … Dit kan het debuggen een stuk gemakkelijker maken. Qt / C ++ heeft daar zelfs niets in de buurt.

Reacties

• 1. Qt zorgt alleen voor geheugenbeheer, u hoeft ' delete ' niet aan te roepen na elke ' nieuw '. 1a. C ++ is GEEN taal op laag niveau, het is taal op hoog niveau met ' capaciteiten '. 3. Ik ben het ermee eens, maar Qt biedt de mogelijkheid om een gebruikersinterface te maken met QtDesigner en met ' gewone code ' in dezelfde tijd. 4. Ben het nogmaals eens, maar Qt biedt ook het gebruik van native APIs.
• tot jouw punt nr. 1. Ik denk dat c ++ een soort semi-automatisch geheugenbeheer heeft: als je slimme aanwijzers gebruikt zoals std :: auto_ptr of boost :: shared_ptr enz. u hoeft zich over het algemeen geen zorgen te maken over het vrijmaken van geheugen. Dit soort containers kunnen ook worden gemaakt voor andere bronnen (bestanden, systeembronnen die moeten worden vrijgemaakt). Het gebruik van RAII-patroon helpt erg bij geheugenbeheer en naarmate het in je groeit, hoef je je niet echt zorgen te maken over het geheugen.
• " Het feit alleen dat het is C ++ dat elke Qt-programmeur aanzienlijk minder productief zal maken in vergelijking met Frameworks geschreven in andere talen. " [nodig citaat]
• @ SK-logic: hoewel ik denk Ik begrijp alle woorden in uw derde zin, ik heb geen idee wat u zegt. Wat is een " abstractieniveau "? Trouwens, je eerste zin is onjuist, gezien de Wikipedia-definitie van " taal op laag niveau ".
• @ SK-logic: Template metaprogramming is Turing-compleet, en er zijn mensen die slim en deskundig genoeg zijn om hiervan te profiteren. RAII is geen ' een geweldige garbage collection, maar het feit dat het voor alle soorten bronnen werkt, maakt dat min of meer goed.Welnu, wat voor soort abstractie werkt in Java, maar niet in C ++?

De belangrijkste maar niet genoemd ding. In een groot project veroorzaakt één ding zoveel problemen en niet noodzakelijke code. De signaalsleufmechanismen van Qt zijn inefficiënt. Qt-widgets leveren niet de noodzakelijke signalen voor eenvoudige widgets voor gebeurtenissen. U kunt bijvoorbeeld geen signalen instellen voor onHover, onMouseEnter, onMouseLeave, onKeyReleased, onLostFocus, onGainFocus en etc. Zelfs de meest complexe widget zoals QTreeWidget biedt een of twee ultraeenvoudige nutteloze signalen.

Ja, je kunt evenementen gebruiken MAAR !!! je hebt een nieuwe klasse gemaakt voor elke widget met een aangepast evenement. Dit is een enorme verloren efficiëntie;

• Je hebt elke aangepaste widget-objectgebeurtenis herschreven, er zijn kleine wijzigingen.
• Je verliest al het Qt Designer-materiaal. Je moet elke widget promoten met aangepaste evenementen.
• Project werd groter en moeilijker te onderhouden.
• Je begon hierdoor een hekel aan qt te krijgen. En begon te praten over hoe .net afgevaardigden biedt, hoe het veel veel beter is dan signal slot, hoe .net componenten (widgets) biedt over het algemeen elke gebeurtenis die je maar kunt bedenken. En enz.

Een van mijn hogescholen heeft een nieuwe combo box-klasse gemaakt voor elke combo box-widget omdat hij een niet-signaalgebeurtenis moest gebruiken. Waargebeurd verhaal …

Qt is echter tot dusver het beste C ++ UI-framework met downs en ups.

Reacties

• Met betrekking tot evenementen en het aanmaken van nieuwe klassen: je kunt gebeurtenisfilters gebruiken in klassen die erop moeten reageren.
• " Ja, je kunt evenementen gebruiken MAAR !! ! je hebt een nieuwe klasse gemaakt voor elke widget met een aangepast evenement. Dit is een enorm verlies aan efficiëntie; " – NIET PRECIES. Ik eindig gewoon met bool eventFilter dat verschillende widgets afhandelt en vervolgens EventFilter (dit) op alle onderliggende widgets installeert. En dit is niet ' t verlies van efficiëntie en programmeerprestaties! Eigenlijk gebruik ik nooit " Gepromote widgets " … Ik laat gewoon een lege widget vallen, installeer dit als eventFilter erop en implementeer de meeste mijn evenementen binnen mijn belangrijkste cpp-klasse. Probeer het, didn ' t pain 🙂 Je kunt bijna ALLES in Qt aanpassen zonder elke keer nieuwe klassen te maken

Ik hou echt van Qt, maar het is een beetje zwaargewicht voor veel toepassingen. Soms heb je dat niveau van complexiteit gewoon niet nodig. Soms heb je gewoon iets eenvoudigs nodig zonder alle overhead van Qt. Niet elke applicatie hoeft gebeurtenisgestuurd te zijn en C ++ biedt een redelijke set sjablonen. Boost biedt nog een zeer goede set en bevat veel van de low-level functionaliteit (bestand, socket, managed pointers, enz.) Die QT doet.

Andere applicaties hebben licentievereisten die niet goed spelen met GPL , LGPL of Qts commerciële licentie. De GPL is niet geschikt voor commerciële software. De LGPL is ongepast voor statisch gekoppelde software en de commerciële licentie kost geld – iets dat velen niet willen betalen.

Sommigen hebben veiligheids- of stabiliteitsoverwegingen waardoor complexe bibliotheken zoals Qt niet zijn toegestaan.

Je moet moc draaien om je bronnen voor te verwerken. Dat is geen groot probleem, maar het kan ontmoedigend zijn voor de nieuwe gebruiker. Veel programmeurs denken dat je nodig hebt om qmake te gebruiken met Qt, maar dat is een verkeerde benaming. Het is mogelijk om Qt vrij gemakkelijk in andere build-systemen te pluggen.

Sommige doelen zijn erg geheugen of CPU beperkt.

Er zitten enkele platformspecifieke valkuilen in. De meeste van die valstrikken zijn niet gedocumenteerd. Bouw een voldoende grote applicatie en je zult ze tegenkomen en je afvragen wat er aan de hand is (disclaimer, de de laatste keer dat ik Qt in woede gebruikte was meer dan 18 maanden geleden, dus het kan verbeterd zijn).

Het is alleen C ++. Er bestaan andere taalbindingen, maar ze hebben de neiging om veel van de functionaliteit waarvoor je Qt zou willen hebben.

Er zijn veel redenen om Qt niet te gebruiken, daarom zijn er alternatieven. Als je alleen een hamer hebt, ziet elk probleem eruit als een spijker.

Opmerkingen

• " De LGPL is ongepast voor statisch gelinkte [closed source] software " – dat lijkt onjuist te zijn, aangezien LGPL en statisch linken in feite wettelijk mogelijk zijn ( zie ).
• Uw positie lijkt correct. Zie gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic Maar het ' s extra werk en extra dingen verschepen. Kun je ermee wegkomen? Ja. Wil je de moeite nemen? Misschien niet.

De werkelijke reden is niet technisch.

Mensen gebeuren anders zijn. Dus zijn hun keuzes. Uniformiteit is geen menselijk kenmerk.

Reacties

• Loopt daarom alle mensen op hun benen? Nou, degenen die tenminste benen hebben …