Hvorfor er ' ikke flere desktop-apps skrevet med Qt? [lukket]

Jeg har ikke til hensigt at dette skal være et forvirrende svar, men det er grundene til at jeg gør ikke personligt bruge Qt. Der er masser af gode ting at sige om det – nemlig at APIet fungerer det meste af tiden, og at det problemfrit bygger bro på platforme. Men jeg bruger ikke Qt, fordi:

1. I nogle tilfælde ser det bare ikke ud som oprindelige programmer ser ud. At designe en enkelt brugergrænseflade til alle platforme vil i sagens natur ikke se rigtigt ud, når den flyttes fra maskine til maskine, af forskellige visuelle stylingsårsager. På Mac-maskiner er splitstænger normalt relativt tykke, og knapperne er små og afrundede med ikoner. På Windows-maskiner er splitstænger typisk smalle, og knapperne er mere tekstlige med mere firkantede designs. Bare fordi du kan skrive et brugergrænseflade til hver platform, betyder det ikke, at du skal for de fleste applikationer.
2. Qt er ikke kun et link-kompatibelt sæt C ++ – biblioteker. Det anvendte build-system kræver oversættelse af visse filer til ekstra kildefiler, hvilket gør byggeprocessen meget mere kompliceret sammenlignet med de fleste andre biblioteker.
3. Som et resultat af (2), C ++ IDEer og værktøjer kan markere Qt-udtryk som fejl, fordi de ikke forstår Qts specifikationer. Dette tvinger næsten brug af QtCreator eller en tekstredigerer som vim.
4. Qt er en stor mængde kilde, som skal være til stede og forudinstalleret på enhver maskine, du bruger inden kompilering. Dette kan gøre opsætningen af et byggemiljø meget mere kedeligt.
5. Dele er for det meste licenseret under LGPL, hvilket gør det er vanskeligt at bruge single-binær-distribution, når man har brug for at frigive under en mere restriktiv eller mindre restriktiv licens.
6. Det producerer ekstremt store kompilerede binære filer sammenlignet med lignende skrevet " almindelige ol “native applikationer " (undtagen naturligvis applikationsskrivning ti for KDE).

Kommentarer

• @Dehumanizer: Der er ' LGPL-licens, og der ' er den kommercielle licens. Den kommercielle licens er tusindvis af dollars fra licenstagerens side og tillader ikke omfordeling osv. For open source-projekter under liberale licenser som BSD, MIT eller Boost, hvor forfatterne ikke er ' t tjener masser af penge, og de ønsker at frigive deres kode under en liberal licens, en afhængighed af LGPL er urimelig, men de pågældende udviklere har generelt ikke råd til kommerciel licensering.
• # 6 er den største grunden til at jeg undgår det. Jeg mener, jeg vil ikke ' ikke have et stort, klodset program, og jeg kan ikke ' lide at være bundet til en bestemt licens, men det ' er virkelig manglen på et godt, indfødt look-and-feel, som ' er en deal-breaker for mig.Nyere versioner af OSX og Windows har specifikt gjort et fantastisk stykke arbejde med at gøre deres oprindelige grænseflader smukke, hurtige og funktionelle, og jeg ' vil hellere udnytte alt det arbejde, de ' har allerede gjort for mig; Jeg finder ud af, at mange programmer uden et indfødt udseende føles billigt og hacky for mig (ikke altid, men det forvirrer mig lidt).
• Dit nummer 6 skulle have været nummer 1. Dette er ved langt det største problem med Qt. I mange tilfælde bruger den simpelthen ikke de oprindelige APIer. Jeg kan godt lide, at min software ser indfødt ud. Brugere kan også lide det. Jeg ' har aldrig set en Mac-applikation oprettet med Qt, der lignede en Mac-applikation. Der er heller ingen andre Mac-brugere, og de ' er kræsne over den slags ting. Du mister hele fordelen ved, at det er " cross-platform ", hvis du ' bruger det kun til at oprette Linux-applikationer, hvilket er omtrent det eneste sted, det ser indfødt ud, fordi der virkelig ikke er noget native.
• undtagen problemet med ' native ' look er der ikke længere. Den gamle konsistens af Windows-apps er nu en bastardisering af de unikke klatter, glød og animationer, som WPF og silverlight giver dig mulighed for. Se på Office eller Windows 7 ' s Kontrolpanel bare for at se, hvordan selv MSs flagskibsprodukt har inkonsekvent GUI i dag. Mac-brugere – ja, du har meget gyldigt et punkt der.
• @TrevorBoydSmith: Beklager, men du ' tager fejl. Qt er den eneste ramme, der bruger forbehandling. Periode. Tjek GNOME, FLTK, WX og venner, og vis mig et forbehandlingstrin. Du vil ikke finde '. Nogle andre biblioteker kommer med forskellige build-systemer, men i slutningen af dagen er de C ++ -biblioteker, som kan bygges af enhver C ++ -compiler. Hvad angår " Raw win32 ikke er til stede i mine grunde ", det er til stede i mine grunde som nr. 5 og # 6.

Som folk siger, passer hvert værktøj til hvert problem og situation …

Men hvis du er C ++ programmør, er Qt din ramme. Ingen rival.

Vi udvikler en kompleks medicinsk billedbehandling kommerciel applikation, og Qt holder fast.

Det siger jeg ikke de “ulemper”, som folk siger om det, er falske, men jeg har en fornemmelse af, at de ikke har prøvet Qt i lang tid (det forbedres løbende i hver ny version …) Og for det meste alle de spørgsmål, de kommenterer er ikke et problem, hvis du passer på.

UI-platformens inkonsistens: kun hvis du bruger UI-widgets “som de er” uden tilpasning eller brugerdefineret kunst.

Overbelastning af Qt-præprocessor : Kun hvis du misbruger signal-slot-mekanismen eller QObject-arv, når der ikke er noget behov for det.

Forresten, vi skriver stadig applikationer i C # .NET og har været gør det i lang tid. Så jeg tror, jeg har enouch-perspektiv.

Som sagt, hvert værktøj til hver situation,

men Qt er uden tvivl en konsistent og nyttig ramme.

Kommentarer

• +1 Thaks! Jeg ville bare skrive det samme. Det mest vrøvl er " ikke-open source / kommercielt argument ". Forbløffende, hvor forkert mange mennesker forstår udtrykket Open Source. Qt var Open source, da jeg bruger det (1.4). Og det plejede at have den mest retfærdige licens: tjen penge med Qt – > løn.
• Åh og jeg don virkelig ikke ' t PAS på at tilføje 10 MB DLLer til applikationer, der indeholder 50 MB kunst og 200 MB mere videotutorials og data 🙂
• Den nødvendige plads til Qt er billig i disse dage.
• Dette svarer stort set til min erfaring med Qt (widgets-rammen, jeg har ikke ' t brugt QML / QtQuick til noget seriøst indtil videre). Det er velegnet til at skrive store applikationer med komplekse UI-krav. Når du først har lært det, kan du være meget produktiv. De nævnte ulemper (separat kompileringstrin til moc ing, ui-filer osv.) Er ikke et problem, hvis build-systemet er korrekt konfigureret. Jeg kan anbefale enten qmake eller cmake.
• fra Qt 5.8 bagefter er der et projekt ved navn Qt Lite, der minimerer ekstremt Qt til dine specifikke behov. dette er en kommerciel funktion;)

Af alle de ting, jeg ikke kan lide ved Qt, det faktum, at det ikke spiller godt med skabeloner, bugter mig mest. Du kan ikke gøre dette:

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

Det spiller heller ikke godt med forprocessoren. Du kan ikke gøre dette:

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

Det blandet med det faktum, at alt, hvad der reagerer på et signal, skal være et Q_OBJECT, gør Qt svært at arbejde ind for en C ++ programmerer. Folk, der plejede at programmere Java eller Python-stil, er sandsynligvis ret bedre faktisk.

Jeg brugte faktisk en masse tid og kræfter på at undersøge og udtænke en måde at få typesikkerhed tilbage og forbinde et Qt-signal til ethvert funktionsobjekt: http://crazyeddiecpp.blogspot.com/2011/01/quest-for-sane-signals-in-qt-step-1.html

Den slags ting, jeg vil gøre der, er en grundlæggende, dagligdags C ++ – udvikling, der næsten er umulig af Qt moc … som i sig selv er helt unødvendige nu dage, hvis det nogensinde faktisk var.

Helt ærligt er jeg dog fast med det, for hvis du vil lave automatiseret UI-test, er Qt stort set det eneste spil i byen, der ikke er MFC. ..som er så 1980 (det suger at arbejde med den lort virkelig hårdt). Nogle siger måske WX, men det har endnu mere alvorlige problemer. GTKmm ville have været mit første valg, men da det er “alle ejere trukket og ikke gør tilgængelighed … kan det ikke drives af industristandard testsoftware. Qt er hårdt nok i den henseende ( knap fungerer, når du ændrer tilgængelighedspluginet).

Kommentarer

• Hvad er det af interesse, hvad ser du som de største problemer med WX?
• @Tom – dårlig dokumentation, især for de nye ting. AUI-komponenterne er næppe dokumenteret med store sektioner mangler, hvilket gør det vanskeligt at bruge i et produktionsmiljø. Dokumentationen til begivenhedsprocessen er grundlæggende fejlagtig med hensyn til den sti, der følges, i det mindste på win32. Brugte meget tid på at råbe på computeren, " Dette burde fungere !!! " inden du går ned i den dybe bearbejdningskode for at finde ud af, at hvad WX gør, ikke ' ikke følger dokumenterne, og hvad jeg lavede, ville ALDRIG fungere.
• Jeg var også forstyrret af accept af ejendomsgitterbiblioteket i hovedlinjen. Jeg brugte dette bibliotek, og det viste adskillige grundlæggende designfejl ud over faktisk manglende viden på vegne af programmøren, der skrev det (f.eks. Kaldet virtuelle funktioner i konstruktører). Det og AUIs dårlige tilstand viste en tendens til dårligere standarder. Jeg ' er heller ikke en stor fan af statiske hændelsestabeller, selvom der i det mindste ' er en anden måde at svare på begivenheder … i modsætning til MFC, hvilken WX bare er for meget til at være spændende alligevel.
• Tak. Jeg ' har kun brugt det lidt og gennem wxPython API, hvor det virkede ganske rart. Jeg kan forstå, at det ville skjule noget af det onde, men også at jeg bare ikke har ' Jeg blev dybt nok involveret i at have været imod de mere alvorlige problemer. Noget for mig at være opmærksom på.
• Alt, hvad der reagerer på et signal, skal være et Q_OBJECT, Nej i dag … Nu kan statiske funktioner, funktioner og endda lambda-funktioner svare på et signal (du kan bruge funktionsmarkører som slots). No-QObject-klasser kan også have medlems slots, hvis du opretter forbindelse til dem ved hjælp af en std :: bind for at konvertere instansmedlem til en funktionsmarkør.

En af grundene til ikke at bruge Qt er, at hvis du kun skriver til en arkitektur, f.eks. Windows, vil du muligvis bruge C # /. NET (eller kakao på Mac), fordi de altid vil være i stand til at drage fordel af de nyeste klokker og fløjter i operativsystemet.

Hvis du skriver apps på tværs af platforme, er du muligvis allerede stærkt knyttet til en anden teknologi som Java (dvs. du arbejder i en “Java Shop”). Dit valg af teknologi dikteres muligvis af det økosystem, du udvikler dig i, såsom sprogspecifikke APIer. I denne slags tilfælde kan det være en fordel at minimere antallet af teknologier.

En tredje grund, som jeg kan tænke på, er at Qt er baseret på C ++, og C ++ er et forholdsvis vanskeligt / farligt sprog at programmere på Jeg synes, det er et sprog for professionelle. Hvis du har brug for at have top ydeevne og er i stand til at være omhyggelig, så er C ++ sandsynligvis stadig det bedste spil i byen. Faktisk forbedrer Qt mange hukommelsesadministrationsproblemer, hvis du indstiller tingene til at falde uden for anvendelsesområdet. Qt selv gør også et godt stykke arbejde med at isolere brugeren fra mange af de grimme C ++ – problemer. Hvert sprog og ramme har sine fordele og ulemper. Det er et meget, meget kompliceret emne, der normalt kan opsummeres af den tilføjelse, der ofte ses hos spisesteder: Hastighed, kvalitet og pris (men du kan kun vælge to).

Selvom reglerne siger, at jeg skal holde fokuseret på at besvare spørgsmålet, vil jeg afvise nogle af de spørgsmål, der er rejst af Billy ONeal, som jeg synes gør et godt stykke arbejde sammenfattende de almindeligt citerede grunde til ikke at bruge Qt:

1. Qt er faktisk et C ++ – bibliotek / framework / header-filer. Det er forstærket af en makroprocessor (moc), der muliggør signaler og slots blandt mange andre ting. Det transformerer yderligere makrokommandoer (såsom Q_OBJECT), så klasser har introspektion og alle mulige andre godbidder, som du måske tænker på som at tilføje Objective-C-funktionalitet til C ++. Hvis du ved nok om C ++ til at blive fornærmet af denne mangel på renhed, dvs.du er en professionel, så 1) brug ikke Q_OBJECT og dens lignende eller 2) vær taknemmelig for, at det gør dette, og programmer rundt i de meget begrænsede hjørnesager, hvor dette forårsager et problem. For folk, der siger “Brug Boost til signaler og slots! “så svarer jeg, at du udveksler et” problem “til et andet. Boost er enormt, og det har sine egne almindeligt citerede problemer som dårlig dokumentation, forfærdelige API og rædsler på tværs af platforme (tænk gamle kompilatorer som gcc 3.3 og store jernkompilatorer som AIX).

2. For redaktørsupport følger dette også af 1, jeg er enig i det. Faktisk er Qt Creator IMHO den bedste grafiske C ++ editor, periode , selvom du ikke bruger Qt-tingene. Mange professionelle programmører bruger emacs og vim. Jeg tror også, at Eclipse håndterer den ekstra syntaks. Således ingen problemer med Qt-makroer (Q_OBJECT) eller tilføjelser af signaler / slots. Du vil sandsynligvis ikke finde disse makroer i Visual Studio, fordi (jeg indrømmer) at de er tilføjelser til C ++. Men stort set vil C # /. NET-folk ikke bruge Qt alligevel på grund af det faktum, at de har meget af funktionaliteten dækket af deres egne beskyttede teknikker.

3. Hvad angår størrelsen på Qt-kilden, så længe den kompileres natten over, hvem er det ligegyldigt? Jeg kompilerede Qt 4 på min dual core Macbook i “mindre end natten over.” Jeg håber bestemt ikke, det er det, der driver din beslutning til bruge eller ikke bruge en bestemt teknologi. Hvis dette virkelig er et problem, kan du downloade de forud kompilerede SDKer til Mac, Linux og Windows fra Qt-webstedet.

4. Licensering er tilgængelig i tre valg: 1) Proprietær licens, hvis du ønsker at ændre Qt ITSELF og ikke dele, eller skjule det faktum, at man bruger Qt og ikke er villig til at give tilskrivning (kan være meget vigtigt for branding og billede!) 2) GPL og 3) LGPL.Ja, der er problemer med statisk sammenkædning (rullende hele Qt i binær) – men jeg tror, det er mere, fordi man ikke kan kigge ind og bemærke, at du er u syng Qt (tilskrivning!). Jeg forsøgte at købe en licens fra Digia, og de fortalte mig “for hvad du laver, har du virkelig ikke brug for det.” Wow. Fra en virksomhed, der er i færd med at sælge licenser.

5. Størrelsen på binær / bundtet skyldes, at du er nødt til at distribuere Qt-tingene til folk, der ikke har det: Windows har allerede? Visual Studio-tingene, eller du skal installere kørselstiden. Mac kommer allerede med den enorme kakao og kan være dynamisk forbundet. Selvom jeg ikke distribuerer meget, har jeg aldrig fundet meget problem med at distribuere den statiske fil på ~ 50 megabyte (som jeg kan gøre endnu mindre med nogle af de binære stripper / komprimeringsværktøjer som UPX). Jeg ved bare ikke pleje nok til at gøre dette, men hvis båndbredde nogensinde var et problem, ville jeg tilføje et UPX-trin til mit build-script.

6. Hvad definerer “Native Look and Feel?” Jeg tror “de fleste” er enige i, at Mac kommer tættest på et samlet udseende. Men her sidder jeg og ser på Safari, iTunes, Aperture, Final Cut Pro, Pages osv., Og de ser ikke ens ud på trods af at de er lavet af OS-leverandøren. Jeg synes, at “føler” -aspektet er mere relevant: widget-styling, lydhørhed osv. Hvis du er interesseret i lydhørhed, er her en god grund til at bruge C ++ i stedet for Java eller et andet meget dynamisk sprog. (Mål C rokker også, men jeg prøver at fjerne myter om Qt)

Sammenfattende er det et kompliceret emne. Men jeg vil gerne påpege, at jeg mener, at der er færre grunde til at “ikke bruge Qt”, som man måske tror baseret på myter og årti-forældede oplysninger.

Kommentarer

• Det, jeg ikke får ', er, hvorfor disse tværplatformsbiblioteker ikke er ' t simpelthen wrapper-funktioner , eller endnu bedre; hvis defs omkring Cocoa, Win32, KDE / Gnome fungerer, hvilket sikrer den bedst mulige brugergrænseflade med alt det ' s funktioner.
• @MarcusJ Skriver en indpakning rundt et værktøjssæt er tydeligt ikke-trivielt, ligegyldigt 4 eller mere – men hvis du synes det ' er så let, er du ' velkommen prøve. Hvad angår ideen om, at dette kun kunne opnås ved hjælp af kun betinget forbehandling … skal du sjov, ikke?
• @MarcusJ libui er netop det (dog uden KDE-understøttelse).
• Jeg vil tilføje, at du nu kan bruge Qt / QML med .NET. Du behøver ikke ' at røre ved C ++. github.com/qmlnet/qmlnet PS: Jeg ' m forfatteren.

Noget af det er licens. Se https://en.wikipedia.org/wiki/Qt_(software) #Licensing for nogle af licenshistorikken. Indtil 2000 brugte folk, der bekymrede sig stærkt om open source, ikke Qt. Periode. (Dette var faktisk den oprindelige motivation for udviklingen af Gnome.) Indtil 2005 brugte folk, der ønskede at være i stand til at frigive gratis software til Windows, ikke Qt.Selv efter denne dato havde folk, der ønskede gratis software under noget andet end GPL, simpelthen ikke mulighed for at bruge Qt. Ethvert gratis softwareprojekt, der er ældre end disse datoer, kunne ikke bruge Qt. Og selvfølgelig måtte folk, der skrev proprietær kode, betale for privilegiet.

Desuden er det ikke som om der er en mangel på andre muligheder. F.eks. WxWidgets , GTK + og Tk er alle open source, værktøjssæt på tværs af platforme.

Desuden var Windows i lang tid så dominerende på skrivebordet, at meget software var indhold til kun at køre på Windows. Hvis du installerer Microsoft værktøjskæde, er det nemmere bare at bruge Microsofts proprietære ting, end det er at bekymre sig om noget andet, og mange programmerere gjorde netop det.

Kommentarer

• @btilly: GTK + er platform. For eksempel er Pidgin IM-klienten skrevet på GTK +.
• Ok, det er dog muligt ' på en eller anden måde ' at køre på Windows 🙂
• Installer bare GIMP på Windows og se.
• Ja, og GIMP fungerer godt på Windows, men det