Proč není ' t více desktopových aplikací napsaných s Qt? [uzavřeno]

Opravdu to nehodlám považovat za ubíjející odpověď, ale to jsou důvody, proč to dělám osobně nepoužívat Qt. Existuje spousta dobrých věcí, které k tomu můžete říci – konkrétně to, že API funguje většinu času a že bezproblémově překlenuje platformy. Qt však nepoužívám, protože:

1. V některých případech to prostě nevypadá jako nativní programy. Navrhování jediného uživatelského rozhraní pro všechny platformy ze své podstaty nebude vypadat správně při přesunu ze stroje na stroj, a to z různých důvodů vizuálního stylingu. Například na počítačích Mac jsou rozdělené pruhy obvykle relativně silné a tlačítka jsou malá a zaoblená ikonami. Na počítačích s Windows jsou rozdělené pruhy obvykle úzké a tlačítka jsou více textová s více čtvercovými vzory. Jen proto, že můžete napsat jedno uživatelské rozhraní pro každou platformu, neznamená, že byste to měli pro většinu aplikací.
2. Qt není jen propojitelná sada knihoven C ++. Používaný systém sestavení vyžaduje překlad určitých souborů do dalších zdrojových souborů, což ve srovnání s většinou ostatních knihoven činí proces sestavování mnohem komplikovanějším.
3. Výsledkem (2), C ++ IDE a nástrojů může označit výrazy Qt jako chyby, protože nerozumí specifikům Qt. To téměř nutí použití QtCreatoru nebo textového editoru jako vim.
4. Qt je velké množství zdroje, který musí být před kompilací k dispozici a předinstalován na jakémkoli počítači, který používáte. Díky tomu může být nastavení prostředí sestavení mnohem zdlouhavější.
5. Části jsou většinou licencovány v rámci LGPL, což umožňuje je obtížné použít single-binary-deployment, když potřebujete uvolnit pod přísnější nebo méně omezující licencí.
6. Produkuje extrémně velké kompilované binární soubory ve srovnání s podobně napsanými " plain ol „native applications " (kromě zápisu aplikací kurzu deset pro KDE).

Komentáře

• @Dehumanizer: Existuje ' Licence LGPL a ' komerční licence. Komerční licence představuje tisíce dolarů nabyvatele licence a neumožňuje její další distribuci atd. U projektů s otevřeným zdrojovým kódem pod liberálními licencemi, jako jsou BSD, MIT nebo Boost, kde autoři nejsou ' t vydělávající spoustu peněz a chtějí uvolnit svůj kód na základě liberální licence, závislost na LGPL je nepřiměřená, ale dotyční vývojáři si obecně nemohou dovolit komerční licence.
• # 6 je největší důvod, proč se tomu vyhýbám. Myslím tím, že nechci ' chci velký a neohrabaný program a ' se mi nelíbí být vázán na konkrétní licenci, ale ve skutečnosti to ' je nedostatek dobrého a nativního vzhledu, který ' je pro mě lámačem dohod.Nedávné verze OSX a Windows konkrétně odvedly skvělou práci při vytváření jejich nativních rozhraní hezkých, rychlých a funkčních a já ' d spíše využil veškerou práci, kterou ' již jsem pro mě udělal; Zjistil jsem, že mnoho programů bez nativního vzhledu mi připadá levné a hackerské (ne vždy, ale trochu mě to rozladí).
• Vaše číslo 6 mělo být číslo 1. Toto je daleko největší problém s Qt. V mnoha případech jednoduše nepoužívá nativní API. Líbí se mi, když můj software vypadá nativně. Také se to uživatelům líbí. ' Nikdy jsem neviděl aplikaci pro Mac vytvořenou pomocí Qt, která vypadala jako aplikace pro Mac. Žádní další uživatelé počítačů Mac také nemají a ' jsou na takové věci vybíraví. Ztratíte všechny výhody toho, že jste " multiplatformní " pokud ' znovu pouze jej používám k vytváření aplikací pro Linux, což je asi jediné místo, kde vypadá nativně, protože ve skutečnosti nic nativního není.
• kromě problému ' nativního ' vzhled již neexistuje. Stará konzistence aplikací pro Windows je nyní bastardizace všech jedinečných objektů blob, záře a animací, které vám WPF a silverlight umožní. Podívejte se na ovládací panel Office nebo Windows 7 ' s, abyste zjistili, jak i vlajkový produkt MS má v dnešní době nekonzistentní grafické uživatelské rozhraní. Uživatelé počítačů Mac – dobře, máte velmi platný bod.
• @TrevorBoydSmith: Omlouváme se, ale ' se mýlíte. Qt je jediný rámec, který používá předzpracování. Doba. Zkontrolujte GNOME, FLTK, WX a přátele a ukažte mi krok předzpracování. ' žádný nenajdete. Některé další knihovny přicházejí s různými sestavovacími systémy, ale na konci dne jsou to knihovny C ++, které lze sestavit pomocí libovolného kompilátoru C ++. Pokud jde o " surový win32, který z mých důvodů není ", je z mých důvodů přítomen jako # 5 a # 6.

Jak lidé říkají, každý nástroj odpovídá každému problému a situaci …

Ale pokud jste programátor v C ++, Qt je váš rámec. Žádný soupeř.

Vyvíjíme komplexní komerční aplikaci pro lékařské zobrazování a Qt se drží.

Neříkám to „nevýhody“, které o tom lidé říkají, jsou falešné, ale mám pocit, že Qt už dlouho nezkoušeli (neustále se vylepšuje u každé nové verze …) A hlavně všechny problémy, které komentují nejsou problém, pokud se o to postaráte.

Nekonzistence platformy UI: pouze pokud používáte widgety uživatelského rozhraní „tak, jak jsou“, bez přizpůsobení nebo vlastního umění.

Přetížení preprocesoru Qt : Pouze pokud zneužijete mechanismus signál-slot nebo dědičnost QObject, když to opravdu není potřeba.

Mimochodem, stále píšeme aplikace v C # .NET a jsme dělá to dlouho. Takže si myslím, že mám enouchovou perspektivu.

Jak jsem řekl, každý nástroj pro každou situaci,

ale Qt je bezpochyby konzistentní a užitečný rámec.

Komentáře

• +1 Thaks! Jen jsem chtěl psát stejně. Nejvíce nesmysl je " neotevřený zdroj / komerční argument ". Úžasné, jak špatně mnoho lidí rozumí pojmu Open-Source. Qt byl Open-source, protože ho používám (1.4). A dříve to mělo tu nejspravedlivější licenci: vydělávejte peníze s Qt – > platbami.
• Ach, opravdu nedělám ' t PÉČE o přidání 10 MB DLL do aplikace obsahující 50 MB umění a 200 MB více video tutoriálů a dat 🙂
• Prostor potřebný pro Qt je dnes levný.
• To do značné míry odpovídá mým zkušenostem s Qt (rámec widgetů, dosud jsem nepoužil QML / QtQuick pro nic vážného) '. Je vhodné psát velké aplikace se složitými požadavky na uživatelské rozhraní. Jakmile se to naučíte, můžete být velmi produktivní. Zmíněné nevýhody (samostatný krok kompilace pro mocing, soubory ui atd.) Nejsou problémem, pokud je systém sestavení správně nastaven. Mohu doporučit buď qmake, nebo cmake.
• Od Qt 5.8 poté existuje projekt s názvem Qt Lite, který minimalizuje extrémně Qt pro vaše konkrétní potřeby. toto je komerční prvek;)

Ze všech věcí, které se mi na Qt nelíbí, skutečnost, že to se šablonami nehraje dobře, mě trápí nejvíc. Nemůžete to udělat:

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

Také to nefunguje dobře s preprocesorem. Nemůžete to udělat:

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

Díky kombinaci toho, že vše, co reaguje na signál, musí být Q_OBJECT, je Qt obtížné pracovat pro programátora C ++. Lidé zvyklí na programování ve stylu Java nebo Python jsou ve skutečnosti pravděpodobně lepší.

Ve skutečnosti jsem strávil spoustu času a úsilí zkoumáním a vymýšlením způsobu, jak získat zpět bezpečnost typu a připojit signál Qt k libovolnému funktorovému objektu: http://crazyeddiecpp.blogspot.com/2011/01/quest-for-sane-signals-in-qt-step-1.html

To, co tam chci udělat, je základní každodenní vývoj v C ++, který je téměř nemožný díky Qt moc … což je samo o sobě dnes zcela zbytečné, pokud to ve skutečnosti vůbec bylo.

Upřímně řečeno, jsem s tím přilepený, protože pokud chcete provádět automatické testování uživatelského rozhraní, Qt je do značné míry jedinou hrou ve městě bez MFC. ..který je tak v roce 1980 (práce na tom sračce je opravdu těžká). Někdo by mohl říci WX, ale má ještě vážnější problémy. GTKmm by byla moje první volba, ale protože je to všechno nakresleno vlastníkem a nedělá přístupnost … nemůže být řízeno standardním testovacím softwarem. Qt je v tomto ohledu dost těžké ( sotva funguje, když upravíte plugin přístupnosti).

Komentáře

• V zájmu zájmu, v čem vidíte hlavní problémy s WX?
• @Tom – špatná dokumentace, zejména pro nové věci. Součásti AUI jsou stěží zdokumentovány a chybí velké části, takže je obtížné je používat v produkčním prostředí. Dokumentace procesu události je zásadně chybná pokud jde o cestu, po které jde, alespoň na win32. Strávil jsem spoustu času křičením na počítač, " To by mělo fungovat !!! " než se pustím do hlubokého kódu zpracování, abych zjistil, že to, co WX dělá, není ' t sledování dokumentů a to, co dělám, NIKDY nebude fungovat.
• Byl jsem narušeno také přijetím knihovny vlastností do hlavního řádku. Tuto knihovnu jsem použil a kromě skutečných nedostatků znalostí jménem programátora, který ji napsal (ukázal se například jako virtuální funkce v konstruktorech), vykazoval řadu zásadních konstrukčních nedostatků. To a špatný stav AUI vykazovaly tendenci k horším standardům. Také ' m nejsem velkým fanouškem statických tabulek událostí, i když alespoň existuje ' jiný způsob reakce na události … na rozdíl od MFC, které WX stejně tak vzrušuje.
• Díky. Používal jsem to ' jen trochu a to přes API wxPython, kde to vypadalo docela hezky. Mohu ocenit, že by to skrylo něco zlého, ale také to, že jsem se ' nezasáhl dostatečně hluboko, abych narazil na vážnější problémy. Něco, čeho bych si měl být vědom.
• vše, co reaguje na signál, musí být Q_OBJECT, dnes už ne … Nyní mohou statické funkce, funkce a dokonce i funkce lambda reagovat na signál (ukazatele funkcí můžete použít jako sloty). Třídy No-QObject mohou mít také členské sloty, pokud se k nim připojíte pomocí std :: bind k převodu člena instance na ukazatel funkce.

Jedním z důvodů, proč nepoužívat Qt, je to, že pokud píšete pouze pro jednu architekturu, například Windows, možná budete chtít použít C # /. NET (nebo Cocoa na Macu), protože budou vždy mít možnost využívat nejnovější zvonky a píšťalky operačního systému.

Pokud píšete aplikace pro více platforem, možná už vám bude pravděpodobně náležet jiná technologie, jako je Java (tj. pracujete v „Java Shop“). Váš výběr technologie může být diktován ekosystémem, ve kterém vyvíjíte, například API specifická pro jazyk. V těchto případech může být prospěšné minimalizovat počet technologií.

Třetím důvodem, který mě napadá, je to, že Qt je založen na C ++ a C ++ je poměrně obtížný / nebezpečný jazyk pro programování v Myslím, že je to jazyk pro profesionály. Pokud potřebujete mít špičkový výkon a umíte být pečliví, pak je C ++ pravděpodobně stále nejlepší hrou ve městě. Ve skutečnosti Qt zlepšuje mnoho problémů se správou paměti, pokud nastavíte věci tak, aby vypadly z rozsahu. Samotný Qt také odvádí dobrou práci a izoluje uživatele od mnoha nepříjemných problémů s C ++. Každý jazyk a rámec má své klady a zápory. Je to velmi, velmi komplikovaný problém, který lze obvykle shrnout do závislosti, kterou často vidíme u hostů: Rychlost, Kvalita a Cena (ale můžete si vybrat pouze dvě).

Ačkoli pravidla říkají, že bych měl dodržet zaměřený na zodpovězení otázky, chci vyvrátit některé problémy, které nastolil Billy ONeal, který podle mě dělá dobrou práci a shrnuje běžně uváděné důvody nepoužívat Qt:

1. Qt je skutečně C ++ knihovna / framework / hlavičkové soubory. Je rozšířen o makro procesor (moc), který mimo jiné umožňuje signály a sloty. Transformuje další makro příkazy (například Q_OBJECT), takže třídy mají introspekci a všechny druhy dalších dobrot, o kterých si můžete myslet, že přidávají do jazyka C ++ funkce Objective-C. Pokud toho o C ++ víte dost, abyste se urazili tímto nedostatkem čistoty, tj.jste profesionál, pak 1) nepoužívejte Q_OBJECT a podobné nástroje nebo 2) buďte vděční za to, že to dělá, a programujte za velmi omezené rohové případy, kdy to způsobí problém. Pro lidi, kteří říkají „Použít Boost pro signály a sloty! „pak bych odpověděl, že vyměňujete jeden„ problém „za jiný. Boost je obrovský a má své vlastní běžně citované problémy, jako je špatná dokumentace, hrozné API a hrůzy napříč platformami (myslím staré kompilátory jako gcc 3.3 a velké kompilátory železa jako AIX).

2. Pro podporu editoru to také vyplývá z 1, trochu souhlasím. Ve skutečnosti je Qt Creator IMHO nejlepším grafickým editorem C ++, období , i když nepoužíváte věci Qt. Mnoho profesionálních programátorů používá emacs a vim. Také si myslím, že Eclipse zpracovává další syntaxi. Žádné problémy s makry Qt (Q_OBJECT) nebo s přidáváním signálů / slotů. Pravděpodobně nenajdete tato makra v Visual Studio, protože (připouštím) jsou dodatky k C ++. Lidé C # /. NET ale obecně Qt stejně nebudou používat, protože mají spoustu funkcí pokrytých vlastními proprietárními technikami.

3. Pokud jde o velikost zdroje Qt, pokud se kompiluje přes noc, koho to zajímá? Zkompiloval jsem Qt 4 na svém dvoujádrovém Macbooku „méně než přes noc“. Určitě doufám, že to není to, co vede vaše rozhodnutí použijte nebo nepoužívejte konkrétní technologii. Pokud je to skutečně problém, můžete si z webu Qt stáhnout předkompilované sady SDK pro Mac, Linux a Windows.

4. Licencování je k dispozici ve třech možnostech: 1) Proprietární licence pro případ, že byste chtěli upravit Qt SEBE a nesdílejte, nebo skrýt skutečnost, že jeden používá Qt a není ochoten uvádět zdroje (může být pro branding velmi důležité a obrázek!) 2) GPL a 3) LGPL. Ano, existují problémy se statickým propojováním (převáděním celého Qt do binárního souboru) – ale myslím si, že „to je víc, protože člověk nemůže“ nahlédnout dovnitř a všimnout si, že jste u zpívat Qt (atribuce!). Snažil jsem se koupit proprietární licenci od společnosti Digia a oni mi řekli „pro to, co děláte, to opravdu nepotřebujete.“ Páni. Od firmy, která se zabývá prodejem licencí.

5. Velikost binárního souboru / svazku je proto, že musíte distribuovat věci Qt lidem, kteří je nemají: Windows již mají? věci Visual Studio nebo musíte nainstalovat běh. Mac již přichází s enormním kakaem a lze jej dynamicky propojovat. I když nedělám hodně distribuce, nikdy jsem nenašel velký problém s distribucí ~ 50 megabajtového statického souboru (který můžu ještě zmenšit pomocí některých nástrojů pro binární striptér / kompresi, jako je UPX). dostatečně se o to starám, ale pokud by někdy došlo k problému s šířkou pásma, přidal bych do svého sestavovacího skriptu krok UPX.

6. Co definuje „Nativní vzhled a dojem?“ Myslím, že „většina“ by souhlasila s tím, že Mac má nejblíže k jednotnému vzhledu a dojmu. Ale tady sedím a dívám se na Safari, iTunes, Aperture, Final Cut Pro, Stránky atd. A nevypadají vůbec podobně, navzdory skutečnosti, že jsou vyrobeny prodejcem OS. Myslím, že aspekt „cítit“ je důležitější: styl widgetu, odezva atd. Pokud vám záleží na odezvě, pak je dobrý důvod používat spíše C ++ než Javu nebo jiný vysoce dynamický jazyk. (Cíl C také skáčí, ale pokouším se vyvrátit mýty o Qt.)

Stručně řečeno, jde o komplikovaný problém. Rád bych však poukázal na to, že si myslím, že je méně důvodů „nepoužívat Qt“, jak by si člověk mohl myslet na základě mýtů a desetiletých zastaralých informací.

Komentáře

• To, co nedostávám ' proto, že tyto knihovny pro různé platformy nejsou ' jednoduše obalovací funkce nebo ještě lépe; pokud defs kolem funkcí Cocoa, Win32, KDE / Gnome, zajištění nejlépe vypadajícího uživatelského rozhraní se všemi jeho ' s funkcemi.
• @MarcusJ Psaní wrapperu jedna sada nástrojů je zjevně netriviální, nevadí jí 4 a více – ale pokud si myslíte, že je to ' tak snadné, jste ' vítáni zkusit. Pokud jde o myšlenku, že toho lze dosáhnout pouze pomocí podmíněného předzpracování … musíte si dělat srandu, že?
• @MarcusJ libui je přesně to (i když bez podpory KDE).
• Chci dodat, že nyní můžete používat Qt / QML s .NET. ' se nemusíte dotýkat jazyka C ++. github.com/qmlnet/qmlnet PS: Jsem ' autor.

Část z toho je licencování. Část historie licencí viz https://en.wikipedia.org/wiki/Qt_(software) #Licensing . Až do roku 2000 Qt nepoužívali lidé, kterým velmi záleželo na open source. Doba. (To byla ve skutečnosti původní motivace pro vývoj Gnome.) Do roku 2005 lidé, kteří chtěli mít možnost vydávat svobodný software pro Windows, Qt nepoužívali.I po tomto datu lidé, kteří chtěli svobodný software pod jiným než GPL, prostě neměli možnost používat Qt. Jakýkoli projekt svobodného softwaru, který je starší než tato data, tedy nemohl použít Qt. A samozřejmě lidé, kteří píší patentovaný kód, museli za toto privilegium platit.

Dále to není tak, jako kdyby existoval nedostatek dalších možností. Například WxWidgets , GTK + a Tk jsou všechny otevřené sady nástrojů pro více platforem.

Kromě toho byl systém Windows po dlouhou dobu tak dominantní na ploše, že spousta softwaru obsahovala pouze běh v systému Windows. Pokud nainstalujete sadu nástrojů Microsoft, je jednodušší používat vlastní věci společnosti Microsoft, než se starat o cokoli jiného, a to dělalo mnoho programátorů.

Komentáře

• @btilly: GTK + je multiplatformní. Například klient Pidgin IM je napsán na GTK +.
• Dobře, je však možné ' nějak ' běžet na Windows 🙂
• Stačí nainstalovat GIMP na Windows a podívat se.
• Ano, GIMP funguje dobře na Windows, ale určitě to nezapadá do vzhledu uživatelského rozhraní Windows 7 &.
• Pidgin je pravděpodobně lepší příklad GTK ve Windows. Nedělá to ' nic fantazijního, ale zapadá to do toho a má to asi 10 a více let?

Souhlasím s téměř všemi výše zmíněnými důvody, nicméně mnoho lidí zde uvedlo, že nebudou používat Qt kvůli extra režii, kterou přináší. Nesouhlasím s tím proto, že všechny nejběžnější jazyky současnosti (Java, C # a Python) nesou samy o sobě trochu peněz.

Zadruhé, Qt dělá programování v C ++ tak snadným a přímočarým, že nahradí další zdroje, které používá. Narazil jsem na poměrně málo konzolových aplikací napsaných v Qt, spíše než na standardní C ++, protože je snadné je psát.

Řekl bych, že produktivita Qt je vyšší než produktivita C / C ++, ale méně než jazyky jako Python.

Komentáře

• Myslím, že to ' vše souvisí s individuální zkušeností ', protože v C ++ 14 mohu kódovat OK, ale pokaždé, když se podívám na nějaký kód Qt, musím tvrdě přimhouřit, abych ho rozpoznal jako stejný jazyk … takže si to určitě nemyslím ' ' je jednomyslné zvýšení produktivity, které ' zde naznačujete.
• @underscore_d samozřejmě pokud znáte C ++ velmi dobře a neděláte ' t Qt, s tím druhým nebudete produktivnější. Ale když se seznámíte s C ++ i Qt, rámec opravdu dělá spoustu věcí jednodušší a rychlejší implementací (C ++ 11, 14 atd. Vyplňují mezeru, ale ještě ne úplně).

Toto skutečně není pokus o zahájení plamenné války, jen jsem se chtěl věnovat některým bodům.

Pravděpodobným skutečným důvodem, proč Qt není široce používán, je to, že je to C ++ a méně lidí používá c ++ pro desktopové aplikace.

Qt není knihovna C ++. Vyžaduje samostatný krok kompilace, což ve srovnání s většinou ostatních knihoven činí proces sestavení mnohem komplikovanějším.

The vs-addin pro Visual Studio to dělá automaticky, stejně jako vlastní proces vytváření příkazového řádku Qt. Kompilátor prostředků, který se používá k vytváření dialogů pro MFC, je také samostatným krokem, ale stále je to c ++.

Qt je velké množství zdroje, který musí být před kompilací k dispozici a předinstalován na jakémkoli počítači, který používáte. Díky tomu bude nastavení prostředí sestavení mnohem zdlouhavější.

Existuje binární stažení pro každá verze vizuálního studia a sestavení ze zdroje je jediný příkaz. Nevidím velikost zdroje SDK v dnešní době tolik. Visual Studio nyní nainstaluje všechny knihovny C ++, místo aby vám umožnilo vybrat a vybrat, v důsledku toho je velikost instalace kompilátoru> 1 GB.

It “ s k dispozici pouze pod LGPL, což ztěžuje použití single-binary-deployment, když je potřeba vydat pod přísnější nebo méně omezující licencí.

LGPL se vztahuje pouze na lib, neovlivní váš kód. Ano, znamená to, že musíte dodávat dll spíše než jeden binární soubor (pokud neplatíte), ale ve světě, kde si potřebujete stáhnout runtime Java nebo aktualizaci .Net pro malé využití, to není tak velký problém. „Na platformách s jediným ABI to také není problém, takže ostatní aplikace Qt mohou sdílet libs.

V některých případech to prostě nejde“ nevypadají jako nativní programy.Navrhování jediného uživatelského rozhraní pro všechny platformy ze své podstaty nebude vypadat správně, když se přesunete ze stroje na stroj, z různých důvodů vizuálního stylingu.

Má se používat nativní widgety a motivy. Musím přiznat, že dělám většinou technické aplikace, takže moji uživatelé se příliš nezajímají o styl. Zejména v systému Windows nová móda pro to, že se vše přizpůsobuje jako widget pro smartphone, znamená, že standardu je stále méně a méně.

Komentáře

• Spousta velkých softwarových společností vytváří komerční aplikace v C ++, ale já ' nevím o mnoha z nich, které používají QT. I když chápu, že se vývojáři, kteří nepoužívají C ++, mohou QT vyhnout, existují další důvody, proč se QT vyhnout, i když píšete aplikaci v C ++, zdá se. Ve skutečnosti neexistuje žádný ' t žádný jazyk napříč platformami a sada nástrojů GUI, se kterými ' nemůžu najít chybu. Zdá se, že vývoj napříč platformami je JUST PLAIN HARD a že dělat to dobře není nikdy snadné nebo zdarma a že slib, který QT dává (napište své GUI jednou a toto GUI znovu použijte všude) není ' t dost.
• Většina softwaru pro stolní počítače C ++ je buď v MFC, protože to začalo před 20 lety, nebo používá interní sadu nástrojů spuštěnou před 20 lety, aby se zabránilo MFC (např. MS-Office nebo Autocad). Pochybuji, že se hodně píše v C ++ / CLR s WPF. Ale i bez ohledu na různé platformy považuji Qt za nejlepší (nebo nejméně nejhorší!) Sadu nástrojů pro stolní počítače. Jako většina lidí se pohybujeme směrem k front-endu webby (pravděpodobně v QtQuick / QML) a back-end serveru C ++ – který pravděpodobně použije signály / sloty Qt, ale žádné gui
• souhlasím. Alespoň nejhorší. A dokonce i v aplikacích pouze pro Windows ' spíše ladím problémy QT než problémy MFC.
• @WarrenP – ano, ' Nenechte si ujít hledání codeprojectu pro všechny věci, které chybí v MFC. Ale s nově nalezenou láskou k nativnímu kódu MSFT ' – nedělali ' tolik, aby psaní GUI bylo snazší.

Důvod je prostý: nemá dobré vazby na všechny běžné jazyky a není kouzelně vždy vhodné pro danou úlohu.

Použijte vhodný nástroj pro danou úlohu. Pokud píšu jednoduchou aplikaci z příkazového řádku, proč bych to kvůli Qt nafouknul?

Jako obecnější odpověď (kterou mohu dát, protože zde jsem relevantní ), někteří programátoři to prostě nikdy nevyzkoušeli a rozhodli se to použít. V některých případech neexistuje žádný konkrétní důvod kromě toho, že programátor to nikdy nenašel a podíval se na to.

Komentáře

• Ale Qt poskytuje schopnost psát pouze konzolovou aplikaci. Není to '?
• @Dehumanizer: Netuším. Ale proč bych ho používal pro malý nástroj? Jakou výhodu by mi to přineslo, kdybych mohl triviálně napsat aplikaci pouze ve standardním C ++? Zdá se, že ' hledáte důvod k použití knihovny , což je zpáteční cesta k programování.
• @Dehumanizer: As Řekl jsem, že ' je zpětný přístup. Když zjistíte, že potřebujete knihovnu, ' to víte, a pak si můžete jít vyzkoušet několik a zjistit, co vám vyhovuje lépe. Pokoušet se získat názor na knihovnu když nemáte ' nemáte případ použití je hlupák ' s pochůzka.
• " Pokud ' píšu jednoduchou aplikaci z příkazového řádku, proč bych to nafoukla s Qt jen kvůli tomu " je v Qt napsán alespoň jeden velmi slavný nástroj mimo GUI – Doxygen 🙂
• @Dehumanizer když se musíte vypořádat se soubory, xml, unicode, json, regexp, concurency, databázemi atd., atd., velmi rychle a nechcete ' chtít stahovat, adoptovat, udržovat tucet 3. stranické knihovny.

Rámečky jako Qt jsou vhodné, pokud se více zajímáte o to, jak váš produkt vypadá sou stejné na všech platformách než u vašeho produktu, který vypadá správně na všech platformách. V dnešní době se tyto druhy aplikací stále častěji přecházejí na webové technologie.

podle mého názoru je učení programování v C ++ jednodušší než spadnout do jiných jazyků, které skryjí svou složitost, a programátor neví, co opravdu se děje na pozadí. Qt na druhou stranu přidává některé výhody oproti C ++, aby byl na vyšší úrovni než nativní C ++. Qt C ++ je tedy skvělý rámec pro toho, kdo chce stejným způsobem vyvíjet úkoly na nižší nebo vyšší úrovni. C ++ je (podle některých postupů) složitý a jednoduchý jazyk. Komplex pro toho, kdo s ním nechce dělat výzvy, jednoduchý pro toho, komu se to líbí.Nenechávejte to na složitost!

Souhlasím s tím, že Qt je pěkný rámec pro práci. Přesto s ním mám řadu problémů:

1. Je napsán v C ++, což je jazyk opravdu nízké úrovně. Samotná skutečnost, že jde o C ++, způsobí, že každý programátor Qt bude výrazně méně produktivní ve srovnání s rámci napsanými v jiných jazycích. Moje hlavní hovězí maso s C ++ jako vývojovým jazykem GUI je, že nemá téměř žádnou představu o automatické správě paměti, díky čemuž je vývojový proces mnohem náchylnější k chybám. Není introspektivní, což ladění mnohem ztěžuje. Většina ostatních hlavních nástrojů GUI má určitou představu o automatické správě paměti a introspekci.
2. Každá sada nástrojů pro různé platformy trpí problémem, že může implementovat nejméně společného jmenovatele všech podporovaných platforem. To a různé pokyny uživatelského rozhraní na různých platformách velmi zpochybňují vhodnost multiplatformních grafických uživatelských rozhraní jako celku.
3. Qt je do značné míry zaměřen na kódování celého vašeho uživatelského rozhraní. I když můžete použít QtDesigner k sestavení některých částí vašeho uživatelského rozhraní, ve srovnání s např. (Cocoa / Obj-C) Builder rozhraní nebo nástroji .Net vážně chybí.
4. I když Qt obsahuje mnoho funkcí aplikací na nízké úrovni, nemůže se srovnávat s tím, že má rámec ručně přizpůsobený pro určitou platformu. Nativní knihovny operačních systémů pro Windows i OSX jsou podstatně výkonnější než implementace Qt. (Think audio frameworks, low level file system access etc.)

To znamená, že rád používám PyQt pro rychlé prototypování aplikací nebo interní aplikace. Použití Pythonu k provádění veškerého kódování zmírňuje obavy s C ++ a ve skutečnosti dělá Qt velmi příjemným místem.

Upravit, v reakci na některé komentáře:

Když jsem psal o tom, že Qt je napsán v C ++, tolik jsem si nestěžoval na samotný Qt , ale více o prostředí, ve kterém žije. Je pravda, že Qt spravuje své vlastní zdroje velmi dobře, ale veškerý váš kód související s grafickým uživatelským rozhraním, ale nikoli Qt musí být napsán také v C ++. I tam Qt poskytuje mnoho pěkné nástroje, ale nakonec se musíte vypořádat s C ++ na této úrovni. Díky Qt je C ++ snesitelný, ale stále je to C ++.

Co se týče introspekce, myslím tím toto: Nejtěžší případy ladění jsou Když vás mít ukazatel na nějaký objekt, který se nechová tak, jak si myslíte, že by měl. S C ++ by váš debugger mohl trochu nahlédnout do tohoto objektu (pokud by náhodou měl informace o typu v bodě thwt), ale ani to ne vždy funguje. Na druhou stranu si vezměte kakao ve stejné situaci. V Cocoa / Obj-C byste byli schopni posílat zprávy („funkce volání“) na objekt přímo v debuggeru. Můžete změnit stav objektů, můžete jej dotazovat na jeho atributy, můžete se ho zeptat na jeho typ a názvy funkcí … Díky tomu může být ladění mnohem pohodlnější. Qt / C ++ nemá nic podobného.

Komentáře

• 1. Qt se stará o vlastní správu paměti, nemusíte volat ' mazat ' po každém ' new '. 1a. C ++ NENÍ jazyk nízké úrovně, je to jazyk vysoké úrovně s ' schopnostmi '. 3. Souhlasím, ale Qt poskytuje vytvoření uživatelského rozhraní s QtDesigner a ' prostým kódem ' současně. 4. Znovu souhlaste, ale Qt také poskytuje použití nativních API.
• k vašemu bodu č. 1. Myslím, že c ++ má druh poloautomatické správy paměti: pokud používáte inteligentní ukazatele jako std :: auto_ptr nebo boost :: shared_ptr atd., obecně se nemusíte starat o uvolnění paměti. Tyto druhy kontejnerů lze vyrobit i pro jiné zdroje (soubory, systémové prostředky, které je třeba uvolnit). Použití vzoru RAII velmi pomáhá se správou paměti a jak do vás narůstá, s pamětí si opravdu nemusíte dělat starosti.
• " Samotná skutečnost, že je to C ++, díky čemuž bude každý programátor Qt výrazně méně produktivní ve srovnání s Frameworks napsanými v jiných jazycích. Rozumím všem slovům ve vaší třetí větě, vůbec netuším, co říkáte. Co je " úroveň abstrakčního limitu "? Vaše první věta je nepravdivá, vzhledem k definici " nízkoúrovňového jazyka " z Wikipedie.
• @ SK-logic: Metaprogramování šablon je Turingovo úplné a existují lidé, kteří jsou dostatečně chytří a dobře informovaní, aby toho mohli využít. RAII není ' skvělá sbírka odpadků, ale fakt, že funguje pro všechny druhy zdrojů, to víceméně vynahrazuje.Konkrétně, jaký druh abstrakce funguje v Javě, ale ne v C ++?

Nejdůležitější ale neuvedená věc. Ve velkém projektu jedna věc způsobuje tolik problémů a nepotřebného kódu. Mechanismy slotů signálu Qt jsou neúčinné. Widgety Qt neposkytují potřebné signály pro widgety jednoduché události. Nelze například nastavit signály pro onHover, onMouseEnter, onMouseLeave, onKeyReleased, onLostFocus, onGainFocus atd. Dokonce i nejsložitější widget, jako je QTreeWidget poskytuje jeden nebo dva velmi jednoduché zbytečné signály.

Ano, můžete použít události ALE !!! pro každou pomůcku s vlastní událostí jste vytvořili novou třídu. To je obrovská ztráta účinnosti;

• Každou přizpůsobenou událost objektu widgetu jste přepsali, došlo k malým změnám.
• Ztratíte všechny věci Qt Designer. Každý widget musíte propagovat vlastními událostmi.
• Projekt se stal větším a těžko udržovatelným.
• Kvůli tomu se vám začal nelíbit qt. A začal mluvit o tom, jak .net poskytuje delegáty, jak je mnohem mnohem lepší než signální slot, jak .net komponenty (widgety) obecně poskytuje každou událost, kterou si dokážete představit. atd.

Jedna z mých univerzit napsal vytvořenou novou třídu pole se seznamem pro každý widget pole se seznamem, protože musel použít nějakou nesignálovou událost. Skutečný příběh …

Qt je však zatím nejlepším rámcem uživatelského rozhraní C ++ s poklesy a výkyvy.

Komentáře

• Pokud jde o události a vytváření nových tříd: filtry událostí můžete použít ve třídách, které na ně musí reagovat.
• " Ano, události můžete použít, ALE !! ! vytvořili jste novou třídu pro každý widget s vlastní událostí. To je obrovská ztráta účinnosti; " – NEPŘESNĚ. Prostě skončím s bool eventFilter, který zpracovává několik widgetů a poté installEventFilter (this) na všechny podřízené widgety. A to ' ztrácí účinnost a výkon programování! Vlastně nikdy nepoužívám " propagované widgety " … upustím prostý prázdný widget, nainstaluji jej jako eventFilter a znovu implementuji většinu moje události v mé hlavní třídě cpp. Vyzkoušejte to, ' t bolest 🙂 Můžete si přizpůsobit téměř VŠECHNO v Qt bez vytváření nových tříd pokaždé

Qt se mi opravdu líbí, ale pro mnoho aplikací je to trochu těžké. Někdy tuto úroveň složitosti nepotřebujete. Někdy prostě potřebujete něco jednoduchého bez všech režijních nákladů Qt. Ne každá aplikace musí být řízena událostmi a C ++ poskytuje rozumnou sadu šablon. Boost poskytuje další velmi dobrou sadu a obsahuje mnoho funkcí na nízké úrovni (soubor, socket, spravované ukazatele atd.), Které QT dělá.

Jiné aplikace mají licenční požadavky, které s GPL nehrají dobře , Komerční licence LGPL nebo Qt. GPL je nevhodné pro komerční software. LGPL je nevhodný pro staticky propojený software a komerční licence stojí peníze – něco, co mnozí nechtějí platit.

Někteří z bezpečnostních důvodů nebo z hlediska stability neumožňují složité knihovny jako Qt.

Chcete-li své zdroje předem zpracovat, musíte spustit moc. To není velký problém, ale pro nového uživatele to může být skličující. Mnoho programátorů si myslí, že potřebujete použít qmake s Qt, ale to je nesprávné pojmenování. Je možné zapojit Qt do jiných sestavovacích systémů docela snadno.

Některé cíle jsou velmi paměť nebo CPU omezené.

Jsou v něm nějaké platformy specifické pro platformu. Většina z nich je nezdokumentovaná. Vytvořte dostatečně velkou aplikaci a narazíte na ně a budete se divit, o co jde (odmítnutí odpovědnosti, naposledy jsem použil Qt v hněvu před více než 18 měsíci, takže se to mohlo zlepšit).

Je to pouze C ++. Existují i jiné jazykové vazby, ale mají tendenci skrýt nebo špatně vystavit mnoho funkce, pro které byste chtěli Qt.

Existuje mnoho důvodů, proč Qt nepoužívat, proto existují alternativy. Pokud máte jen kladivo, pak bude každý problém vypadat jako hřebík.

Komentáře

• " LGPL je nevhodný pro staticky propojený [uzavřený zdroj] software " – to se zdá být nepřesné, protože ve skutečnosti je LGPL a statické propojení legálně možné ( viz ).
• Vaše pozice se jeví jako správná. Viz gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic Ale je to ' práce navíc a další věci na loď. Dokážete se z toho dostat? Ano. Chcete vynaložit úsilí? Možná ne.

Skutečný důvod není technický.

Lidé se stávají být jiný. Stejně tak jsou jejich volby. Jednotnost není lidským rysem.

Komentáře

• Proto všichni lidé chodí na nohou? No, ti, kdo mají alespoň nohy …