Hvorfor er ' ikke flere skrivebordsprogrammer skrevet med Qt? [lukket]

Jeg har egentlig ikke tenkt at dette skal være et svimlende svar, men det er grunnene jeg gjør ikke personlig bruke Qt. Det er mange gode ting å si om det – nemlig at API-et fungerer mesteparten av tiden, og at det sømløst bygger bro på plattformer. Men jeg bruker ikke Qt, fordi:

1. I noen tilfeller ser det bare ikke ut som innfødte programmer ser ut. Å designe et enkelt brukergrensesnitt for alle plattformer vil i utgangspunktet ikke se riktig ut når det flyttes fra maskin til maskin, av forskjellige visuelle stylingsgrunner. På Mac-maskiner er delte bjelker vanligvis relativt tykke, og knappene er små og avrundet med ikoner. På Windows-maskiner er delt bjelker vanligvis smale, og knappene er mer tekstlige med mer firkantede design. Bare fordi du kan skrive et brukergrensesnitt for hver plattform, betyr ikke det at du burde for de fleste applikasjoner.
2. Qt er ikke bare et koblingsbart sett med C ++ – biblioteker. Byggesystemet som brukes krever oversettelse av visse filer til ekstra kildefiler, noe som gjør byggeprosessen mye mer komplisert sammenlignet med de fleste andre biblioteker.
3. Som et resultat av (2), C ++ IDEer og verktøy kan flagge Qt-uttrykk som feil, fordi de ikke forstår Qts detaljer. Dette tvinger nesten bruk av QtCreator eller en tekstredigerer som vim.
4. Qt er en stor mengde kilde, som må være til stede og forhåndsinstallert på enhver maskin du bruker før du kompilerer. Dette kan gjøre oppsett av et bygningsmiljø mye mer kjedelig.
5. Deler er for det meste lisensiert under LGPL, noe som gjør det er vanskelig å bruke single-binær distribusjon når man trenger å slippe under en mer restriktiv eller mindre restriktiv lisens.
6. Den produserer ekstremt store kompilerte binærfiler sammenlignet med lignende skrevet " ren ol «native applikasjoner " (unntatt selvfølgelig applikasjonsskriv ti for KDE).

Kommentarer

• @Dehumanizer: Det er ' LGPL-lisens, og det ' er den kommersielle lisensen. Den kommersielle lisensen er på tusenvis av dollar fra lisensinnehaverens side, og tillater ikke omfordeling osv. For open source-prosjekter under liberale lisenser som BSD, MIT eller Boost, der forfatterne ikke er ' t tjener massevis av penger, og de ønsker å gi ut koden sin under en liberal lisens, en avhengighet av LGPL er urimelig, men utviklerne i spørsmålet har generelt ikke råd til kommersiell lisensiering.
• # 6 er den største grunnen til at jeg unngår det. Jeg mener, jeg ønsker ikke ' et stort, klumpete program, og jeg liker ikke ' som å være bundet til en bestemt lisens, men det ' er virkelig mangelen på et godt, innfødt utseende som ' er en deal-breaker for meg.Nyere versjoner av OSX og Windows har spesifikt gjort en fantastisk jobb med å gjøre de opprinnelige grensesnittene vakre, raske og funksjonelle, og jeg ' vil heller utnytte alt arbeidet de ' har allerede gjort for meg; Jeg finner ut at mange programmer uten et innfødt utseende føles billig og hacky for meg (ikke alltid, men det forvirrer meg litt).
• Ditt nummer 6 burde ha vært nummer 1. Dette er av langt det største problemet med Qt. I mange tilfeller bruker den rett og slett ikke de innebygde API-ene. Jeg liker at programvaren min ser innfødt ut. Brukere liker det også. Jeg ' har aldri sett et Mac-program opprettet med Qt som så ut som et Mac-program. Det har heller ingen andre Mac-brukere, og de ' er kresne på den slags ting. Du mister hele fordelen med at det er " tverrplattform " hvis du ' bare bruker den til å lage Linux-applikasjoner, som er omtrent det eneste stedet det ser ut som hjemme fordi det egentlig ikke er noe naturlig.
• bortsett fra problemet med ' native ' utseendet er ikke lenger der. Den gamle konsistensen av Windows-apper er nå en bastardisering av hva unike blobs, glød og animasjoner WPF og silverlight lar deg ha. Ta en titt på Office eller Windows 7 ' s Kontrollpanel for å se hvordan selv MSs flaggskipprodukt har inkonsekvent GUI i dag. Mac-brukere – vel, du har veldig gyldige poeng der.
• @TrevorBoydSmith: Beklager, men du ' tar feil. Qt er det eneste rammeverket som bruker forhåndsbehandling. Periode. Sjekk GNOME, FLTK, WX og venner, og vis meg et trinn for forhåndsbehandling. Du vant ' ikke å finne en. Noen andre biblioteker kommer med forskjellige byggesystemer, men på slutten av dagen er de C ++ – biblioteker som kan bygges av en hvilken som helst C ++ – kompilator. Når det gjelder " Raw win32 som ikke er tilstede i mine grunner ", er den til stede i mine grunner som # 5 og # 6.

Som folk sier, passer hvert verktøy til hvert problem og enhver situasjon …

Men hvis du er C ++ programmerer, er Qt ditt rammeverk. Ingen rival.

Vi utvikler en kompleks medisinsk bildebehandling, og Qt holder på.

Jeg sier ikke det «ulempene» som folk sier om det er falske, men jeg har en følelse av at de ikke har prøvd Qt i lang tid (det forbedrer seg kontinuerlig på hver nye versjon …) Og for det meste alle spørsmålene de kommenterer er ikke et problem hvis du tar vare.

UI-plattformens inkonsistens: bare hvis du bruker UI-widgetene «som de er», uten tilpasning eller tilpasset kunst.

Overbelastning av Qt-preprosessor : Bare hvis du misbruker signal-spor-mekanismen, eller QObject-arv, når det ikke er noe behov.

Forresten, vi skriver fortsatt applikasjoner i C # .NET, og har vært gjør det lenge. Så jeg tror jeg har enouch-perspektiv.

Som sagt, hvert verktøy for hver situasjon,

men Qt er uten tvil et konsistent og nyttig rammeverk.

Kommentarer

• +1 Thaks! Jeg ville bare skrive det samme. Det mest tullete er " ikke åpen kildekode / kommersielt argument ". Utrolig, hvor galt mange mennesker forstår begrepet Open Source. Qt var åpen kildekode siden jeg bruker den (1.4). Og det pleide å ha den mest rettferdige lisensen: tjen penger med Qt – > lønn.
• Åh og jeg don virkelig ikke ' t CARE om å legge til 10 MB DLL-filer i applikasjoner som inneholder 50 MB kunst og 200 MB-filer med videoopplæring og data 🙂
• Plassen som trengs for Qt er billig i disse dager. li> Dette stemmer ganske mye med min erfaring med Qt (widgets-rammeverket, jeg har ikke ' t brukt QML / QtQuick for noe seriøst så langt). Det er egnet å skrive store applikasjoner med komplekse UI-krav. Når du har lært det, kan du være veldig produktiv. De nevnte ulempene (separat kompileringstrinn for mocing, ui-filer osv.) Er ikke et problem hvis byggesystemet er riktig konfigurert. Jeg kan anbefale enten qmake eller cmake.
• fra Qt 5.8 etterpå er det et prosjekt som heter Qt Lite som minimerer ekstremt Qt for dine spesifikke behov. dette er en kommersiell funksjon;)

Av alle tingene jeg ikke liker med Qt, det faktum at det ikke spiller bra med maler, bugger meg mest. Du kan ikke gjøre dette:

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

Det spiller heller ikke bra med forprosessoren. Du kan ikke gjø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 som reagerer på et signal, må være et Q_OBJECT, gjør Qt vanskelig å jobbe inn for en C ++ programmerer. Folk som pleide å programmere Java eller Python-stil, var sannsynligvis ganske bedre.

Jeg brukte faktisk mye tid og krefter på å undersøke og utvikle en måte å få type sikkerhet tilbake og koble et Qt-signal til et hvilket som helst funksjonsobjekt: http://crazyeddiecpp.blogspot.com/2011/01/quest-for-sane-signals-in-qt-step-1.html

Den typen ting jeg vil gjøre der er grunnleggende, hverdagslige C ++ – utvikling som nesten er umulig av Qt moc … som i seg selv er helt unødvendig nå dager, hvis det noen gang faktisk var.

Ærlig talt skjønner jeg det, for hvis du vil gjøre automatisert UI-testing, er Qt stort sett det eneste spillet i byen som ikke er MFC. ..som er så 1980 (det suger å jobbe hardt i den dritten). Noen vil kanskje si WX, men det har enda mer alvorlige problemer. GTKmm ville ha vært mitt førstevalg, men siden det er «alle eiere tegnet og ikke gjør tilgjengelighet … kan det ikke drives av industristandard testprogramvare. Qt er vanskelig nok i den forbindelse ( knapt fungerer når du endrer tilgjengelighetsplugin).

Kommentarer

• Av interesse, hva ser du som de viktigste problemene med WX?
• @Tom – dårlig dokumentasjon, spesielt for de nye tingene. AUI-komponentene er knapt dokumentert i det hele tatt med store deler mangler, noe som gjør det vanskelig å bruke i et produksjonsmiljø. Dokumentasjonen for hendelsesprosessen er fundamentalt feil. med hensyn til stien som følges, i det minste på win32. Brukte mye tid på å rope på datamaskinen, " Dette skal fungere !!! " før du går ned i koden for dyp behandling for å finne ut at det WX ikke er ' t å følge dokumentene og hva jeg gjorde, ville ALDRI fungere.
• Jeg var det også forstyrret av aksept av eiendomsnettbiblioteket i hovedlinjen. Jeg brukte dette biblioteket, og det viste mange grunnleggende designfeil i tillegg til faktisk mangel på kunnskap på vegne av programmereren som skrev det (for eksempel kalt virtuelle funksjoner i konstruktører). Den og AUIs dårlige tilstand viste en trend til dårligere standarder. Jeg ' Jeg er heller ikke en stor fan av statiske hendelsestabeller, selv om det i det minste ' er en annen måte å svare på hendelser … i motsetning til MFC, som WX bare er for mye til å være spennende uansett.
• Takk. Jeg ' har bare brukt det litt, og gjennom wxPython API, hvor det virket ganske hyggelig. Jeg kan sette pris på at det ville skjule noe av det onde, men også at jeg bare ikke har ' ikke ble dypt nok involvert i å ha møtt de mer alvorlige problemene. Noe for meg å være klar over.
• Alt som reagerer på et signal må være et Q_OBJECT, Nei i dag … Nå kan statiske funksjoner, funksjoner og til og med lambdafunksjoner svare på et signal (du kan bruke funksjonspekere som spor). No-QObject-klasser kan også ha medlemsautomater hvis du kobler til dem ved hjelp av en std :: bind for å konvertere forekomstmedlem til en funksjonspeker.

En grunn til å ikke bruke Qt er at hvis du bare skriver for en arkitektur, for eksempel Windows, kan det være lurt å bruke C # /. NET (eller Cocoa på Mac) fordi de alltid vil være i stand til å dra nytte av de nyeste bjeller og fløyter i operativsystemet.

Hvis du skriver apper på tvers av plattformer, kan det hende at du allerede er sterkt opptatt av en annen teknologi som Java (dvs. du jobber i en «Java Shop»). Valget av teknologi kan være diktert av økosystemet du utvikler deg i, for eksempel språkspesifikke APIer. I slike tilfeller kan det være gunstig å minimere antall teknologier.

En tredje grunn til at jeg kan tenke meg er at Qt er basert på C ++, og C ++ er et relativt vanskelig / farlig språk å programmere på Jeg tror det er et språk for profesjonelle. Hvis du trenger å ha topp ytelse og er i stand til å være grundig, er C ++ sannsynligvis fortsatt det beste spillet i byen. Egentlig forbedrer Qt mange av minnestyringsproblemene hvis du setter opp ting for å falle utenfor omfanget. Også Qt selv gjør en god jobb med å isolere brukeren fra mange de ekle C ++ -problemene. Hvert språk og rammeverk har sine fordeler og ulemper. Det er en veldig, veldig komplisert sak som vanligvis kan oppsummeres av tillegget som ofte ses hos spisesteder: Hastighet, kvalitet og pris (men du kan bare velge to).

Selv om reglene sier at jeg skal holde fokusert på å svare på spørsmålet, vil jeg motbevise noen av spørsmålene som Billy ONeal har tatt opp, som jeg synes gjør en god jobb med å oppsummere de ofte siterte grunnene til å ikke bruke Qt:

1. Qt er faktisk et C ++ – bibliotek / rammeverk / topptekstfiler. Det er forstørret av en makroprosessor (moc) som muliggjør signaler og spor, blant mange andre ting. Den transformerer ekstra makrokommandoer (for eksempel Q_OBJECT) slik at klasser har introspeksjon og alle slags andre godbiter som du kanskje tenker på som å legge til Objective-C-funksjonalitet til C ++. Hvis du vet nok om C ++ til å bli fornærmet av denne mangelen på renhet, dvs.du er en proff, så 1) ikke bruk Q_OBJECT og dens liknende eller 2) vær takknemlig for at den gjør dette, og programmer rundt de svært begrensede hjørnetilfeller der dette forårsaker et problem. For folk som sier «Bruk Boost for signaler og slots! «så vil jeg svare på at du bytter ut et» problem «mot et annet. Boost er enormt, og det har sine egne ofte siterte problemer som dårlig dokumentasjon, fryktelig API og grusomme plattformer (tenk gamle kompilatorer som gcc 3.3 og store jernkompilatorer som AIX).

2. For redaktørstøtte følger dette også av 1, jeg er enig i det. Egentlig er Qt Creator IMHO den beste grafiske C ++ redaktøren, periode , selv om du ikke bruker Qt-ting. Mange profesjonelle programmerere bruker emacs og vim. Jeg tror også Eclipse håndterer den ekstra syntaksen. Dermed ingen problemer med Qt-makroer (Q_OBJECT) eller signaler / sportillegg. Du vil sannsynligvis ikke finne disse makroene i Visual Studio, fordi (jeg innrømmer) at de er tillegg til C ++. Men stort sett vil ikke C # /. NET-folk bruke Qt uansett, på grunn av det faktum at de har mye av funksjonaliteten dekket med egne proprietære teknikker.

3. Når det gjelder størrelsen på Qt-kilden, så lenge den kompileres over natten, hvem bryr seg? Jeg samlet Qt 4 på min dual core Macbook i «mindre enn over natten.» Jeg håper absolutt ikke dette er det som driver din beslutning om bruke eller ikke bruke en bestemt teknologi. Hvis dette virkelig er et problem, kan du laste ned de forhåndskompilerte SDK-ene for Mac, Linux og Windows fra Qt-nettstedet.

4. Lisensiering er tilgjengelig i tre valg: 1) Proprietær lisens i tilfelle du ønsker å endre Qt SELV og ikke dele, eller skjule det faktum at man bruker Qt og ikke er villig til å gi tilskrivning (kan være veldig viktig for merkevarebygging og bilde!) 2) GPL og 3) LGPL Ja, det er problemer med statisk kobling (rulling av hele Qt i binær) – men jeg tror det er mer fordi man ikke kan titte inn og legge merke til at du er u syng Qt (attribusjon!). Jeg prøvde å kjøpe en proprietær lisens fra Digia, og de fortalte meg «for det du gjør, trenger du virkelig ikke det.» Wow. Fra en bedrift som jobber med å selge lisenser.

5. Størrelsen på binær / pakke er fordi du må distribuere Qt-tingene til folk som ikke har det: Windows har allerede? Visual Studio-ting, eller du må installere kjøretiden. Mac kommer allerede med den enorme kakaoen, og kan kobles dynamisk. Selv om jeg ikke distribuerer mye, har jeg aldri funnet mye problem med å distribuere den statiske filen på ~ 50 megabyte (som jeg kan gjøre enda mindre med noen av de binære strippere / komprimeringsverktøyene som UPX). Jeg bare ikke bryr meg nok om å gjøre dette, men hvis båndbredde noen gang var et problem, vil jeg legge til et UPX-trinn i byggeskriptet.

6. Hva definerer «Innfødt utseende og følelse?» Jeg tror «de fleste» er enige i at Mac kommer nærmest enhetlig utseende. Men her sitter jeg og ser på Safari, iTunes, Aperture, Final Cut Pro, Pages, etc., og de ser ingenting like ut til tross for at de er laget av OS-leverandøren. Jeg tror «føler» -aspektet er mer relevant: widget-styling, responsivitet, etc. Hvis du bryr deg om respons, så er det en god grunn til å bruke C ++ i stedet for Java, eller et annet svært dynamisk språk. (Mål C rokker også, men jeg prøver å fjerne myter om Qt).

Oppsummert er det en komplisert sak. Men jeg vil påpeke at jeg tror det er færre grunner til å «ikke bruke Qt» som man kanskje tror basert på myter og tiårs utdatert informasjon.

Kommentarer

• Det jeg ikke får ', er hvorfor disse plattformbibliotekene ikke er ' t ganske enkelt innpakningsfunksjoner , eller enda bedre; hvis defs rundt Cocoa, Win32, KDE / Gnome fungerer, og sikrer det flotteste brukergrensesnittet, med alt det ' s funksjoner.
• @MarcusJ Skriver en omslag rundt ett verktøysett er tydeligvis ikke trivielt, husk 4 eller flere – men hvis du synes det ' er så enkelt, er du ' velkommen å prøve. Når det gjelder ideen om at dette bare kan oppnås ved bruk av betinget forhåndsbehandling … må du tulle, ikke sant?
• @MarcusJ libui er akkurat det (dog uten KDE-støtte).
• Jeg vil legge til at du nå kan bruke Qt / QML med .NET. Du trenger ikke ' å berøre C ++. github.com/qmlnet/qmlnet PS: Jeg ' m forfatteren.

Noe av det er lisensiering. Se https://en.wikipedia.org/wiki/Qt_(software) #Licensing for noen av lisensieringshistorikken. Fram til 2000 brukte folk som brydde seg sterkt om åpen kildekode, ikke Qt. Periode. (Dette var faktisk den opprinnelige motivasjonen for utviklingen av Gnome.) Fram til 2005 brukte ikke folk som ønsket å kunne gi ut gratis programvare for Windows Qt.Selv etter den datoen hadde ikke folk som ønsket gratis programvare under noe annet enn GPL, muligheten til å bruke Qt. Dermed kunne ikke noe gratis programvareprosjekt som er eldre enn disse datoene, bruke Qt. Og selvfølgelig måtte folk som skrev proprietær kode betale for privilegiet.

Videre er det ikke som om det er en mangel på andre alternativer. For eksempel WxWidgets , GTK + og Tk er alle åpen kildekode, verktøysett på tvers av plattformer.

Videre var Windows lenge så dominerende på skrivebordet at mye programvare var innhold for bare å kjøre på Windows. Hvis du installerer Microsoft-verktøykjeden, er det lettere å bare bruke Microsofts proprietære ting enn å bekymre seg for noe annet, og mange programmerere gjorde nettopp det.

Kommentarer

• @btilly: GTK + er plattform. For eksempel er Pidgin IM-klienten skrevet på GTK +.
• Ok, det er imidlertid mulig ' på en eller annen måte ' for å kjøre på Windows 🙂
• Bare installer GIMP på Windows og se.
• Ja, og GIMP fungerer bra på Windows, men det gjør det absolutt ikke ' passer ikke inn i Windows 7 UI-utseendet &.
• Pidgin er sannsynligvis et bedre eksempel på GTK på Windows. ' t gjør noe fancy, men det passer inn og har kanskje i ti år eller mer?

Jeg er enig med nesten alle årsakene som er diskutert ovenfor, men mange mennesker her har sagt at de ikke vil bruke Qt på grunn av den ekstra kostnaden det fører med seg. Jeg er uenig med det fordi alle de vanligste språkene i dag (Java, C # og Python) bærer seg ganske mye overhead selv.

For det andre gjør Qt programmering med C ++ så enkelt og rett frem at det gjør opp for ekstra ressurser den bruker. Jeg har kommet over ganske mange konsollapplikasjoner skrevet i Qt i stedet for standard C ++ på grunn av den enkle bruken de kan skrives på.

Jeg vil si at produktiviteten til Qt er større enn for C / C ++, men mindre enn språk som Python.

Kommentarer

• Jeg antar at det ' er alt i forhold til den individuelle ' opplevelsen, fordi jeg kan kode OK i C ++ 14, men hver gang jeg ser på en eller annen Qt-kode, må jeg kaste meg hardt for å gjenkjenne det som samme språk … så jeg tror absolutt ikke ' det ' er den enstemmige produktivitetsforsterkeren du ' antyder her.
• @underscore_d åpenbart hvis du kjenner C ++ veldig godt og du ikke ' t Qt, du vil ikke være mer produktiv med sistnevnte. Men når du blir kjent med både C ++ og Qt, gjør rammeverket mange ting enklere og raskere å implementere (C ++ 11, 14 osv. Fyller gapet, men ikke helt ennå).

Dette er virkelig ikke et forsøk på å starte en flammekrig, jeg ville bare ta opp noen av poengene.

Sannsynligvis er den virkelige grunnen til at Qt ikke brukes mer, at det er C ++ og færre bruker c ++ for desktop-apper.

Qt er ikke et C ++ – bibliotek. Det krever et eget kompileringstrinn, noe som gjør byggeprosessen mye mer komplisert sammenlignet med de fleste andre biblioteker.

The vs-addin for visual studio gjør dette automatisk, det samme gjør Qts egen kommandolinjeprosess. Ressurskompilatoren som ble brukt til å lage dialogene for MFC er også et eget trinn, men det er fortsatt c ++.

Qt er en stor mengde kilde, som må være til stede og forhåndsinstallert på hvilken som helst maskin du bruker før du kompilerer. Dette kan gjøre oppsett av et bygningsmiljø mye mer kjedelig.

Det er en binær nedlasting for hver versjon av visual studio og build from source er en enkelt kommando. Jeg ser ikke SDK-kildestørrelse er så mye av en avtale i disse dager. Visual studio installerer nå alle C ++ libs i stedet for å la deg velge og velge, som et resultat er installasjonsstørrelsen på kompilatoren> 1Gb.

It » er bare tilgjengelig under LGPL, noe som gjør det vanskelig å bruke single-binær distribusjon når man trenger å frigjøre under en mer restriktiv eller mindre restriktiv lisens.

LGPL gjelder bare for lib, det påvirker ikke koden din. Ja, det betyr at du må sende DLL-filer i stedet for en enkelt binær (med mindre du betaler), men i en verden der du trenger å laste ned en Java-kjøretid eller en .Net-oppdatering for et lite bruk, er dette ikke så mye. «er også mindre av et problem på plattformer med en enkelt ABI slik at andre Qt-apper kan dele libs.

I noen tilfeller gjør det bare ikke» t ser ut som innfødte programmer ser ut.Å designe en enkelt brukergrensesnitt for alle plattformer vil i utgangspunktet ikke se riktig ut når den flyttes fra maskin til maskin, av forskjellige visuelle stylingsgrunner.

Det antas å bruke native widgets og temaer. Jeg må innrømme at jeg for det meste gjør tekniske apper, slik at brukerne mine ikke er så opptatt av stil. Spesielt på windows betyr den nye moten for å ha alt i seg selv som en smarttelefon-widget at det uansett er mindre og mindre standard.

Kommentarer

• Ganske mange store programvareselskaper bygger kommersielle applikasjoner i C ++, men jeg ' er ikke klar over veldig mange som bruker QT. Så selv om jeg forstår at ikke-C ++ – utviklere kan unngå QT, er det andre grunner til å unngå QT selv når du skriver en C ++ – app, virker det. Det er faktisk ikke ' t noe plattformsspråk og GUI-verktøy som jeg ikke kan ' ikke finne feil på. Det ser ut til at plattformutvikling er BARE PLANHARD, og at det å gjøre det bra er aldri lett eller gratis, og at løftet QT gir (Skriv GUI en gang og bruk den GUI overalt) er ikke ' t nok.
• De fleste stasjonære C ++ -programvarene er enten i MFC fordi den startet for 20 år siden eller bruker en intern verktøysett som ble startet for 20 år siden for å unngå MFC (f.eks. MS-Office eller Autocad). Jeg tviler veldig på at det blir skrevet i C ++ / CLR med WPF. Men selv uten hensyn til plattformen synes jeg Qt er det beste (eller minst verste!) Skrivebordsverktøyet. Som de fleste mennesker beveger vi oss mot en webby-frontend (muligens i QtQuick / QML) og en C ++ server-backend – som sannsynligvis vil bruke Qt-signaler / spor, men ingen gui
• Jeg er enig. Minst verste. Og selv på apper som bare er til Windows, <