Dlaczego nie napisano więcej aplikacji komputerowych za pomocą Qt? [Zamknięte]

O ile wiem i rozumiem z mojego doświadczenia z Qt, jest to bardzo dobra i łatwa do nauczenia biblioteka. Ma bardzo dobrze zaprojektowany interfejs API i jest wieloplatformowy, a to tylko dwie z wielu funkcji, które czynią go atrakcyjnym. Chcę wiedzieć, dlaczego więcej programistów nie używa Qt. Czy istnieje niedobór, który przemawia przeciwko niemu? Która funkcja sprawia, że ​​inne biblioteki są lepsze niż Qt? Czy problem dotyczy licencjonowania?

Tak naprawdę nie zamierzam tego uśmierzać, ale z tych powodów osobiście nie używam Qt. Jest wiele dobrych rzeczy do powiedzenia na ten temat - mianowicie, że API działa przez większość czasu i że płynnie łączy platformy. Ale nie używam Qt, ponieważ:

1. W niektórych przypadkach po prostu nie wygląda tak, jak wyglądają programy natywne. Zaprojektowanie jednego interfejsu użytkownika dla wszystkich platform z natury nie będzie wyglądało dobrze po przeniesieniu z maszyny na maszynę, z różnych powodów stylizacji wizualnej. Na przykład na komputerach Mac dzielone paski są zwykle stosunkowo grube, a przyciski są małe i zaokrąglone ikonami. Na komputerach z systemem Windows paski podziału są zwykle wąskie, a przyciski są bardziej tekstowe i mają bardziej kwadratowe wzory. To, że możesz napisać jeden interfejs dla każdej platformy, nie oznacza, że ​​powinieneś to robić w przypadku większości aplikacji.
2. Qt nie jest biblioteką C ++. Wymaga osobnego kroku kompilacji, co znacznie komplikuje proces kompilacji w porównaniu z większością innych bibliotek.
3. W wyniku (2) środowiska IDE i narzędzia C ++ mogą oznaczać wyrażenia Qt jako błędy, ponieważ nie rozumieją specyfiki Qt. To prawie wymusza użycie QtCreatora lub edytora tekstowego, takiego jak vim.
4. Qt to duża ilość źródeł, które muszą być obecne i wstępnie zainstalowane na każdym komputerze, którego używasz przed kompilacją. Może to sprawić, że skonfigurowanie środowiska kompilacji będzie znacznie bardziej uciążliwe.
5. Jest dostępny tylko na licencji LGPL, co utrudnia korzystanie z pojedynczego wdrożenia binarnego, gdy trzeba go wydać na podstawie bardziej restrykcyjnej lub mniej restrykcyjnej licencji.
6. Tworzy bardzo duże skompilowane pliki binarne w porównaniu z podobnie napisanymi „zwykłymi aplikacjami natywnymi” (z wyjątkiem oczywiście aplikacji napisanych dla KDE).

Jak mówią ludzie, każde narzędzie pasuje do każdego problemu i sytuacji ...

Ale jeśli jesteś programistą C ++, Qt jest twoim frameworkiem. Brak rywala.

Opracowujemy złożoną komercyjną aplikację do obrazowania medycznego, a Qt nadal działa.

Nie twierdzę, że „wady”, które ludzie o tym mówią, są fałszywe, ale mam wrażenie, że od dawna nie próbowali Qt (ciągle poprawia się w każdej nowej wersji ...) I, głównie wszystkie problemy, które komentują, nie stanowią problemu, jeśli się nimi zajmiesz.

Niespójność platformy interfejsu użytkownika: tylko jeśli używasz widżetów interfejsu użytkownika „takimi, jakie są”, bez dostosowywania i niestandardowej grafiki.

Przeciążenie preprocesora Qt: Tylko w przypadku nadużycia mechanizmu gniazda sygnału lub dziedziczenia QObject, gdy tak naprawdę nie ma takiej potrzeby.

Nawiasem mówiąc, wciąż piszemy aplikacje w języku C # .NET i robimy to od dłuższego czasu. Więc myślę, że mam enouch perspektywy.

Jak powiedziałem, każde narzędzie do każdej sytuacji,

ale Qt jest bez wątpienia spójną i przydatną ramą.

Ze wszystkich rzeczy, których nie lubię w Qt, najbardziej boli mnie to, że nie działa dobrze z szablonami. Nie możesz tego zrobić:

template < typename T >
struct templated_widget : QWidget
{
  Q_OBJECT;

public signals:
  void something_happened(T);
};

Nie działa również dobrze z preprocesorem. Nie możesz tego zrobić:

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

To, w połączeniu z faktem, że wszystko, co odpowiada na sygnał, musi być Q_OBJECT, sprawia, że ​​Qt jest trudny do pracy dla programisty C ++. Ludzie przyzwyczajeni do programowania w stylu Java lub Python prawdopodobnie są raczej lepsi.

Właściwie spędziłem dużo czasu i wysiłku, szukając sposobu na odzyskanie bezpieczeństwa typu i podłączenie sygnału Qt do dowolnego obiektu funktora: http://crazyeddiecpp.blogspot.com/2011/01/quest-for-sane-signals -in-qt-step-1.html

To, co chcę zrobić, to podstawowy, codzienny rozwój C ++, który jest prawie niemożliwy przez Qt moc ... który sam w sobie jest teraz zupełnie niepotrzebny, jeśli w ogóle był.

Szczerze mówiąc, utknąłem z tym, ponieważ jeśli chcesz przeprowadzić automatyczne testowanie interfejsu użytkownika, Qt jest właściwie jedyną grą w mieście bez MFC ... która jest tak 1980 (naprawdę ciężko jest pracować w tym gównie). Niektórzy mogą powiedzieć WX, ale ma to jeszcze poważniejsze problemy. GTKmm byłby moim pierwszym wyborem, ale ponieważ jest w całości rysowany przez właściciela i nie zapewnia dostępności ... nie może być napędzany przez standardowe oprogramowanie testujące. Qt jest pod tym względem wystarczająco trudne ( ledwo działa, gdy modyfikujesz wtyczkę ułatwień dostępu).

Jednym z powodów, aby nie używać Qt jest to, że jeśli piszesz tylko dla jednej architektury, takiej jak Windows, możesz chcieć użyć C # / .NET (lub Cocoa na Macu), ponieważ zawsze będą mogli korzystać z najnowszych dzwonków i -historie systemu operacyjnego.

Jeśli piszesz aplikacje wieloplatformowe, możesz być już mocno obciążony inną technologią, taką jak Java (tzn. Pracujesz w „Sklepie Java”). Twój wybór technologii może być podyktowany ekosystemem, w którym się rozwijasz, na przykład interfejsy API specyficzne dla języka. W takich przypadkach minimalizacja liczby technologii może być korzystna.

Trzecim powodem, dla którego mogę wymyślić, jest to, że Qt opiera się na C ++, a C ++ jest stosunkowo trudnym / niebezpiecznym językiem do programowania. Myślę, że jest to język dla profesjonalistów. Jeśli potrzebujesz najwyższej wydajności i potrafisz być drobiazgowy, C ++ jest prawdopodobnie najlepszą grą w mieście. W rzeczywistości Qt poprawia wiele problemów z zarządzaniem pamięcią, jeśli skonfigurujesz rzeczy tak, aby wykraczały poza zakres. Ponadto sama Qt dobrze sobie radzi, izolując użytkownika od wielu nieprzyjemnych problemów z C ++. Każdy język i struktura ma swoje zalety i wady. Jest to bardzo, bardzo skomplikowana kwestia, którą zwykle można podsumować dodaniem często spotykanym w restauracjach: Szybkość, Jakość i Cena (ale można wybrać tylko dwa).

Chociaż przepisy mówią, że powinienem skupić się na odpowiedzi na pytanie, chcę odeprzeć niektóre kwestie poruszone przez Billy ONeala, który moim zdaniem wykonuje dobrą robotę, podsumowując często cytowane powody, dla których nie używa Qt:

1. Qt to rzeczywiście biblioteka / framework / pliki nagłówkowe C ++. Jest rozszerzonydzięki makroprocesorowi (moc), który umożliwia między innymi sygnały i gniazda. Przekształca dodatkowe makropolecenia (takie jak Q_OBJECT), dzięki czemu klasy mają introspekcję i wszelkiego rodzaju inne gadżety, o których możesz pomyśleć jako o dodaniu funkcjonalności C-Objective do C ++. Jeśli wiesz wystarczająco dużo o C ++, aby obrazić się tym brakiem czystości, tj. Jesteś zawodowcem, to 1) nie używaj Q_OBJECT i jego podobnych lub 2) bądź wdzięczny, że to robi, i programuj wokół bardzo ograniczonych przypadków narożnych gdzie to powoduje problem. Dla osób, które mówią „Użyj wzmocnienia dla sygnałów i gniazd!” następnie odparłbym, że wymieniasz jeden „problem” na inny. Zwiększenie jest ogromne i ma swoje często cytowane problemy, takie jak słaba dokumentacja, przerażający interfejs API i horrory między platformami (pomyśl o starych kompilatorach, takich jak gcc 3.

2. W przypadku obsługi edytora wynika to również z 1, nieco się zgadzam. W rzeczywistości Qt Creator to IMHO najlepszy graficzny edytor C ++, kropka, nawet jeśli nie używasz Qt. Wielu profesjonalnych programistów używa emacsa i vima. Myślę też, że Eclipse obsługuje dodatkową składnię. Dlatego nie ma problemów z makrami Qt (Q_OBJECT) ani dodatkami sygnałów / gniazd. Prawdopodobnie nie znajdziesz tych makr w Visual Studio, ponieważ (przyznaję) są one dodatkami do C ++. Ale ogólnie rzecz biorąc, ludzie C # / .NET i tak nie będą używać Qt, ponieważ mają wiele funkcji objętych własnymi zastrzeżonymi technikami.

3. Co do wielkości źródła Qt, o ile kompiluje się przez noc, kogo to obchodzi? Kompilowałem Qt 4 na moim dwurdzeniowym Macbooku w „mniej niż z dnia na dzień”. Z pewnością mam nadzieję, że nie to decyduje o tym, czy zdecydujesz się na korzystanie z konkretnej technologii. Jeśli to naprawdę problem, możesz pobrać wstępnie skompilowane zestawy SDK dla komputerów Mac, Linux i Windows ze strony internetowej Qt.

4. Licencje są dostępne w trzech opcjach: 1) Licencja własna na wypadek, gdybyś chciał zmodyfikować Qt ITSELF i nie udostępniać go, lub ukryć fakt, że używasz Qt i nie chcesz podawać atrybucji (może to być bardzo ważne dla marki i wizerunku!) 2 ) GPL i 3) LGPL. Tak, są problemy z łączeniem statycznym (zwijaniem całego Qt do pliku binarnego) - ale myślę, że to więcej, ponieważ nie można zajrzeć do środka i zauważyć, że używasz Qt (atrybucja!). Próbowałem kupić licencję prawną od Digii, a oni powiedzieli mi „do tego, co robisz, naprawdę nie potrzebujesz”. Łał. Od firmy zajmującej się sprzedażą licencji.

5. Rozmiar pliku binarnego / pakietu polega na tym, że musisz rozpowszechniać rzeczy Qt wśród osób, które go nie mają: system Windows już? Visual Studio lub musisz zainstalować środowisko wykonawcze. Mac ma już ogromne kakao i może być dynamicznie łączony. Chociaż nie robię dużo dystrybucji, nigdy nie znalazłem dużego problemu z dystrybucją ~ 50 megabajtowego pliku statycznego (który mogę zmniejszyć nawet za pomocą niektórych narzędzi do ściągania / kompresji binarnych, takich jak UPX). Po prostu nie dbam o to wystarczająco, ale jeśli przepustowość kiedykolwiek byłaby problemem, dodałbym krok UPX do mojego skryptu kompilacji.

6. Co definiuje „Native Look and Feel?” Myślę, że „większość” zgodzi się, że Mac jest najbliższy jednolitemu wyglądowi. Ale tutaj siedzę i patrzę na Safari, iTunes, Aperture, Final Cut Pro, Pages itp. I wyglądają podobnie, mimo że zostały stworzone przez producenta systemu operacyjnego. Myślę, że aspekt „czuć” jest bardziej odpowiedni: styl widgetu, responsywność itp. Jeśli zależy Ci na responsywności, oto dobry powód, aby używać C ++ zamiast Java lub innego wysoce dynamicznego języka. (Cel C także się kołysze, ale staram się rozwiać mity o Qt)

Podsumowując, jest to skomplikowany problem. Chciałbym jednak zaznaczyć, że moim zdaniem istnieje mniej powodów, by „nie używać Qt”, jak można by sądzić na podstawie mitów i nieaktualnych informacji z dekady.

Niektóre z nich to licencjonowanie. Zobacz https://en.wikipedia.org/wiki/Qt_(software)#Licensing, aby zapoznać się z historią licencjonowania. Do 2000 roku ludzie, którym bardzo zależało na open source, nie używali Qt. Kropka. (W rzeczywistości była to pierwotna motywacja do rozwoju Gnome.) Do 2005 roku ludzie, którzy chcieli móc wypuszczać darmowe oprogramowanie dla Windows, nie używali Qt. Nawet po tej dacie ludzie, którzy chcieli wolnego oprogramowania na podstawie innej niż GPL, po prostu nie mieli możliwości korzystania z Qt. Tak więc każdy projekt wolnego oprogramowania, który jest starszy niż te daty, nie może korzystać z Qt. I oczywiście ludzie piszący kod własności musieli zapłacić za ten przywilej.

Ponadto nie jest tak, jakby brakowało innych opcji. Na przykład WxWidgets , GTK + i Tk to otwarte, wieloplatformowe zestawy narzędzi.

Co więcej, przez długi czas system Windows był tak dominujący na pulpicie, że wiele programów można było uruchamiać tylko w systemie Windows. Jeśli zainstalujesz zestaw narzędzi Microsoft, łatwiej jest po prostu korzystać z zastrzeżonych przez Microsoft rzeczy, niż martwić się czymkolwiek innym, a wielu programistów właśnie to zrobiło.

Zgadzam się z prawie wszystkimi omówionymi powyżej przyczynami, jednak wiele osób twierdziło, że nie będzie używać Qt z powodu dodatkowego obciążenia, które to ze sobą niesie. Nie zgadzam się z tym, ponieważ wszystkie najpopularniejsze obecnie języki (Java, C # i Python) same w sobie są dość obciążone.

Po drugie, Qt sprawia, że ​​programowanie w C ++ jest tak łatwe i proste, że nadrabia dodatkowe zasoby, których używa. Natrafiłem na całkiem sporo aplikacji konsolowych napisanych w Qt zamiast w standardowym C ++ ze względu na łatwość pisania.

Powiedziałbym, że wydajność Qt jest większa niż C / C ++, ale mniejsza niż języków takich jak Python.

To naprawdę nie jest próba rozpoczęcia wojny z płomieniami, chciałem tylko poruszyć niektóre kwestie.

Prawdopodobnie prawdziwym powodem, dla którego Qt nie jest szerzej stosowany, jest to, że jest to C ++, a mniej osób używa c ++ do aplikacji komputerowych.

Qt nie jest biblioteką C ++. Wymaga osobnego kroku kompilacji, co znacznie komplikuje proces kompilacji w porównaniu z większością innych bibliotek.

Dodatek vs dla visual studio robi to automatycznie, podobnie jak proces tworzenia linii poleceń Qt. Kompilator zasobów używany do budowania okien dialogowych dla MFC jest również osobnym krokiem, ale wciąż jest to c ++.

Qt to duża ilość źródeł, które muszą być obecne i wstępnie zainstalowane na każdym komputerze, którego używasz przed kompilacją. Może to sprawić, że skonfigurowanie środowiska kompilacji będzie znacznie bardziej uciążliwe.

Do każdej wersji programu visual studio jest pobierane binarnie, a kompilacja ze źródła to jedno polecenie. Nie widzę, żeby rozmiar źródła SDK był obecnie bardzo interesujący. Visual Studio instaluje teraz wszystkie biblioteki C ++, zamiast pozwolić ci wybierać i wybierać, w wyniku czego rozmiar instalacji kompilatora wynosi> 1 Gb.

Jest dostępny tylko na licencji LGPL, co utrudnia korzystanie z pojedynczego wdrożenia binarnego, gdy trzeba go wydać na podstawie bardziej restrykcyjnej lub mniej restrykcyjnej licencji.

Licencja LGPL dotyczy tylko biblioteki lib, nie wpływa na kod. Tak, oznacza to, że musisz wysyłać biblioteki DLL zamiast jednego pliku binarnego (chyba że płacisz), ale w świecie, w którym musisz pobrać środowisko wykonawcze Java lub aktualizację .Net dla niewielkiego wykorzystania, nie jest to wielka sprawa. Jest to również mniejszy problem na platformach z jednym ABI, dzięki czemu inne aplikacje Qt mogą współdzielić biblioteki.

W niektórych przypadkach po prostu nie wygląda tak, jak wyglądają programy natywne. Zaprojektowanie jednego interfejsu użytkownika dla wszystkich platform z natury nie będzie wyglądało dobrze po przeniesieniu z maszyny na maszynę, z różnych powodów stylizacji wizualnej.

Ma używać natywnych widżetów i motywów. Muszę przyznać, że robię głównie aplikacje techniczne, więc moi użytkownicy nie przejmują się stylem. Zwłaszcza w systemie Windows nowa moda na to, by wszystko wyglądało jak widżet na smartfona, oznacza, że ​​i tak jest coraz mniej standardu.

Powód jest prosty: nie ma dobrych powiązań ze wszystkimi głównymi językami i nie zawsze jest magicznie odpowiedni dla danego zadania.

Użyj odpowiedniego narzędzia do pracy. Jeśli piszę prostą aplikację z linii poleceń, dlaczego miałbym to robić z Qt tylko ze względu na to?

Jako ogólniejszą odpowiedź (którą mogę udzielić, ponieważ jestem tutaj istotny), niektórzy programiści nigdy nie dadzą jej szansy i zdecydują się jej użyć. W niektórych przypadkach nie ma konkretnego powodu innego niż to, że programista nigdy nie znalazł takiej potrzeby i nie przyjrzał się jej.

Ramy takie jak Qt są odpowiednie, gdy bardziej zależy Ci na tym, aby Twój produkt wyglądał tak samo na wszystkich platformach, niż na swoim produkcie, który wygląda poprawnie na wszystkich platformach. Obecnie coraz częściej aplikacje tego typu przechodzą na technologie internetowe.

Zgadzam się, że Qt to fajna platforma do pracy. Mimo to mam z tym wiele problemów:

1. Jest napisany w C ++, który jest językiem naprawdę niskiego poziomu. Sam fakt, że jest to C ++, sprawi, że każdy programista Qt będzie znacznie mniej produktywny w porównaniu do frameworków napisanych w innych językach. Główną zaletą C ++ jako języka programowania GUI jest to, że nie ma pojęcia automatycznego zarządzania pamięcią, co czyni proces programowania o wiele bardziej podatnym na błędy. Nie jest introspekcyjny, co znacznie utrudnia debugowanie. Większość innych głównych zestawów narzędzi GUI ma pewne pojęcie automatycznego zarządzania pamięcią i introspekcji.
2. Każdy wieloplatformowy zestaw narzędzi ma problem polegający na tym, że może tylko zaimplementować najmniej powszechny mianownik ze wszystkich obsługiwanych platform. To i różne wytyczne interfejsu użytkownika na różnych platformach bardzo podważają zasadność stosowania wieloplatformowych interfejsów GUI w ogóle.
3. Qt jest bardzo skoncentrowany na kodowaniu całego interfejsu użytkownika. Mimo że można użyć QtDesigner do budowy niektórych części interfejsu użytkownika, jest on poważnie brakuje w porównaniu do, powiedzmy, (Cocoa / Obj-C) Konstruktora interfejsów lub narzędzi .Net.
4. Mimo że Qt zawiera wiele funkcji aplikacji niskiego poziomu, nie może się równać z dostosowaniem frameworka do konkretnej platformy. Biblioteki natywnego systemu operacyjnego zarówno dla systemu Windows, jak i OSX są znacznie wydajniejsze niż implementacje Qt. (Pomyśl o ramach audio, niskim poziomie dostępu do systemu plików itp.)

To powiedziawszy, uwielbiam używać PyQt do szybkiego prototypowania aplikacji lub aplikacji wewnętrznych. Używanie Pythona do całego kodowania zmniejsza obawy związane z C ++ i sprawia, że ​​Qt jest bardzo przyjemnym miejscem.

Edytuj w odpowiedzi na niektóre komentarze:

Kiedy pisałem o tym, że Qt jest napisane w C ++, nie tyle narzekałem na samą Qt, ile na środowisko, w którym żyje. To prawda, że ​​Qt bardzo dobrze zarządza swoimi zasobami, ale wszystkie twoje związane z GUI, ale kod nie-Qt również musi być napisany w C ++. Nawet tam Qt zapewnia wiele fajnych narzędzi, ale ostatecznie musisz radzić sobie z C ++ na tym poziomie. Qt sprawia, że ​​C ++ jest znośny, ale nadal jest C ++.

Jeśli chodzi o introspekcję, mam na myśli to: najtrudniejsze przypadki debugowania mają miejsce, gdy masz wskaźnik do jakiegoś obiektu, który nie zachowuje się tak, jak myślisz, że powinien. W przypadku C ++ debugger może nieco zaglądać do tego obiektu (jeśli zdarza się, że zawiera informacje o typie w punkcie), ale nawet to nie zawsze działa. Z drugiej strony weź kakao w tej samej sytuacji. W Cocoa / Obj-C można wysyłać wiadomości („funkcje wywoływania”) do obiektu bezpośrednio w debuggerze. Możesz zmienić stan obiektów, możesz zapytać o jego atrybuty, możesz zapytać o typ i nazwy funkcji ... To może znacznie ułatwić debugowanie. W Qt / C ++ nie ma nic podobnego.

Naprawdę lubię Qt, ale jest trochę ciężki dla wielu aplikacji. Czasami po prostu nie potrzebujesz tego poziomu złożoności. Czasami potrzebujesz po prostu czegoś prostego bez całego narzutu Qt. Nie każda aplikacja musi być sterowana zdarzeniami, a C ++ zapewnia rozsądny zestaw szablonów. Boost zapewnia kolejny bardzo dobry zestaw i zawiera wiele niskopoziomowych funkcji (plików, gniazd, wskaźników zarządzanych itp.), Które wykonuje QT.

Inne aplikacje mają wymagania licencyjne, które nie działają dobrze z licencją komercyjną GPL, LGPL lub Qt. GPL jest nieodpowiednia dla oprogramowania komercyjnego. Licencja LGPL jest nieodpowiednia dla statycznie połączonego oprogramowania, a licencja komercyjna kosztuje - coś, za co wielu nie chce płacić.

Niektóre mają względy bezpieczeństwa lub stabilności, które nie zezwalają na złożone biblioteki, takie jak Qt.

Musisz uruchomić moc, aby wstępnie przetworzyć źródła. To nie jest duży problem, ale może być zniechęcający dla nowego użytkownika. Wielu programistów uważa, że musisz używać qmake z Qt, ale to błędne określenie. Możliwe jest łatwe podłączenie Qt do innych systemów kompilacji.

Niektóre cele są bardzo ograniczone w pamięci lub w procesorze.

Jest w nim kilka gotch specyficznych dla platformy. Większość tych błędów nie jest udokumentowana. Zbuduj wystarczająco dużą aplikację, a na nią natrafisz i będziesz się zastanawiać, co się dzieje (zrzeczenie się, że ostatni raz użyłem Qt w gniewie ponad 18 miesięcy temu, więc mogło się poprawić).

To tylko C ++. Istnieją inne powiązania językowe, ale mają tendencję do ukrywania lub słabego ujawnienia wielu funkcji, dla których chcesz Qt.

Istnieje wiele powodów, aby nie używać Qt, dlatego istnieją alternatywy. Jeśli masz tylko młotek, każdy problem będzie wyglądał jak gwóźdź.

Najważniejsza, ale nie wspomniana rzecz. W dużym projekcie jedna rzecz powoduje tyle problemów i niepotrzebnego kodu. Mechanizmy szczelin sygnałowych Qt są nieefektywne. Widżety Qt nie zapewniają niezbędnych sygnałów dla prostych widżetów zdarzeń. Na przykład nie można ustawić sygnałów dla onHover, onMouseEnter, onMouseLeave, onKeyReleased, onLostFocus, onGainFocus itp. Nawet najbardziej złożony widget, taki jak QTreeWidget, zapewnia jeden lub dwa bardzo proste, bezużyteczne sygnały.

Tak, możesz używać wydarzeń ALE !!! utworzyłeś nową klasę dla każdego widżetu ze zdarzeniem niestandardowym. Jest to ogromna utrata wydajności;

• Przepisałeś każde dostosowane zdarzenie obiektu widgetu, wprowadzono małe zmiany.
• Tracisz wszystkie rzeczy z Qt Designer. Musisz promować każdy widget za pomocą niestandardowych wydarzeń.
• Projekt stał się większy i trudny w utrzymaniu.
• Z tego powodu zacząłeś nie lubić qt. I zaczynamy mówić o tym, w jaki sposób .net zapewnia delegatom, w jaki sposób jest o wiele lepszy niż gniazdo sygnału, w jaki sposób komponenty .net (widżety) generalnie zapewniają każde zdarzenie, jakie możesz sobie wyobrazić. Itd.

Jeden z moich studentów napisał nową klasę pola kombi dla każdego widżetu pola kombi, ponieważ musiał użyć jakiegoś zdarzenia bez sygnału. Prawdziwa historia...

Jednak Qt jest jak dotąd najlepszą strukturą interfejsu użytkownika C ++ z wadami i wzlotami.

według mnie nauka programowania w C ++ jest łatwiejsza niż popadanie w inne języki, które ukrywają ich złożoność, a programista nie wie, co tak naprawdę dzieje się w tle. Z drugiej strony Qt dodaje pewne zalety w stosunku do C ++, dzięki czemu jest wyższy niż natywny C ++. Dlatego Qt C ++ jest świetnym frameworkiem dla tych, którzy chcą rozwijać zadania niskiego poziomu lub zadania wysokiego poziomu w ten sam sposób. C ++ jest (według niektórych praktyk) złożonym i prostym językiem. Kompleksowy dla tych, którzy nie chcą się z nim mierzyć, prosty dla tych, którzy go lubią. Nie zostawiaj tego ze względu na złożoność!

Rzeczywisty powód nie jest techniczny.

Ludzie się różnią. Podobnie są z ich wyborami. Jednorodność nie jest cechą ludzką.