Raport Totaliztyczny: 7. Sprawa qt.io

[Jacek Marcin Jaworski]

Zamieszczam to tu jako ciekawostkę - dyskusja tu: https://groups.google.com/g/pl.comp.lang.c/c/AhS6IdVImF4

qt.io: Międzynarodowa firma będąca od 2011r. własnością fińskiej firmy Digia. W latach 2008-2011 należała do fińskiej Noki. W latach 1994-2008 funkcjonowała jako samodzielna norweska firma Trolltech (początkowo miała nazwę Quasar). Trolltech nigdy nie przynosił dochodów.

Biblioteka Qt: To wieloplatformowa bib. zakodowana w C++. Jest podzielona na kilka mniejszych bibliotek (zwanych modułami Qt): podst. kontrolki graf., kontrolka OpenGL (można wyświetlić w oknie Qt scenę OpenGL), bazy SQL, sieć IP, port szeregowy, geolokalizacja, drukowanie, dźwięk, kontrolki do wyświetlania plików HTML i PDF (ta ostatnia mimo, że prymitywna jest komercyjna), kl. do parsowania plików Json i XML (do plików CSV brak kl. od qt.io , ale jest do nich darmowa bibl. na github.com), DBus (to w sys. Linuks).

Oprócz tego jest sporo w Qt bibliotek "robiących tłum": QtConcurrent (jakiś dziwny potworek do programowania równoległego), QtRemote (tajemnicza bib. do budowy systemów obiektów rozproszonych - z dok. nie można nawet się dowiedzieć w jakim modelu to działa: czy w modelu wywołań synchronicznych czy asynchronicznych), QtScript (stary potworek skryptowy z czasów Trolltech zastąpiony w czasach Noki przez potwora QML), QtSVG (powinna to być zwykła wtyczka do obrazków), QtTest (do testów jednostkowych - jednak jest to banalne rozw.), QtWebKit (stary silnik wyświetlania plików HTML - powinien być zastąpiony QWebEngine, jednak ma on zupełnie inne API).

Od czasów sprzedaży firmie Nokia bib. Qt praktycznie nie jest rozwijana. Dzieje się tak, gdyż zaczęto wtedy tworzyć i wymuszać na programistach C++ użycie zupełnie niezwiązanych z C++ narzędzi skryptowych QML. Potwierdzeniem braku prac nad Qt jest brak aktualizacji s. WWW wiki.qt.io/Qt_History (ost. wpis dot. 20 lecia Qt jakie obchodzono w 2015r.).

QML: jest to zdegenerowany j. skryptowy oparty na Jawa z Krypt. Jego cechą szczególną jest połączenie w jedno deklaracji i implementacji klas oraz instancji obiektu tych klas. Czyli klasę definiuje się w miejscu wystąpienia obiektu w trakcie uruchomienia. TAKIEGO SZALEŃSTWA NIE MA NIGDZIE INDZIEJ!!! Komunikacja między C++ i Jawa z Krypt (w odmianie QML) jest możliwa, ale potwornie trudna. Kontrolki QML nie umożliwiają nawet normalnej obsługi kliknięcia. Pomimo 3 prób komercyjnego użycia QML dla mnie jest on tak nienormalny, że nie jestem w stanie go używać.

Model biznesowy Qt:
- Tak jak wspomniałem Trolltech nigdy nie przynosił dochodów właścicielom. Coś ok. 2020 qt.io chwaliło się że ma 1M aktywnych programistów. Czy teraz są dochody? Chyba nie, bo rozwój bib. Qt od czasów Noki stoi w miejscu.
- Wariacki model biznesowy qt.io polega na udostępnianiu wszystkiego za darmo, a na licencji komercyjnej nie oferowanie niczego więcej (bo kompilator Qt Quick to jakiś żart). Tak wygląda oferta qt.io dziś w nie. 2023-08-20 patrząc na tabelkę subskrypcji na s. WWW qt.io/pricing .
+ Moim zdaniem za darmo należało udostępniać biblioteki (w terminologii Qt to moduły) jakie służą do nauki programowania w szkole i na uczelni. Natomiast od pracujących i firm należy pobierać opłatę i oferować dodatkowe biblioteki (moduły) jakie są niezbędne do szybkiego tworzenia prof. oprogramowania komercyjnego.

Uzasadnienie:
+ Uczniowie i studenci starają się opanować umiejętności niezbędne do podjęcia pracy. Ucząc się postępują moralnie i na tym etapie życia nie zarabiają. Uczniowie i studenci potrzebują czegoś co jest do zrozumienia i uczy czegoś przydatnego w przyszłej pracy. Dlatego dla uczniów i studentów należy udostępnić podstawowe bibl. Qt: obsługa plików i i kat., obsługa wątków, obsługa plików INI, podst. kontrolki graf., bazy SQL (z jedną wtyczką do SQLite), sieć IP (jednak wyłącznie do wymiany surowych danych, czyli bez obsługi HTTP ani FTP), port szeregowy (do nauki przyszłych elektroników), drukowanie.
+ Klienci komercyjni mają zupełnie inne potrzeby. Im chodzi o prostotę i szybkość programowania i są skłonni za to zapłacić. Dlatego na pewno docenią gotowe moduły wysokiej jakości takie jak np. OpenGL, geolokalizacja, bluetooth, żyroskop, edycja dok. ODT i ODS, wyświetlanie plików HTML i PDF, Json, XML, CSV, gotowe wtyczki SQL do popularnych baz danych, protokoły HTTP, FTP, CAN. Tego jest i będzie coraz więcej! Tu jest miejsce na biznes!

Celowo popsute rzeczy w bib. Qt (mowa tu o tym co można używać z poziomu C++):

- QApplication::exec() można wywołać jedynie z f. main(). Wywołanie z QApplication::exec() z innej f. kończy się zawieszeniem prog. Aby coś takiego zakodować na prawdę trzeba się postarać! PRAWDOPODOBNIE WYMUSZA SIĘ TO W CELU ANALIZY KRADZIONEGO KODU. Na razie nie znalazłem na to obejścia;

- W okienkowym programie Qt musi istnieć obiekt z oknem głównym. Jak się zamknie okno główne cały program się zamyka. Czyli nie można zrobić nawet kl. LogikaProgramu jaka najpierw otwiera okno konfiguracji, zamyka je, potem otwiera okno gł., zamyka je i na koniec wyświetla okno podsumowania. PRAWDOPODOBNIE WYMUSZA SIĘ TO W CELU ANALIZY KRADZIONEGO KODU. Na razie nie znalazłem na to obejścia;

- Kl. QWebEngine: Ta kl. jest następcą QWebKit. Ten QWebKit był funkcjonalny i dawał dobrą kontrolę nad wyświetlaną stroną HTML. Wiem to z mojego pryw. proj. TotalCzat w którym kontrolką QWebKit wyświetlałem wiadomości użytkowników. QWebEngine został wprowadzony do Qt od razu po mojej publikacji TotalCzat w sieci Internet w 2011r. (dodatkowo wkrótce po tym, w 2012r. wyłączono też serwer poczat.pl jakiego używał mój TotalCzat - zrobił to właściciel czyli Gadu-Gadu). QWebEngine nie ma wielu f. jakie miał QWebKit. W dodatku komunikacja między C++ i skryptem Jawa z Krypt jest możliwa, ale potwornie trudna. ROBI SIĘ TO BY DOPROWADZIĆ PROGRAMISTÓW C++ DO SZALEŃSTWA PRZEZ UŻYWANIE WARIACKICH API. Na razie nie znalazłem na to obejścia;

- Z poziomu C++ nie można używać kl. QML. Jest to sztuczne ograniczenie bo te kl. i tak są kodowane w C++. Te kl. QML mają jedną zaletę: są dostosowane do ekranów dotykowych (sprytne tel. i tablety). ROBI SIĘ TO BY DOPROWADZIĆ PROGRAMISTÓW C++ DO SZALEŃSTWA PRZEZ ZMUSZANIE ICH DO PORZUCENIA PRAWIE NORMALNEGO J. C++ I DO KODOWANIA SZALONYM J. JAWA Z KRYPT (W WARIACKIEJ ODMIANIE QML). Jest na to obejście: standardowe kontrolki Qt można ostylować definiując własne pliki QSS (jest to rozw. wzorowane na CSS znane ze s. HTML). Jednak wymaga to dodatkowej pracy I TO W DODATKU ARTYSTYCZNEJ!!!. Na 100% jest to wykonalne, bo mam wdrożenia takich prog. (terminale płatnicze Posnet Pospay Online i Posnet Netpay)

- Właściwości w kl. dziedziczących po kl. QObject: Te właściwości są tylko po to by można było wystawić obiekty kl. Qt do j. skryptowych. W trakcie prog. w C++ z tych właściwości wcale się nie korzysta. TYLKO Z TEGO POWODU MOŻNA BYŁO STWORZYĆ POTWORA QML!

- Nie używanie w bib. Qt wyjątków. Zamiast nich używa się po prostu wart. zwracanej. ROBI SIĘ TO BY DOPROWADZIĆ PROGRAMISTÓW C++ DO SZALEŃSTWA PRZEZ CIĄGŁE WKLEPYWANIE TEGO SAMEGO KODU DO OBSŁUGI BŁĘDÓW. Na to jest sposób: dziedziczenie kl. i przykrywanie f. kl. Qt własnymi f., które spr. kod błędu i rzucają wyjątek.
UWAGA: W materiałach propagandowych qt.io podaje się, że w czasach gdy zaczynano prace nad Qt nie było standardu C++, a drugiej strony starano się by Qt działała z jak największą l. kompilatorów (a później dodano, że chcą by Qt pracowała na jak największej l. platform). Ponad to argumentowano, że niektóre z tych kompilatorów miały problemy z prawidłową obsługą wyjątków.
Prace nad Qt zaczęto w 1991r. Wtedy już były wyjątki, bo wprowadzono je do C++ w 1990r. Wyjątki objął też pierwszy standard C++ jaki przyjęto w 1998r. No i teraz mamy już 2023r., czyli minęło 25lat, i dalej w qt.io twierdzą, że trzeba klepać w kółko ten sam kod obsługi błędów zwracanych przez wart.!
UWAGA: Dowodem na celowe nie używanie wątków w bib. Qt jest to, że w tym samym standardzie C++ z 1998r. wprowadzono szablony i przestrzenie nazw, które Qt wdrożyło w kodzie bibl.! Więc szablony i przestrzenie nazw można było wdrożyć, a wyjątków nie?

- Wyliczenia w QSizePolicy są podane dokładnie odwrotnie od ich znaczenia. ROBI SIĘ TO BY DOPROWADZIĆ PROGRAMISTÓW C++ DO SZALEŃSTWA PRZEZ PODWÓJNE MYŚLENIE TYPU: CZARNE JEST BIAŁE, A BIAŁE CZARNE. Dlatego zrobiłem takie obejście:
klasa Skalowanie : publiczne QSizePolicy
{
publiczne:
wylicz Sposoby
{
wMaks = QSizePolicy::MinimumExpanding,
wMin = QSizePolicy::Maximum,
wStala = QSizePolicy::Fixed
};
};

- QSqlDatabase nie można awaryjnie zamknąć. Chodzi o to, że nie można po prostu zerwać poł. z bazą danych. A może być to konieczne, np. do przerwania długiego zapytania SQL (np. gdy użytkownik włączy generowanie długiego raportu i zdecyduje się go przerwać po tym jak się wścieknie długim czekaniem). Blokadę swobodnego tworzenia obiektów w C++ uzyskuje się definiując w kl. statyczne f. tworzące i zamykające poł. bazodanowe. JEST TO ROBIONE PO TO BY UTRUDNIAĆ ŻYCIE PROGRAMISTOM. Na razie nie znalazłem na to obejścia;

- W sklepie marketplace.qt.io są biblioteki i narzędzia jakie można dokupić do Qt. Jest to b. dobry pomysł. Jednak przez skurwiałą politykę nie da się tego sklepu używać:
1. Wspierane są tylko najnowsze wer. bib. Qt. Ja kupowałem bib. QtPdfViewer i mogłem go używać wyłącznie z ost. wer. Qt5 czyli Qt5.15.xx albo z nie w pełni funkcjonalną, wczesną wer. Qt6. Jest to kompletnie nie uzasadnione technicznie, bo qt.io chwali się, że wszystkie wydania Qt5 są programowo i binarnie kompatybilne - API i ABI są zgodne (wyjątkiem był jakiś fakap w jednym z wczesnych wydań Qt5 - z tego co pamiętam chyba to było Qt5.1.xx);
2. Produkty z tego sklepu można instalować jedynie instalatorem od qt.io . Tak więc nie można zintegrować tych dodatków z sys. Linuks (razem z którym jest instalowana bib. Qt). A robi się to istotne w momencie gdy w swoich proj. chcemy bazować na Qt z systemu. Ma to znaczenie w sytuacji gdy prowadzimy własne proj. i modyfikujemy źródła w prog. dostarczanych z distro. Własne proj. łatwo przestawić na Qt w innym kat. Natomiast przerabianie skryptów budowania prog. dostarczanych z distro to masakra.