Închis . Această întrebare este
bazată pe opinie . În prezent, nu acceptă răspunsuri.
Comentarii
Răspuns
Nu intenționez cu adevărat să fie un răspuns bashing, dar acestea sunt motivele pentru care fac nu utilizați personal Qt. Există o mulțime de lucruri bune de spus despre asta – și anume că API-ul funcționează de cele mai multe ori și că folosește platforme fără probleme. Dar eu nu folosesc Qt, deoarece:
- În unele cazuri, nu arată doar ca programele native. Proiectarea unei singure UI pentru toate platformele în mod inerent nu va arăta corect atunci când este mutată de la mașină la mașină, din diverse motive de stil vizual. De exemplu, pe mașinile Mac, barele împărțite sunt de obicei relativ groase, iar butoanele sunt mici și rotunjite cu pictograme. Pe mașinile Windows, barele împărțite sunt de obicei înguste, iar butoanele sunt mai textuale, cu modele mai pătrate. Doar pentru că puteți scrie o interfață de utilizare pentru fiecare platformă nu înseamnă că ar trebui să faceți acest lucru pentru majoritatea aplicațiilor.
- Qt nu este doar un set de biblioteci C ++ care poate fi conectat. Sistemul de construire utilizat necesită traducerea anumitor fișiere în fișiere sursă suplimentare, ceea ce face procesul de compilare mult mai complicat în comparație cu majoritatea celorlalte biblioteci.
- Ca rezultat al (2), ID-urilor și instrumentelor C ++ poate semnaliza expresiile Qt ca erori, deoarece nu înțeleg specificul Qt. Acest lucru aproape forțează utilizarea QtCreator sau a unui editor numai textual ca
vim.
- Qt este o cantitate mare de sursă, care trebuie să fie prezentă și preinstalată pe orice mașină pe care o utilizați înainte de compilare. Acest lucru poate face ca instalarea unui mediu de construcție să fie mult mai plictisitoare.
- Piesele sunt în mare parte licențiate în baza LGPL, ceea ce face ca este dificil să se utilizeze implementarea binară unică atunci când este nevoie să se lanseze sub o licență mai restrictivă sau mai puțin restrictivă.
- Produce binare compilate extrem de mari în comparație cu " simplu ol „aplicații native " (cu excepția, desigur, a aplicațiilor scrise zece pentru KDE).
Comentarii
Răspuns
După cum spun oamenii, fiecare instrument se potrivește fiecărei probleme și situații …
Dar dacă ești programator C ++, Qt este cadrul tău. Nici un rival.
Dezvoltăm o aplicație comercială complexă de imagistică medicală și Qt se menține.
Nu spun asta „dezavantajele” pe care oamenii le spun despre asta sunt false, dar am senzația că nu au încercat Qt de mult timp (se îmbunătățește continuu la fiecare nouă versiune …) Și, mai ales toate problemele pe care le comentează nu sunt o problemă dacă aveți grijă.
Inconsistența platformei UI: numai dacă utilizați widgeturile UI „așa cum sunt”, fără personalizare sau artă personalizată.
Supraîncărcarea preprocesatorului Qt : Numai dacă abuzați de mecanismul slotului de semnal sau de moștenirea QObject, atunci când nu este cu adevărat nevoie.
Apropo, încă scriem aplicații în C # .NET și am fost făcând-o mult timp. Deci, cred că am o perspectivă amplă.
După cum am spus, fiecare instrument pentru fiecare situație,
dar Qt este, fără îndoială, un cadru consecvent și util.
Comentarii
Răspuns
Dintre toate lucrurile care nu-mi plac la Qt, faptul că nu se joacă bine cu șabloanele mă blochează cel mai mult. Nu puteți face acest lucru:
template < typename T > struct templated_widget : QWidget { Q_OBJECT; public signals: void something_happened(T); };
De asemenea, nu se joacă bine cu preprocesorul. Nu puteți face acest lucru:
#define CREATE_WIDGET(name,type) \ struct name ## _widget : QWidget \ { \ Q_OBJECT; \ \ public signals: \ void something_happened(type); \ }
Asta, amestecat cu faptul că tot ceea ce răspunde la un semnal trebuie să fie Q_OBJECT, face ca Qt să fie greu de funcționat pentru un programator C ++. Oamenii obișnuiți cu programarea în stil Java sau Python probabil că sunt mai bine.
De fapt, am petrecut mult timp și efort cercetând și concepând o modalitate de a câștiga înapoi siguranța tipului și de a conecta un semnal Qt la orice obiect funcțional: http://crazyeddiecpp.blogspot.com/2011/01/quest-for-sane-signals-in-qt-step-1.html
Genul de lucru pe care vreau să-l fac acolo este dezvoltarea C ++ de zi cu zi, făcută aproape imposibilă de Qt moc … care în sine este cu totul inutil acum zilele, dacă a fost vreodată.
Sincer, totuși, am rămas cu el pentru că, dacă doriți să faceți teste automate ale interfeței de utilizare, Qt este aproape singurul joc din oraș în afara MFC. .. care este atât de 1980 (e de rau să lucrezi în rahatul ăsta foarte tare). Unii ar putea spune WX, dar are probleme și mai grave. GTKmm ar fi fost prima mea alegere, dar din moment ce este realizat de proprietar și nu face accesibilitate … nu poate fi condus de software-ul de testare standard din industrie. Qt este suficient de greu în această privință ( abia funcționează când modificați pluginul de accesibilitate).
Comentarii
Răspuns
Un motiv pentru a nu utiliza Qt este că, dacă scrieți doar pentru o singură arhitectură, cum ar fi Windows, vă recomandăm să utilizați C # /. NET (sau Cocoa pe Mac), deoarece vor invariabil să puteți profita de cele mai recente clopote și fluiere ale sistemului de operare.
Dacă scrieți aplicații pe mai multe platforme, este posibil să fiți deja învestit într-o altă tehnologie, cum ar fi Java (adică lucrați într-un „magazin Java”). Alegerea tehnologiei dvs. poate fi dictată de ecosistemul în care vă dezvoltați, cum ar fi API-urile specifice limbajului. În aceste tipuri de cazuri, minimizarea numărului de tehnologii poate fi benefică.
Un al treilea motiv la care mă pot gândi este că Qt se bazează în jurul C ++, iar C ++ este un limbaj relativ dificil / periculos de programat în Cred că este un limbaj pentru profesioniști. Dacă aveți nevoie de performanțe de vârf și sunteți capabil să fie meticulos, atunci C ++ este probabil cel mai bun joc din oraș. De fapt, Qt ameliorează o mulțime de probleme de gestionare a memoriei dacă setați lucrurile să cadă din sfera de aplicare. De asemenea, Qt în sine face o treabă bună izolând utilizatorul de o mulțime de probleme urâte de C ++. Fiecare limbă și cadru are argumentele pro și contra. Este o problemă foarte, foarte complicată, care, de obicei, poate fi rezumată prin adăugarea frecvent întâlnită la clienți: Viteză, calitate și preț (dar puteți alege doar două).
Deși regulile spun că ar trebui să păstrez concentrat pe răspunsul la întrebare, vreau să resping unele dintre problemele ridicate de Billy ONeal, care cred că face o treabă bună rezumând motivele frecvent citate pentru a nu utiliza Qt:
-
Qt este într-adevăr o bibliotecă / cadru / fișiere antet C ++. Este mărit de un procesor macro (moc) care permite semnale și sloturi, printre multe alte lucruri. Transformă comenzi macro suplimentare (cum ar fi Q_OBJECT) astfel încât clasele să aibă introspecție și tot felul de alte bunătăți la care s-ar putea crede că adaugă funcționalitate Objective-C la C ++. Dacă știi suficient despre C ++ să fii jignit de această lipsă de puritate, adicăsunteți un profesionist, atunci 1) nu folosiți Q_OBJECT și altele sau 2) fiți recunoscător că face acest lucru și programați în jurul valorii de cazuri foarte limitate în care acest lucru cauzează o problemă. Pentru persoanele care spun „Utilizați Boost pentru semnale și sloturi! „, aș răspunde că schimbați o„ problemă ”cu alta. Boost este uriaș și are propriile sale probleme citate, cum ar fi documentația slabă, API-ul oribil și ororile pe mai multe platforme (gândiți-vă la compilatoare vechi precum gcc 3.3 și mari compilatoare de fier precum AIX).
-
Pentru asistență pentru editor, acest lucru rezultă și din 1, sunt oarecum de acord. De fapt, Qt Creator este IMHO cel mai bun editor grafic C ++, perioadă , chiar dacă nu folosiți chestii Qt. Mulți programatori profesioniști folosesc emacs și vim. De asemenea, cred că Eclipse se ocupă de sintaxa suplimentară. Astfel, nu există probleme cu macro-urile Qt (Q_OBJECT) sau cu adăugările de semnale / sloturi. Probabil că nu veți găsi aceste macrocomenzi în Visual Studio, deoarece (recunosc) sunt adăugiri la C ++. În general, oamenii C # /. NET nu vor folosi Qt oricum, datorită faptului că au o mulțime de funcționalități acoperite cu propriile tehnici proprii.
-
În ceea ce privește dimensiunea sursei Qt, atâta timp cât se compilează peste noapte, cui îi pasă? Am compilat Qt 4 pe Macbook-ul meu dual core în „mai puțin de peste noapte”. Sper cu siguranță că nu aceasta este motivul deciziei dvs. utilizați sau nu utilizați o anumită tehnologie. Dacă aceasta este cu adevărat o problemă, puteți descărca SDK-urile precompilate pentru Mac, Linux și Windows de pe site-ul Qt.
-
Licențierea este disponibil în trei opțiuni: 1) Licență de proprietate în cazul în care doriți să modificați Qt SINE și să nu distribuiți sau să ascundeți faptul că cineva folosește Qt și nu dorește să acorde atribuire (ar putea fi foarte important pentru branding și imagine!) 2) GPL și 3) LGPL. Da, există probleme legate de legarea statică (rularea întregului Qt în binar) – dar cred că este mai mult pentru că nu se poate arunca o privire în interior și se poate observa că ești tu cântă Qt (atribuire!). Am încercat să cumpăr o licență proprietară de la Digia și mi-au spus „pentru ceea ce faceți, chiar nu aveți nevoie de ea.” Wow. De la o afacere care se ocupă cu vânzarea licențelor.
-
Dimensiunea binarului / pachetului se datorează faptului că trebuie să distribuiți lucrurile Qt celor care nu le au: Windows are deja? lucrurile Visual Studio sau trebuie să instalați timpul de execuție. Mac vine deja cu enorma Cocoa și poate fi conectat dinamic. Deși nu fac o mulțime de distribuție, nu am găsit niciodată prea multe probleme cu distribuirea fișierului static de ~ 50 megaocteți (pe care îl pot face și mai mic cu unele dintre utilitarele de stripare / compresie binare, cum ar fi UPX). suficient de grijă pentru a face acest lucru, dar dacă lățimea de bandă ar fi vreodată o problemă, aș adăuga un pas UPX la scriptul meu de construire.
-
Ce definește „Aspectul și simțirea nativă?” Cred că „majoritatea” ar fi de acord că Mac se apropie cel mai mult de aspectul și simțul unificat. Dar aici stau, uitându-mă la Safari, iTunes, Aperture, Final Cut Pro, Pages etc. și nu seamănă nimic, în ciuda faptului că sunt realizate de către furnizorul sistemului de operare. Cred că aspectul „simt” este mai relevant: stilul widgetului, capacitatea de reacție etc. Dacă vă pasă de capacitatea de reacție, iată un motiv bun pentru a utiliza C ++ mai degrabă decât Java, sau un alt limbaj extrem de dinamic. (Obiectivul C este, de asemenea, dificil, dar încerc să disip miturile despre Qt)
În rezumat, este o problemă complicată. Dar aș dori să subliniez că cred că există mai puține motive pentru „a nu utiliza Qt”, așa cum s-ar putea gândi pe baza miturilor și a informațiilor învechite de un deceniu.
Comentarii
Răspuns
Unele dintre acestea sunt licențiate. Consultați https://en.wikipedia.org/wiki/Qt_(software) #Licensing pentru o parte din istoricul licențierilor. Până în 2000, persoanele cărora le păsa puternic open source, nu foloseau Qt. Perioadă. (Aceasta a fost, de fapt, motivația inițială pentru dezvoltarea Gnome.) Până în 2005, oamenii care doreau să poată lansa software gratuit pentru Windows nu foloseau Qt.Chiar și după acea dată, oamenii care doreau software gratuit sub altceva decât GPL, pur și simplu nu aveau opțiunea de a utiliza Qt. Astfel, orice proiect de software gratuit care este mai vechi decât acele date, nu ar putea folosi Qt. Și, bineînțeles, oamenii care scriu cod proprietar trebuiau să plătească pentru privilegiu.
În plus, nu este ca și cum ar exista o lipsa altor opțiuni. De exemplu, WxWidgets , GTK + și Tk sunt seturi de instrumente open-source, multiplataforma.
Mai mult timp, Windows a fost atât de dominant pe desktop, încât o mulțime de software a fost conținut doar pentru a rula pe Windows. Dacă instalați lanțul de instrumente Microsoft, este mai ușor să folosiți lucrurile proprietare ale Microsoft decât să vă faceți griji pentru orice altceva, iar mulți programatori au făcut exact asta.
Comentarii
Răspuns
Sunt de acord cu aproape toate motivele discutate mai sus, însă o mulțime de oameni de aici au spus că nu vor folosi Qt din cauza cheltuielilor suplimentare pe care le aduce. Nu sunt de acord cu asta, deoarece toate cele mai frecvente limbaje de astăzi (Java, C # și Python) poartă singure un pic de overhead.
În al doilea rând, Qt face programarea cu C ++ atât de ușoară și directă încât compensează resurse suplimentare pe care le folosește. Am întâlnit destul de multe aplicații de consolă scrise în Qt, mai degrabă decât C ++ standard, datorită ușurinței în care pot fi scrise.
Aș spune că productivitatea Qt este mai mare decât cea a C / C ++, dar mai mică decât limbile ca Python.
Comentarii
Răspuns
Aceasta nu este cu adevărat o încercare de a începe un război cu flăcări, am vrut doar să abordez unele dintre puncte.
Probabil că adevăratul motiv pentru care Qt nu este mai utilizat este că este C ++ și mai puțini oameni folosesc c ++ pentru aplicațiile desktop.
Qt nu este o bibliotecă C ++. Este necesară o etapă de compilare separată, ceea ce face procesul de compilare mult mai complicat în comparație cu majoritatea celorlalte biblioteci.
vs-addin pentru Visual Studio face acest lucru automat, la fel ca procesul de realizare a liniei de comandă a lui Qt. Compilatorul de resurse utilizat pentru a construi casetele de dialog pentru MFC este, de asemenea, un pas separat, dar acesta este încă c ++.
Qt este o cantitate mare de sursă, care trebuie să fie prezent și preinstalat pe orice mașină pe care o utilizați înainte de compilare. Acest lucru poate face ca configurarea unui mediu de construcție să fie mult mai obositoare.
Există o descărcare binară fiecare versiune de studio vizual și construirea de la sursă este o singură comandă. Nu văd că dimensiunea sursei SDK este atât de mare în zilele noastre. Visual Studio instalează acum toate libs-urile C ++, mai degrabă decât să vă permită să alegeți, ca urmare, dimensiunea de instalare a compilatorului este> 1 GB.
It ” S sunt disponibile numai în LGPL, ceea ce face dificilă utilizarea unei implementări unice-binare atunci când este nevoie să eliberați sub o licență mai restrictivă sau mai puțin restrictivă.
LGPL se aplică doar lib, nu vă afectează codul. Da, înseamnă că trebuie să livrați DLL-uri mai degrabă decât un singur binar (cu excepția cazului în care plătiți), dar într-o lume în care trebuie să descărcați un timp de rulare Java sau o actualizare .Net pentru o utilizare mică nu este o problemă atât de mare. „Este, de asemenea, o problemă mai mică pe platformele cu un singur ABI, astfel încât alte aplicații Qt să poată partaja libs-urile.
În unele cazuri, nu face nimic” Arată ca programele native.Proiectarea unei singure UI pentru toate platformele nu va arăta în mod inerent atunci când este mutată de la mașină la mașină, din diverse motive de stil vizual.
Se presupune că să folosesc widget-uri și teme native. Trebuie să recunosc că fac în principal aplicații tehnice, astfel încât utilizatorii mei să nu fie prea preocupați de stil. Mai ales pe Windows, noua modă de a avea stilul în sine ca widget pentru smartphone înseamnă că există din ce în ce mai puțin un standard.
Comentarii
Răspuns
Motivul este simplu: nu are legături bune la toate limbile principale și nu este magic întotdeauna adecvat pentru jobul la îndemână.
Utilizați instrumentul potrivit pentru job. Dacă scriu o aplicație simplă din linia de comandă, de ce aș face asta cu Qt doar de dragul ei?
Ca răspuns mai general (pe care îl pot oferi pentru că sunt relevant aici) ), unii programatori pur și simplu nu l-au dat niciodată și au decis să-l folosească. În unele cazuri, nu există niciun alt motiv, în afară de faptul că programatorul nu a găsit niciodată o nevoie și a analizat-o.
Comentarii
Răspuns
Cadrele precum Qt sunt potrivite atunci când sunteți mai preocupat de aspectul produsului dvs. la fel pe toate platformele decât cu produsul dvs. corect pe toate platformele. Din ce în ce mai des în zilele noastre, aceste tipuri de aplicații trec la tehnologii bazate pe web.
Răspunde
după părerea mea, învățarea programării C ++ este mai simplă decât a cădea în alte limbi care ascund complexitatea lor, iar programatorul nu știe ce chiar se întâmplă în fundal. Pe de altă parte, Qt adaugă unele beneficii față de C ++, pentru a-l face mai înalt decât C ++ nativ. Astfel, Qt C ++ este un cadru excelent pentru cine dorește să dezvolte sarcini de nivel scăzut sau altele, în același mod. C ++ este (prin unele practici) un limbaj complex și simplu. Complex pentru cine vrea să nu provoace cu el, simplu pentru cine îi place.Nu-l lăsați pentru complexitatea ei!
Răspundeți
Sunt de acord că Qt este un cadru frumos cu care să lucrați. Totuși, există o serie de probleme pe care le am cu el:
- Este scris în C ++, care este un limbaj foarte scăzut. Numai faptul că este C ++ va face ca fiecare programator Qt să fie semnificativ mai puțin productiv în comparație cu Frameworks scrise în alte limbi. Carnea mea principală cu C ++ ca limbaj de dezvoltare GUI este că nu are aproape nicio noțiune de gestionare automată a memoriei, ceea ce face procesul de dezvoltare mult mai predispus la erori. Nu este introspectiv, ceea ce îngreunează mult depanarea. Majoritatea celorlalte truse de instrumente GUI majore au o noțiune de gestionare automată a memoriei și introspecție.
- Fiecare trusă de instrumente multiplatăforme suferă de problema că doar poate implementa cel mai puțin numitor comun dintre toate platformele acceptate. Acest lucru și diferite linii directoare ale interfeței de utilizare pe diferite platforme pun foarte mult în discuție oportunitatea GUI-urilor pe mai multe platforme în ansamblu.
- Qt se concentrează foarte mult pe codificarea tuturor interfeței dvs. de utilizare. Chiar dacă puteți utiliza QtDesigner pentru a construi unele părți ale interfeței dvs. de utilizare, aceasta lipsește grav în comparație cu, să spunem, (Cocoa / Obj-C) Interface Builder sau cu instrumentele .Net.
- Chiar dacă Qt include o mulțime de funcționalități de aplicații de nivel scăzut, nu se poate compara cu a avea un cadru personalizat pentru o anumită platformă. Bibliotecile native de sisteme de operare atât pentru Windows cât și pentru OSX sunt semnificativ mai puternice decât implementările Qt. (Gândiți-vă la cadrele audio, acces la sistem de fișiere de nivel scăzut etc.)
Acestea fiind spuse, îmi place să folosesc PyQt pentru prototiparea rapidă a aplicațiilor sau aplicații interne. Folosind Python pentru a face toate codările, atenua preocupările cu C ++ și face de fapt Qt un loc foarte plăcut.
Edit, ca răspuns la câteva comentarii:
Când am scris despre faptul că Qt este scris în C ++, nu mă plângeam atât de mult de Qt în sine , dar mai multe despre mediul în care trăiește. Este adevărat că Qt își gestionează propriile resurse foarte bine, dar tot codul dvs. legat de GUI, dar nu Qt, trebuie să fie scris și în C ++. Chiar și acolo, Qt oferă multe instrumente frumoase, dar, în cele din urmă, trebuie să aveți de-a face cu C ++ la acel nivel. Qt face C ++ suportabil, dar este în continuare C ++.
În ceea ce privește introspecția, ceea ce vreau să spun este următorul: Cele mai dificile cazuri de depanare sunt cand tu aveți un indicator către un obiect care nu se comportă așa cum credeți că ar trebui. Cu C ++, depanatorul dvs. ar putea fi capabil să privească puțin în interiorul acelui obiect (dacă se întâmplă să aibă informații de tip la punctul secundar), dar chiar și asta nu funcționează întotdeauna. Luați, pe de altă parte, cacao în aceeași situație. În Cocoa / Obj-C, veți putea trimite mesaje („funcții de apel”) către un obiect chiar din depanator. Puteți schimba starea obiectelor, îl puteți interoga pentru atributele sale, îi puteți cere tipul și numele funcțiilor sale … Acest lucru poate face depanarea mult mai convenabilă. Qt / C ++ nu are nimic aproape de asta.
Comentarii
Răspuns
Cel mai important, dar lucru nemenționat. În proiectul mare, un lucru cauzează atât de multe probleme și codul nu este necesar. Mecanismele sloturilor de semnal ale Qt sunt ineficiente. Widgeturile Qt nu furnizează semnalele necesare pentru widgeturile simple de eveniment. De exemplu, nu puteți seta semnale pentru onHover, onMouseEnter, onMouseLeave, onKeyReleased, onLostFocus, onGainFocus și etc. Chiar și cel mai complex widget, cum ar fi QTreeWidget oferă unul sau două semnale inutile ultra simple.
Da, puteți utiliza evenimente DAR !!! ați creat noi clase pentru fiecare widget cu eveniment personalizat. Aceasta este o eficiență imensă pierdută;
- Ați rescris fiecare eveniment de obiect widget personalizat, există mici modificări.
- Pierdeți toate lucrurile Qt Designer. Trebuie să promovați fiecare widget cu evenimente personalizate.
- Proiectul a devenit mai mare și greu de întreținut.
- Ați început să nu vă placă qt din această cauză. Și ați început să vorbiți despre modul în care .net oferă delegați, modul în care este mult mai bine decât slotul de semnal, modul în care .net componentele (widget-urile) oferă în general fiecare eveniment pe care ți-l poți imagina. Și etc.
Unul dintre colegii mei a scris o nouă clasă de casetă combinată pentru fiecare widget de casetă combinată, deoarece a trebuit să utilizeze un eveniment care nu este semnal. Poveste adevărată …
Cu toate acestea, Qt este cel mai bun cadru de interfață C ++ UI de până acum, cu downs și up.
Comentarii
Răspuns
Îmi place foarte mult Qt, dar este „puțin greu” pentru multe aplicații. Uneori nu aveți nevoie de acel nivel de complexitate. Uneori ai nevoie doar de ceva simplu, fără toate cheltuielile generale ale Qt. Nu fiecare aplicație trebuie să fie bazată pe evenimente și C ++ oferă un set rezonabil de șabloane. Boost oferă un alt set foarte bun și include o mulțime de funcționalități de nivel scăzut (fișier, soclu, pointeri gestionați etc.) pe care le face QT.
Alte aplicații au cerințe de licențiere care nu se joacă bine cu GPL , Licența comercială LGPL sau Qt. GPL nu este adecvat pentru software-ul comercial. LGPL nu este adecvat pentru software-ul legat static, iar licența comercială costă bani – lucru pe care mulți nu sunt dispuși să îl plătească.
Unii au considerații de securitate sau stabilitate care nu permit biblioteci complexe precum Qt.
Trebuie să rulați moc pentru pre-procesarea surselor. Aceasta nu este o problemă uriașă, dar poate fi descurajant pentru noul utilizator. Mulți dintre programatori consideră că aveți nevoie de pentru a utiliza qmake cu Qt, dar „este un nume greșit. Este posibil să conectați Qt la alte sisteme de construire destul de ușor.
Unele ținte sunt memorie sau procesor constrâns.
Există unele probleme specifice platformei în ea. Majoritatea acestor informații sunt nedocumentate. Construiți o aplicație suficient de mare și vă veți întâlni cu ele și vă veți întreba ce se întâmplă (responsabilitate, ultima dată când am folosit Qt în furie a fost în urmă cu peste 18 luni, deci s-ar putea să se fi îmbunătățit).
Este doar C ++. Există alte legături lingvistice, dar ele tind să ascundă sau să expună slab o mulțime de funcționalitate pentru care ați dori Qt.
Există multe motive pentru a nu utiliza Qt, de aceea există alternative. Dacă tot ce ai este un ciocan, atunci fiecare problemă va arăta ca un cui.
Comentarii
Răspuns
Motivul real nu este tehnic.
Oamenii se întâmplă a fi diferit. La fel și alegerile lor. Uniformitatea nu este o trăsătură umană.
Comentarii