info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Raport Totaliztyczny: 7. Sprawa qt.io
55 views
Skip to first unread message
Jacek Marcin Jaworski
Aug 20, 2023, 11:42:21 AM8/20/23
to
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.
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.
Jacek Marcin Jaworski
Aug 20, 2023, 1:24:36 PM8/20/23
to
niedziela, 20 sierpnia 2023 o 17:42:21 UTC+2 Jacek Marcin Jaworski napisał(a):
Pow. jest:
Trolltech nigdy nie przynosił zysków.
Pow. jest:
> Trolltech nigdy nie przynosił dochodów.
Powinno być:
Trolltech nigdy nie przynosił zysków.
Jacek Marcin Jaworski
Aug 20, 2023, 1:40:40 PM8/20/23
to
niedziela, 20 sierpnia 2023 o 17:42:21 UTC+2 Jacek Marcin Jaworski napisał(a):
Jest:
> - Tak jak wspomniałem Trolltech nigdy nie przynosił dochodów właścicielom.
Powinno być:
- Tak jak wspomniałem Trolltech nigdy nie przynosił zysków właścicielom.
Jacek Marcin Jaworski
Aug 20, 2023, 1:41:58 PM8/20/23
to
niedziela, 20 sierpnia 2023 o 17:42:21 UTC+2 Jacek Marcin Jaworski napisał(a):
Jest:
Jest:
> - 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;
Powinno być:
- QSqlDatabase nie można awaryjnie zamknąć przez zwykłe wywołanie destruktora. Chodzi o to, że w Qt jest zabezpieczenie by 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 i niszczenia obiektów w C++ uzyskuje się definiując w kl. statyczne f. tworzące i niszczące obiekty. JEST TO ROBIONE PO TO BY UTRUDNIAĆ ŻYCIE PROGRAMISTOM. Na razie nie znalazłem na to obejścia;
Jacek Marcin Jaworski
Aug 20, 2023, 4:42:48 PM8/20/23
to
niedziela, 20 sierpnia 2023 o 17:42:21 UTC+2 Jacek Marcin Jaworski napisał(a):
Jest:
> Czy teraz są dochody?
Jest:
Powinno być:
Czy teraz są zyski?
Arnold Ziffel
Aug 21, 2023, 11:00:50 PM8/21/23
to
Jacek Marcin Jaworski <jawors...@adres.pl> wrote:
>> Czy teraz są dochody?
>
> Powinno być:
> Czy teraz są zyski?
https://www.templetons.com/usenet-format/supersedes.html
>> Czy teraz są dochody?
>
> Powinno być:
> Czy teraz są zyski?
--
- Skąd ma pan takiego siniaka na głowie?
- Byłem u lekarza. Na łupież zalecił mi nacierać włosy wodą
toaletową. Nacierałem, nacierałem, aż w końcu deska sedesowa spadła mi
na głowę.
Arnold Ziffel
Aug 21, 2023, 11:01:50 PM8/21/23
to
> 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.
TLDR?
> 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.
--
Lekarz rozmawia z pacjentem - nałogowym palaczem.
- Czy nie może pan obejść się bez papierosów? Czy sprawiają panu aż
taką przyjemność?
- Oczywiście. Ilekroć zapalę, teściowa wychodzi z pokoju.
Jacek Marcin Jaworski
Nov 25, 2023, 10:14:23 AM11/25/23
to
7. Raport Totaliztyczny: Sprawa qt.io
autor:
Jacek Marcin Jaworski
pseudonim:
Energo Koder Atlant
pomocnicy autora:
BRAK
miejsce:
Pruszcz Gd.
utworzono:
2023-08-20
wersja: 277 z dnia:
2023-11-25
program składu:
Libre Office Writer
sys. op.:
Kubuntu
Spis treści
1 Wstęp 3
1.1 Teza 3
1.2 Streszczenie 3
1.3 Słownik Pojęć 3
2 Metoda badawcza 4
3 Fakty 4
3.1 Czym jest bibl. Qt? 4
3.2 Obecny stan prac nad Qt: 5
3.3 Czym jest QML? 5
3.4 Obecny model biznesowy qt.io 6
3.5 Rozwiązania celowo popsute w bibl. Qt (mowa tu o tym co można używać z poziomu C++): 6
4 Jakie wsk. moralnej poprawności "są na tak" a jakie "są na nie" wzg. proj. qt.io 8
5 Analiza proj. XXX w świetle wsk. moralnej poprawności zwanym Ekonomia i własne utrzymanie 9
6 Podsumowanie 10
6.1 Rewelacje, zalety, wady i partactwa w proj. qt.io 10
6.1.1 Rewelacje 10
6.1.2 Zalety 10
6.1.3 Wady 11
6.1.4 Partactwa 11
6.2 Wnioski 11
6.3 Przewidywania na przyszłość 12
6.4 Zalecenia na teraz 12
6.5 Zalecenia na przyszłość 12
7 Bibliografia 13
1 Wstęp
qt.io dostarcza wieloplatformową bibliotekę programistyczną Qt dla języka C++. W latach 1991-2008 bibl. Qt w j. C++ zakodowała norweska firma Quasar, później zwana Trolltech. W 2008r. została ona sprzedana fińskiej firmie Nokia. W marcu 2011r. Nokia sprzedała dział Qt innej fińskiej firmie Digia. W paź. 2014r. z firmy Digia wydzielono Qt Company. W 2016r. Digia i Qt Company całkowicie się rozdzieliły (jest to nonsens, bo przecież wtedy ktoś musiałby nabyć udziały Qt Company, jednak nabywcy nie ujawniono).
Wiadomo, że Trolltech nigdy nie przynosił zysków1.
1.1 Teza
Bibl. Qt jest najważniejszą bibl. dla j. C++. qt.io to hamulcowy rozwoju biblioteki Qt. qt.io robi programistom wodę z mózgu promując j. QML. Należy rozwidlić bibliotekę Qt by można z niej normalnie korzystać w C++.
1.2 Streszczenie
Bibl. Qt zawiera niezbędne kl. do tworzenia prog. w C++. Zawiera też bezużyteczne moduły. W bibl. Qt kl. dostępne z j. C++ są zaniedbane: błędy nie są naprawiane, wygląd i zachowanie kontrolek nie odpowiada dzisiejszym standardom. W Qt są prog. i kl. celowo popsute, tak by nękać i odganiać programistów od C++. Aktualny model biznesowy qt.io wyklucza zarabianie na bibl. i prog. Qt. Analiza w świetle wsk. moralnej popr. daje jednoznacznie negatywny wynik.
1.3 Słownik Pojęć
dok.
dokument
SZAP
w j. ang. USONA
j.
język
bibl.
biblioteka
kl.
klasa
f.
funkcja
graf.
grafika
wyśw.
wyświetlanie
dom.
domyślnie
zach.
zachowanie
konf.
konfiguracja
rozw.
rozwiązania
podst.
podstawowe
2 Metoda badawcza
Opieram się przede wszystkim na swoim ponad 25 letnim (od 1998r.) doświadczeniu w programowaniu w C++ z czego ponad 13 lat (od ok. 2010r.) z użyciem Qt. W dalszej kol. opieram się na art. w sieci Internet.
3 Fakty
3.1 Czym jest bibl. Qt?
Qt to wieloplatformowa bibl. zakodowana w C++. Jest podzielona na kilka mniejszych bibliotek:
• podst. kontrolki graf.;
• kontrolka OpenGL: można wyświetlić w oknie Qt scenę OpenGL;
• bazy SQL: łączenie z bazami SQL i wykonywanie zapytań, jednak bez żadnych mechanizmów serializacji danych (kl.->baza i baza->kl.);
• sieć IP;
• port szeregowy;
• geolokalizacja;
• drukowanie;
• dźwięk;
• kl. do parsowania i zapisu 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);
• Przydatnym (choć prostym) uzupełnieniem jest QtTest: do tworzenia testów jednostkowych.
Co dziwne wyodrębniono też moduł QSvg (moim zdaniem powinna to być zwykła wtyczka do renderowania obrazków).
• QtRemote: tajemnicza bibl. 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 – od tamtej pory wmawia się nam że do prog. interfejsów dotykowych jest QML i że C++ „się nie nadaje”;
• QWebView: stary silnik wyświetlania plików HTML. Cechował się on dużymi możliwościami i wygodnym API;
• QWebEngine: nowy silnik wyśw. plików HTML. Mimo że powinien on mieć API w 100% kompatybilne z QWebView, to ma on zupełnie inne API – dosłownie wygląda to tak jakby ktoś stwierdził, że QWebView jest zbyt prosty w użyciu.
W przeciwieństwie do QWebView QWebEngine nigdy nie został podczepiony do listy kontrolek Qt Designer. Zrobiono to prawdopodobnie z powodu niestabilności QWebEngine.
3.2 Obecny stan prac nad Qt:
Od 2008r, czyli od sprzedaży Trolltech firmie Nokia bibl. Qt praktycznie nie jest rozwijana (innymi słowy proj. jest mrożony). Nie chodzi mi o to że nie dają nam za darmo nowych modułów do C++, chodzi mi o to, że:
• Jest b. mało dostępnych gotowych stylów QSS2 dla „normalnych” kontrolek dostępnych z C++;
• Nie ma wcale dostępnych gotowych stylów QSS dla twórców prog. w C++ dla ekranów dotykowych;
• Nie wiadomo do własnych, nowych kontrolek tworzyć nowe style QSS;
• Zarządzanie oknami w kl. QMdiArea oraz QDockWidget (dostępnych z C++) jest od lat popsute. Należy uznać to za sabotaż qt.io mający zniechęcać do tworzenia „normalnych” prog.;
• Dom. zach. kontrolek (dostępnych z C++) jest już przestarzałe (niezgodne z intuicją), przez co zawsze wymagają one dodatkowej pracy. Np. kl. QTreeWidget mimo że węzły i liście w tej kontrolce oparte są o kl. QTreeWidgetItem i ma ona 3 stany zaznaczania, to dom. nie są one używane. Podczas gdy normalne było by zaznaczanie węzłów jako Qt::PartiallyChecked gdy część liści jest zaznaczona a część nie.
Zamiast tego wszystkiego od 2009r. wśród programistów C++ używających bibl. Qt promuje się potwora QML opartego o język skryptowy Jawa Skrypt.
Swoistym potwierdzeniem braku prac nad Qt jest brak aktualizacji firmowej s. WWW [0] na temat proj. Qt (ost. wpis dot. 20 lecia Qt jakie obchodzono w 2015r.).
3.3 Czym jest QML?
QML jest to zdegenerowany j. skryptowy oparty na Jawa Srypt. QML reklamuje się, jako j. szybkiego tworzenia aplikacji które mogą tworzyć nie tylko zawodowi programiści ale też projektanci. Ale to fikcja. Cechą szczególną QML 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 Srypt (w odmianie QML) jest możliwa, ale potwornie trudna. Kontrolki QML nie umożliwiają nawet normalnej obsługi kliknięcia.
- Tak jak wspomniałem we wstępie, Trolltech nigdy nie przynosił zysków właścicielom;
- Jak podano w wikipedia.org na s. [0]:
„In 2017, the Qt Company estimated a community of about 1 million developers worldwide[17] in over 70 industries.[18]”
Czy teraz są zyski? Chyba nie, bo od przejęcia przez f. Nokia rozwój bibl. Qt stoi w miejscu (nie naprawiają nawet poważnych błędów w kluczowych kl. - jw.).
- 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-11-25 patrząc na tabelkę subskrypcji na s. WWW [0].
- W sklepie marketplace.qt.io są bibl. i prog. 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. bibl. Qt. Ja kupowałem bibl. 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 ma zasadę, że wszystkie wydania Qt5 są programowo i binarnie kompatybilne - API i ABI są zgodne;
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 bibl. 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 w paczkach z distro to masakra.
3.5 Rozwiązania celowo popsute w bibl. Qt (mowa tu o tym co można używać z poziomu C++):
• jw.: Zarządzanie oknami w kl. QMdiArea oraz QDockWidget jest od lat popsute. Należy uznać to za sabotaż wobec twórców „normalnych” prog.;
• jw.: Wygląd i dom. zachowanie kontrolek jest niezgodne z intuicją i przestarzałe, przez co zawsze wymagają one dodatkowej pracy;
• jw.: Wariackie API kl. QWebEngine kl. do renderowania s. HTML;
• 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).
To nachalne wpychanie QML można obejść: standardowe kontrolki Qt można ostylować definiując własne pliki QSS. 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).
• Nie używanie w bibl. Qt wyjątków. Zamiast nich używa się po prostu wart. Zwracanej.
Dowodem na celowe nie używanie wątków w bibl. 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 JEST CZARNE.
Znam obejście tego prob.:
#define wMaks QSizePolicy::MinimumExpanding
#define wMin QSizePolicy::Maximum
#define wStala QSizePolicy::Fixed
• 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 nawet nie można zrobić 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;
• QSqlDatabase nie można awaryjnie zamknąć przez zwykłe wywołanie destruktora. W Qt jest zabezpieczenie by 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ę tą uzyskano f. statycznymi (działają one w oparciu o zmienne globalne w pliku C++). JEST TO ROBIONE PO TO BY UTRUDNIAĆ ŻYCIE PROGRAMISTOM. Na razie nie znalazłem na to obejścia;
• 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 udostępniać obiekty kl. Qt j. skryptowym. W trakcie prog. w C++ z tych właściwości wcale się nie korzysta. WŁAŚCIWOŚCI W KL. QT SĄ TYLKO PO TO BY MOŻNA BYŁO STWORZYĆ POTWORA QML! Na razie nie znalazłem na to obejścia.
4 Jakie wsk. moralnej poprawności "są na tak" a jakie "są na nie" wzg. proj. qt.io
Wsk.
Skrótowa analiza zagadnienia
Ocena
Pole moralne
Sprzeczne z wsk. pole moralne jest psucie istniejących kl., nie naprawianie zgłaszanych błędów, nie ulepszanie i nie dostosowywanie bibl. Qt do dzisiejszych urządzeń.
NIE
Karma
Wciskanie popsutych bibl. C++ i ogłupiającego j. QML to łamanie wsk. karma.
NIE
Praca Moralna
Brak prac nad Qt w kontekście C++ to oznaka braku pracy.
NIE
Uczucia
Nie wiadomo co czują pracownicy qt.io .
BRAK
Motywacje
Brak prac nad Qt w kontekście C++ to oznaka lenistwa. Chęć zniszczenia cudzego umysłu, to z kolei szataństwo.
NIE
Odpowiedzialność
Sabotowanie całego proj. bibl. Qt, to zupełny brak poczucia odpowiedzialności za siebie, oraz brak poczucia odpowiedzialności za tych którzy jej używają i brak poczucia odpowiedzialności za cywilizację która ma używać prog. stworzonych z użyciem tej bibl.
NIE
Sumienie
Widać, że decydenci w qt.io chcący zniszczyć umysły programistom C++ nie mają wcale sumienia.
NIE
Ekonomia i własne utrzymanie
Po analizie modelu biznesowego qt.io widać, że biorąc nieskończone kredyty łamią zasady ekonomii i nie chcą sami zarabiać na własne utrzymanie.
NIE
Uczciwość
Cytat z [0]:„A więc: poznacie ich po owocach”. No te owoce są popsute, brzydkie, przestarzałe i ogłupiające.
NIE
Solidność
Tolerowanie błędów w swoich publikacjach jest sprzeczne z wsk. solidność.
NIE
Braterstwo
Dążenie do niszczenia umysłów innych ludzi jest skrajnym łamaniem wsk. braterstwo!
NIE
Kompetencje
Z jednej s. wklepano 30.703.306 linii kodu (do wer. Qt 5.12.12 włącznie), a toleruje się liczne błędy. Te błędy w wielu przypadkach uniemożliwiają użycie danej kl., np. QMdiArea i QDockWidget. Wygląda to tak, jakby kompetencje były, ale niewystarczające.
NIE
Występowanie NIE i BRAK w kol. „Ocena” oznacza, że jest jednomyślność wsk. moralnej popr. (przy braku wskazania wsk. Uczucia). Dlatego cały proj. qt.io jest niemoralny.
5 Analiza proj. XXX w świetle wsk. moralnej poprawności zwanym Ekonomia i własne utrzymanie
Pierwotni założyciele projektu Qt nigdy nie przejmowali się ekonomią, bo Trolltech nigdy nie zarabiał na siebie. Dziś rzekomo mamy 1M aktywnych programistów używających Qt, ale mogę się założyć o stówę, że qt.io nie zarabia na siebie. Świadczą o tym wspomniane pow. fakty:
1. Nonsensowna i demotywująca polityka subskrypcji;
2. Nonsensowne rozw. tech. w sklepie marketplace.qt.io powodują, że nie ma mowy by czegokolwiek z tego sklepu używać na sys. Linuks. A sys. Linuks jest dziś najlepszą platformą dostępną dla cywilnych programistów;
3. Nonsensowny marketing (coś jak w Commodore w latach 1985-1994, czyli po wygnaniu założyciela Idka Trzmiela). Zupełny brak obecności w mediach: likwidacja Qt Quarterly (z końcem 2011r.), zero art. sponsorowanych w gazetach i serwisach WWW, zero info o wdrożeniach komercyjnych, zero przykładów wzorcowych. Jedynie na blogu zamieszczają komunikaty typu: „Wyszła nowa wer. Qt X.XX.0, nowości brak.”, albo „Wyszła nowa wer. Qt Creator XX.0, nowości brak.”.
4. Braki ideologiczne: ładują bez ograniczeń kasę w patologię (QML) zamiast programować w j. C++, który jest najbardziej normalny w tym całym szaleństwie. Nawet gorzej, bo oni i tak kodują w C++ tworząc nowe kl. dla QML;
5. To ostatnie jest szerszym zjawiskiem w branży, bo wielkie korpo swoje narzędzia kodują w C++, natomiast innym podsuwają, często za darmo, jakieś własne, patologiczne wynalazki. Tym samym Qt dołącza do takich właśnie diabelskich korpo.
Pow. fakty jednoznacznie świadczą o łamaniu wsk. moralnej popr. Zwanego Ekonomia i własne utrzymanie. Dlatego w świetle tego wsk. proj. qt.io jest niemoralny.
6 Podsumowanie
Biblioteka Qt od momentu przejęcia norweskiej firmy Trolltech przez fińską firmę Nokia praktycznie nie jest rozwijana. Jest tak na przekór postępów w el. w tym np. pojawieniu się sprytnych tel. i tabletów z dotykowymi interfejsami użytkownika.
Aby wspierać nowe interfejsy dotykowe opracowano potwora QML jaki jest zaprzeczeniem filozofii Qt i C++. Dlatego QML jest kompletnie nie do przyjęcia dla programistów C++.
Model biznesowy qi.io to fikcja: zarówno oferta subskrypcji, jak zasada działania sklepu marketplace.qt.io. Nawet mi nasuwają się różne pomysły jak na tej bibl. można zarabiać. Obecnie już nawet nie wiadomo do kogo należy Qt Company. Dlatego należy powiedzieć w prost, że qt.io jest utrzymywana przez niejawnego sponsora. I że ten sponsor celowo chce psuć umysły programistów C++ i dla niego jest to ważniejsze niż dochodowy biznes. qt.io to trojan.
6.1 Rewelacje, zalety, wady i partactwa w proj. qt.io
6.1.1 Rewelacje
1. BRAK
6.1.2 Zalety
1. Wybranie przez twórców bibl. Qt j. C++;
2. W 2023r. bibl. Qt ciągle jest dostępna.
6.1.3 Wady
1. Prog. takie jak Qt Creator i Qt Assistant są uciążliwe w użyciu 3;
2. Zbędne właściwości w kl. dziedziczonych po QObject.
6.1.4 Partactwa
1. Brak aktualizacji wyglądu (brak nowych stylów QSS) i zachowania kontrolek w bibl. Qt;
2. Brak możliwości rozszerzania sys. styli QSS (tak by można je było w nowo tworzonych kontrolkach);
3. Brak naprawy popsutych kluczowych kl. (takich jak wspomniane QMdiArea i QDockWidget);
4. Niemożność w kwestii użycia wyjątków;
5. Niemożność w kwestii udostępnienia kl. QML na poziomie C++;
6. Brak możliwości integracji zakupionych bibl. w maketplace.qt.io z sys. Linuks.
7. Nonsensowny marketing;
8. Nonsensowny model biznesowy;
9. Krecia robota przeciwko społeczności programistów C++ (np. QSizePolicy, albo QApplication::exec()).
6.2 Wnioski
Na przekór braku rozwoju Qt nie ma nic porównywalnego do tej bibl. (a przynajmniej ja o niczym takim nie słyszałem).
Czy jesteśmy skazani na Qt? W polskich warunkach niestety tak, wynika to z faktu braku środków do napisania porównywalnej bibl. bez wad Qt.
Wątpliwy jest sens przepisywania Qt od zera wynika to z wad C++:
- Braku ABI;
- Brak działania f. wirt. w konstruktorach i destruktorach;
- Brak dziedziczenia operatorów;
- Brak wybierania najlepszego dopasowania typów, gdy pojawia się jakakolwiek niejednoznaczność (przekleństwo ambigous).
By naprawić te wady konieczne jest niewielkie zmodyfikowanie kompilatora i zerwanie kompatybilności z obecnym kodem C++. Dopiero wtedy należało by stworzyć następcę Qt.
Wątpliwy jest też sens przepisywania Qt od zera w j. D wynika to z wady j. D:
- D ma format plików źródłowych w modelu Asemblera (poł. deklaracji i definicji f.) a nie w modelu j. C (osobne pliki dla deklaracji i definicji f.). Programowanie w j. D jest procesem odwrotnym do programowania w j. C i C++: w j. D najpierw koduje się definicję f. i dopiero później można wygenerować plik nagłówkowy z deklaracjami tych f. Każdy programista C i C++ potwierdzi, że to nienormalny sposób pracy (tak samo jak programowanie sterowane przez testy). Wadą plików źródłowych w modelu j. C/C++ jest puchnięcie kodu o 100% w porównaniu do j. D i Pyton (sprawdziłem to kodując w tych j. przykładowy programik).
6.3 Przewidywania na przyszłość
qt.io najprawdopodobniej dalej będzie cudakować z j. QML. Będą się pojawiać nowe błędy w kl. dostępnych z C++. qt.io dalej będzie dalej udawać, że marketing nie jest do niczego potrzebny i dalej będzie cudakować ze swoim modelem biznesowym i udawać, że jest firmą komercyjną. Wszystko to po to by niszczyć programistów C++ (bo my wiemy, że ten język jest najlepszy do programowania prog., choć nie jest idealny).
6.4 Zalecenia na teraz
Zalecenia dla programistów indywidualnych:
• Nie należy się pakować w QML bo jest to sprzeczne z ustawą o ochronie zdrowia psychicznego!;
• Dalej kodować w C++ i Qt.
• Izolować własny kod C++ od kodu bibl. Qt. W tym celu używane kl. Qt należy przezywać używając dyrektyw using i #define. Robimy to po to, by w razie konieczności przezwaną kl. rozwijać je jako typy pochodne od tych przezwanych kl.
Zalecenia dla polskich firm, oprócz pow. dodatkowo:
• Należy ostylować w QSS kontrolki Qt tak by dało się je używać na sys. z ekranami dotykowymi. Wymaga to też pewnej pracy programistycznej dotyczącej obsługi kliknięć (w Qt kliknięcie jest punktowe a na ekranach dotykowych powinno działać w określonym promieniu). To na 100% działa, bo już wdrożył nieistniejący Posbit.pl (jeszcze dziś, 2023-08-21, można to zobaczyć w terminalach płatniczych Posnet Pospay Online i Posnet Netpay).
6.5 Zalecenia na przyszłość
Zalecenie dla społeczności polskich programistów C++:
• Należy rozwidlić4 proj. Qt oraz poprawić w. wymienione wady Qt;
• Z rozwidlenia Qt należy usunąć QtScript i QML;
• Z rozwidlenia Qt należy się pozbyć całego kodu wynikającego z udostępniania Qt w j. innych niż C++ (właściwości). Nie ma sensu wlec tego balastu.
Rozwidlenie Qt nie będzie możliwe do użycia w mikrokontrolerach, bo w nich nie ma bibliotek współdzielonych jakich dystrybucji wymaga licencja LGPL.
Jednak użycie Qt w mikrokontrolerach i tak jest trochę bez sensu, bo Qt nie jest bibl. czasu rzeczywistego (bo jest oparta o pętlę zdarzeń, która nie gwarantuje kiedy zdarzenie zostanie obsłużone).
• Oferta komercyjnej subskrypcji rozwidlenia Qt powinna być tak atrakcyjna, że uzasadniała by ponoszone koszty. Np.: Na licencji LGPL dostępne były by konieczne narzędzia, ale tylko konsolowe. Natomiast na licencji komercyjnej udostępniane były by wygodne narzędzia5 z interfejsem graf. (w rodzaju obecnych Qt Creator, Qt Designer, Qt Linguist i Qt Assistant). Nie ma przy tym obawy o konkurencję ze s. obecnych narzędzi graf. od Qt: one też są nienormalne i popsute i wystarczy parę minut poklikać i już jest mnóstwo pomysłów jak je można by naprawić i rozwinąć. Jednak tego typu narzędzia należy zakodować od zera (ze względu na niską jakość ich kodu oraz z powodu zapewnienia sobie do nich pełnych praw autorskich);
• Należy stworzyć sklep z dodatkami dla rozwidlonego Qt, tak by udostępniać w nim dodatkowe bibl. i prog. na komercyjnych zasadach. Pomysłów jest mnóstwo: kl. do edycji dok. ODT i ODS, kl. do wyświetlania plików HTML, PDF i innych, wtyczki SQL do popularnych baz danych, bazy no-sql, hurtownie danych, popularne protokoły: HTTP, FTP, CAN, RS. Tego jest i będzie coraz więcej! Tu jest miejsce na biznes!
• Należy dbać o to by społeczność mogła też się włączyć do tego interesu. W tym celu należy zdefiniować proste zasady i jasne kryteria techniczne i biznesowe jakie pozwalają na opublikowanie rozszerzeń dla rozwidlonego Qt.
7 Bibliografia
Bibliografia
1: , Qt History, 2018, wiki.qt.io/Qt_History
2: , Qt (software), 2023, https://en.m.wikipedia.org/wiki/Qt_(software)
3: , Pricing and Packaging | Software Stack | Tech Stack | Qt, , qt.io/pricing
4: św. Mateusz, Biblia Tysiąclecia, 2002
autor:
Jacek Marcin Jaworski
pseudonim:
Energo Koder Atlant
pomocnicy autora:
BRAK
miejsce:
Pruszcz Gd.
utworzono:
2023-08-20
wersja: 277 z dnia:
2023-11-25
program składu:
Libre Office Writer
sys. op.:
Kubuntu
Spis treści
1 Wstęp 3
1.1 Teza 3
1.2 Streszczenie 3
1.3 Słownik Pojęć 3
2 Metoda badawcza 4
3 Fakty 4
3.1 Czym jest bibl. Qt? 4
3.2 Obecny stan prac nad Qt: 5
3.3 Czym jest QML? 5
3.4 Obecny model biznesowy qt.io 6
3.5 Rozwiązania celowo popsute w bibl. Qt (mowa tu o tym co można używać z poziomu C++): 6
4 Jakie wsk. moralnej poprawności "są na tak" a jakie "są na nie" wzg. proj. qt.io 8
5 Analiza proj. XXX w świetle wsk. moralnej poprawności zwanym Ekonomia i własne utrzymanie 9
6 Podsumowanie 10
6.1 Rewelacje, zalety, wady i partactwa w proj. qt.io 10
6.1.1 Rewelacje 10
6.1.2 Zalety 10
6.1.3 Wady 11
6.1.4 Partactwa 11
6.2 Wnioski 11
6.3 Przewidywania na przyszłość 12
6.4 Zalecenia na teraz 12
6.5 Zalecenia na przyszłość 12
7 Bibliografia 13
1 Wstęp
qt.io dostarcza wieloplatformową bibliotekę programistyczną Qt dla języka C++. W latach 1991-2008 bibl. Qt w j. C++ zakodowała norweska firma Quasar, później zwana Trolltech. W 2008r. została ona sprzedana fińskiej firmie Nokia. W marcu 2011r. Nokia sprzedała dział Qt innej fińskiej firmie Digia. W paź. 2014r. z firmy Digia wydzielono Qt Company. W 2016r. Digia i Qt Company całkowicie się rozdzieliły (jest to nonsens, bo przecież wtedy ktoś musiałby nabyć udziały Qt Company, jednak nabywcy nie ujawniono).
Wiadomo, że Trolltech nigdy nie przynosił zysków1.
1.1 Teza
Bibl. Qt jest najważniejszą bibl. dla j. C++. qt.io to hamulcowy rozwoju biblioteki Qt. qt.io robi programistom wodę z mózgu promując j. QML. Należy rozwidlić bibliotekę Qt by można z niej normalnie korzystać w C++.
1.2 Streszczenie
Bibl. Qt zawiera niezbędne kl. do tworzenia prog. w C++. Zawiera też bezużyteczne moduły. W bibl. Qt kl. dostępne z j. C++ są zaniedbane: błędy nie są naprawiane, wygląd i zachowanie kontrolek nie odpowiada dzisiejszym standardom. W Qt są prog. i kl. celowo popsute, tak by nękać i odganiać programistów od C++. Aktualny model biznesowy qt.io wyklucza zarabianie na bibl. i prog. Qt. Analiza w świetle wsk. moralnej popr. daje jednoznacznie negatywny wynik.
1.3 Słownik Pojęć
dok.
dokument
SZAP
w j. ang. USONA
j.
język
bibl.
biblioteka
kl.
klasa
f.
funkcja
graf.
grafika
wyśw.
wyświetlanie
dom.
domyślnie
zach.
zachowanie
konf.
konfiguracja
rozw.
rozwiązania
podst.
podstawowe
2 Metoda badawcza
Opieram się przede wszystkim na swoim ponad 25 letnim (od 1998r.) doświadczeniu w programowaniu w C++ z czego ponad 13 lat (od ok. 2010r.) z użyciem Qt. W dalszej kol. opieram się na art. w sieci Internet.
3 Fakty
3.1 Czym jest bibl. Qt?
Qt to wieloplatformowa bibl. zakodowana w C++. Jest podzielona na kilka mniejszych bibliotek:
• podst. kontrolki graf.;
• kontrolka OpenGL: można wyświetlić w oknie Qt scenę OpenGL;
• bazy SQL: łączenie z bazami SQL i wykonywanie zapytań, jednak bez żadnych mechanizmów serializacji danych (kl.->baza i baza->kl.);
• sieć IP;
• port szeregowy;
• geolokalizacja;
• drukowanie;
• dźwięk;
• kl. do parsowania i zapisu 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);
• Przydatnym (choć prostym) uzupełnieniem jest QtTest: do tworzenia testów jednostkowych.
Co dziwne wyodrębniono też moduł QSvg (moim zdaniem powinna to być zwykła wtyczka do renderowania obrazków).
Oprócz tego jest sporo w Qt bibliotek "robiących tłum":
• QtConcurrent: jakiś dziwny potworek do programowania równoległego;
• QtRemote: tajemnicza bibl. 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 – od tamtej pory wmawia się nam że do prog. interfejsów dotykowych jest QML i że C++ „się nie nadaje”;
• QWebView: stary silnik wyświetlania plików HTML. Cechował się on dużymi możliwościami i wygodnym API;
• QWebEngine: nowy silnik wyśw. plików HTML. Mimo że powinien on mieć API w 100% kompatybilne z QWebView, to ma on zupełnie inne API – dosłownie wygląda to tak jakby ktoś stwierdził, że QWebView jest zbyt prosty w użyciu.
W przeciwieństwie do QWebView QWebEngine nigdy nie został podczepiony do listy kontrolek Qt Designer. Zrobiono to prawdopodobnie z powodu niestabilności QWebEngine.
3.2 Obecny stan prac nad Qt:
Od 2008r, czyli od sprzedaży Trolltech firmie Nokia bibl. Qt praktycznie nie jest rozwijana (innymi słowy proj. jest mrożony). Nie chodzi mi o to że nie dają nam za darmo nowych modułów do C++, chodzi mi o to, że:
• Jest b. mało dostępnych gotowych stylów QSS2 dla „normalnych” kontrolek dostępnych z C++;
• Nie ma wcale dostępnych gotowych stylów QSS dla twórców prog. w C++ dla ekranów dotykowych;
• Nie wiadomo do własnych, nowych kontrolek tworzyć nowe style QSS;
• Zarządzanie oknami w kl. QMdiArea oraz QDockWidget (dostępnych z C++) jest od lat popsute. Należy uznać to za sabotaż qt.io mający zniechęcać do tworzenia „normalnych” prog.;
• Dom. zach. kontrolek (dostępnych z C++) jest już przestarzałe (niezgodne z intuicją), przez co zawsze wymagają one dodatkowej pracy. Np. kl. QTreeWidget mimo że węzły i liście w tej kontrolce oparte są o kl. QTreeWidgetItem i ma ona 3 stany zaznaczania, to dom. nie są one używane. Podczas gdy normalne było by zaznaczanie węzłów jako Qt::PartiallyChecked gdy część liści jest zaznaczona a część nie.
Zamiast tego wszystkiego od 2009r. wśród programistów C++ używających bibl. Qt promuje się potwora QML opartego o język skryptowy Jawa Skrypt.
Swoistym potwierdzeniem braku prac nad Qt jest brak aktualizacji firmowej s. WWW [0] na temat proj. Qt (ost. wpis dot. 20 lecia Qt jakie obchodzono w 2015r.).
3.3 Czym jest QML?
QML jest to zdegenerowany j. skryptowy oparty na Jawa Srypt. QML reklamuje się, jako j. szybkiego tworzenia aplikacji które mogą tworzyć nie tylko zawodowi programiści ale też projektanci. Ale to fikcja. Cechą szczególną QML 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 Srypt (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ć.
3.4 Obecny model biznesowy qt.io
- Tak jak wspomniałem we wstępie, Trolltech nigdy nie przynosił zysków właścicielom;
- Jak podano w wikipedia.org na s. [0]:
„In 2017, the Qt Company estimated a community of about 1 million developers worldwide[17] in over 70 industries.[18]”
Czy teraz są zyski? Chyba nie, bo od przejęcia przez f. Nokia rozwój bibl. Qt stoi w miejscu (nie naprawiają nawet poważnych błędów w kluczowych kl. - jw.).
- 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-11-25 patrząc na tabelkę subskrypcji na s. WWW [0].
- W sklepie marketplace.qt.io są bibl. i prog. 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. bibl. Qt. Ja kupowałem bibl. 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 ma zasadę, że wszystkie wydania Qt5 są programowo i binarnie kompatybilne - API i ABI są zgodne;
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 bibl. 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 w paczkach z distro to masakra.
3.5 Rozwiązania celowo popsute w bibl. Qt (mowa tu o tym co można używać z poziomu C++):
• jw.: Zarządzanie oknami w kl. QMdiArea oraz QDockWidget jest od lat popsute. Należy uznać to za sabotaż wobec twórców „normalnych” prog.;
• jw.: Wygląd i dom. zachowanie kontrolek jest niezgodne z intuicją i przestarzałe, przez co zawsze wymagają one dodatkowej pracy;
• jw.: Wariackie API kl. QWebEngine kl. do renderowania s. HTML;
• 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).
To nachalne wpychanie QML można obejść: standardowe kontrolki Qt można ostylować definiując własne pliki QSS. 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).
• Nie używanie w bibl. 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.
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 trzeba klepać w kółko ten sam kod obsługi błędów zwracanych przez wart.!
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.
Dowodem na celowe nie używanie wątków w bibl. 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 JEST CZARNE.
Znam obejście tego prob.:
#define wMaks QSizePolicy::MinimumExpanding
#define wMin QSizePolicy::Maximum
#define wStala QSizePolicy::Fixed
• 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 nawet nie można zrobić 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;
• QSqlDatabase nie można awaryjnie zamknąć przez zwykłe wywołanie destruktora. W Qt jest zabezpieczenie by 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ę tą uzyskano f. statycznymi (działają one w oparciu o zmienne globalne w pliku C++). JEST TO ROBIONE PO TO BY UTRUDNIAĆ ŻYCIE PROGRAMISTOM. Na razie nie znalazłem na to obejścia;
• 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 udostępniać obiekty kl. Qt j. skryptowym. W trakcie prog. w C++ z tych właściwości wcale się nie korzysta. WŁAŚCIWOŚCI W KL. QT SĄ TYLKO PO TO BY MOŻNA BYŁO STWORZYĆ POTWORA QML! Na razie nie znalazłem na to obejścia.
4 Jakie wsk. moralnej poprawności "są na tak" a jakie "są na nie" wzg. proj. qt.io
Wsk.
Skrótowa analiza zagadnienia
Ocena
Pole moralne
Sprzeczne z wsk. pole moralne jest psucie istniejących kl., nie naprawianie zgłaszanych błędów, nie ulepszanie i nie dostosowywanie bibl. Qt do dzisiejszych urządzeń.
NIE
Karma
Wciskanie popsutych bibl. C++ i ogłupiającego j. QML to łamanie wsk. karma.
NIE
Praca Moralna
Brak prac nad Qt w kontekście C++ to oznaka braku pracy.
NIE
Uczucia
Nie wiadomo co czują pracownicy qt.io .
BRAK
Motywacje
Brak prac nad Qt w kontekście C++ to oznaka lenistwa. Chęć zniszczenia cudzego umysłu, to z kolei szataństwo.
NIE
Odpowiedzialność
Sabotowanie całego proj. bibl. Qt, to zupełny brak poczucia odpowiedzialności za siebie, oraz brak poczucia odpowiedzialności za tych którzy jej używają i brak poczucia odpowiedzialności za cywilizację która ma używać prog. stworzonych z użyciem tej bibl.
NIE
Sumienie
Widać, że decydenci w qt.io chcący zniszczyć umysły programistom C++ nie mają wcale sumienia.
NIE
Ekonomia i własne utrzymanie
Po analizie modelu biznesowego qt.io widać, że biorąc nieskończone kredyty łamią zasady ekonomii i nie chcą sami zarabiać na własne utrzymanie.
NIE
Uczciwość
Cytat z [0]:„A więc: poznacie ich po owocach”. No te owoce są popsute, brzydkie, przestarzałe i ogłupiające.
NIE
Solidność
Tolerowanie błędów w swoich publikacjach jest sprzeczne z wsk. solidność.
NIE
Braterstwo
Dążenie do niszczenia umysłów innych ludzi jest skrajnym łamaniem wsk. braterstwo!
NIE
Kompetencje
Z jednej s. wklepano 30.703.306 linii kodu (do wer. Qt 5.12.12 włącznie), a toleruje się liczne błędy. Te błędy w wielu przypadkach uniemożliwiają użycie danej kl., np. QMdiArea i QDockWidget. Wygląda to tak, jakby kompetencje były, ale niewystarczające.
NIE
Występowanie NIE i BRAK w kol. „Ocena” oznacza, że jest jednomyślność wsk. moralnej popr. (przy braku wskazania wsk. Uczucia). Dlatego cały proj. qt.io jest niemoralny.
5 Analiza proj. XXX w świetle wsk. moralnej poprawności zwanym Ekonomia i własne utrzymanie
Pierwotni założyciele projektu Qt nigdy nie przejmowali się ekonomią, bo Trolltech nigdy nie zarabiał na siebie. Dziś rzekomo mamy 1M aktywnych programistów używających Qt, ale mogę się założyć o stówę, że qt.io nie zarabia na siebie. Świadczą o tym wspomniane pow. fakty:
1. Nonsensowna i demotywująca polityka subskrypcji;
2. Nonsensowne rozw. tech. w sklepie marketplace.qt.io powodują, że nie ma mowy by czegokolwiek z tego sklepu używać na sys. Linuks. A sys. Linuks jest dziś najlepszą platformą dostępną dla cywilnych programistów;
3. Nonsensowny marketing (coś jak w Commodore w latach 1985-1994, czyli po wygnaniu założyciela Idka Trzmiela). Zupełny brak obecności w mediach: likwidacja Qt Quarterly (z końcem 2011r.), zero art. sponsorowanych w gazetach i serwisach WWW, zero info o wdrożeniach komercyjnych, zero przykładów wzorcowych. Jedynie na blogu zamieszczają komunikaty typu: „Wyszła nowa wer. Qt X.XX.0, nowości brak.”, albo „Wyszła nowa wer. Qt Creator XX.0, nowości brak.”.
4. Braki ideologiczne: ładują bez ograniczeń kasę w patologię (QML) zamiast programować w j. C++, który jest najbardziej normalny w tym całym szaleństwie. Nawet gorzej, bo oni i tak kodują w C++ tworząc nowe kl. dla QML;
5. To ostatnie jest szerszym zjawiskiem w branży, bo wielkie korpo swoje narzędzia kodują w C++, natomiast innym podsuwają, często za darmo, jakieś własne, patologiczne wynalazki. Tym samym Qt dołącza do takich właśnie diabelskich korpo.
Pow. fakty jednoznacznie świadczą o łamaniu wsk. moralnej popr. Zwanego Ekonomia i własne utrzymanie. Dlatego w świetle tego wsk. proj. qt.io jest niemoralny.
6 Podsumowanie
Biblioteka Qt od momentu przejęcia norweskiej firmy Trolltech przez fińską firmę Nokia praktycznie nie jest rozwijana. Jest tak na przekór postępów w el. w tym np. pojawieniu się sprytnych tel. i tabletów z dotykowymi interfejsami użytkownika.
Aby wspierać nowe interfejsy dotykowe opracowano potwora QML jaki jest zaprzeczeniem filozofii Qt i C++. Dlatego QML jest kompletnie nie do przyjęcia dla programistów C++.
Model biznesowy qi.io to fikcja: zarówno oferta subskrypcji, jak zasada działania sklepu marketplace.qt.io. Nawet mi nasuwają się różne pomysły jak na tej bibl. można zarabiać. Obecnie już nawet nie wiadomo do kogo należy Qt Company. Dlatego należy powiedzieć w prost, że qt.io jest utrzymywana przez niejawnego sponsora. I że ten sponsor celowo chce psuć umysły programistów C++ i dla niego jest to ważniejsze niż dochodowy biznes. qt.io to trojan.
6.1 Rewelacje, zalety, wady i partactwa w proj. qt.io
6.1.1 Rewelacje
1. BRAK
6.1.2 Zalety
1. Wybranie przez twórców bibl. Qt j. C++;
2. W 2023r. bibl. Qt ciągle jest dostępna.
6.1.3 Wady
1. Prog. takie jak Qt Creator i Qt Assistant są uciążliwe w użyciu 3;
2. Zbędne właściwości w kl. dziedziczonych po QObject.
6.1.4 Partactwa
1. Brak aktualizacji wyglądu (brak nowych stylów QSS) i zachowania kontrolek w bibl. Qt;
2. Brak możliwości rozszerzania sys. styli QSS (tak by można je było w nowo tworzonych kontrolkach);
3. Brak naprawy popsutych kluczowych kl. (takich jak wspomniane QMdiArea i QDockWidget);
4. Niemożność w kwestii użycia wyjątków;
5. Niemożność w kwestii udostępnienia kl. QML na poziomie C++;
6. Brak możliwości integracji zakupionych bibl. w maketplace.qt.io z sys. Linuks.
7. Nonsensowny marketing;
8. Nonsensowny model biznesowy;
9. Krecia robota przeciwko społeczności programistów C++ (np. QSizePolicy, albo QApplication::exec()).
6.2 Wnioski
Na przekór braku rozwoju Qt nie ma nic porównywalnego do tej bibl. (a przynajmniej ja o niczym takim nie słyszałem).
Czy jesteśmy skazani na Qt? W polskich warunkach niestety tak, wynika to z faktu braku środków do napisania porównywalnej bibl. bez wad Qt.
Wątpliwy jest sens przepisywania Qt od zera wynika to z wad C++:
- Braku ABI;
- Brak działania f. wirt. w konstruktorach i destruktorach;
- Brak dziedziczenia operatorów;
- Brak wybierania najlepszego dopasowania typów, gdy pojawia się jakakolwiek niejednoznaczność (przekleństwo ambigous).
By naprawić te wady konieczne jest niewielkie zmodyfikowanie kompilatora i zerwanie kompatybilności z obecnym kodem C++. Dopiero wtedy należało by stworzyć następcę Qt.
Wątpliwy jest też sens przepisywania Qt od zera w j. D wynika to z wady j. D:
- D ma format plików źródłowych w modelu Asemblera (poł. deklaracji i definicji f.) a nie w modelu j. C (osobne pliki dla deklaracji i definicji f.). Programowanie w j. D jest procesem odwrotnym do programowania w j. C i C++: w j. D najpierw koduje się definicję f. i dopiero później można wygenerować plik nagłówkowy z deklaracjami tych f. Każdy programista C i C++ potwierdzi, że to nienormalny sposób pracy (tak samo jak programowanie sterowane przez testy). Wadą plików źródłowych w modelu j. C/C++ jest puchnięcie kodu o 100% w porównaniu do j. D i Pyton (sprawdziłem to kodując w tych j. przykładowy programik).
6.3 Przewidywania na przyszłość
qt.io najprawdopodobniej dalej będzie cudakować z j. QML. Będą się pojawiać nowe błędy w kl. dostępnych z C++. qt.io dalej będzie dalej udawać, że marketing nie jest do niczego potrzebny i dalej będzie cudakować ze swoim modelem biznesowym i udawać, że jest firmą komercyjną. Wszystko to po to by niszczyć programistów C++ (bo my wiemy, że ten język jest najlepszy do programowania prog., choć nie jest idealny).
6.4 Zalecenia na teraz
Zalecenia dla programistów indywidualnych:
• Nie należy się pakować w QML bo jest to sprzeczne z ustawą o ochronie zdrowia psychicznego!;
• Dalej kodować w C++ i Qt.
• Izolować własny kod C++ od kodu bibl. Qt. W tym celu używane kl. Qt należy przezywać używając dyrektyw using i #define. Robimy to po to, by w razie konieczności przezwaną kl. rozwijać je jako typy pochodne od tych przezwanych kl.
Zalecenia dla polskich firm, oprócz pow. dodatkowo:
• Należy ostylować w QSS kontrolki Qt tak by dało się je używać na sys. z ekranami dotykowymi. Wymaga to też pewnej pracy programistycznej dotyczącej obsługi kliknięć (w Qt kliknięcie jest punktowe a na ekranach dotykowych powinno działać w określonym promieniu). To na 100% działa, bo już wdrożył nieistniejący Posbit.pl (jeszcze dziś, 2023-08-21, można to zobaczyć w terminalach płatniczych Posnet Pospay Online i Posnet Netpay).
6.5 Zalecenia na przyszłość
Zalecenie dla społeczności polskich programistów C++:
• Należy rozwidlić4 proj. Qt oraz poprawić w. wymienione wady Qt;
• Z rozwidlenia Qt należy usunąć QtScript i QML;
• Z rozwidlenia Qt należy się pozbyć całego kodu wynikającego z udostępniania Qt w j. innych niż C++ (właściwości). Nie ma sensu wlec tego balastu.
Rozwidlenie Qt nie będzie możliwe do użycia w mikrokontrolerach, bo w nich nie ma bibliotek współdzielonych jakich dystrybucji wymaga licencja LGPL.
Jednak użycie Qt w mikrokontrolerach i tak jest trochę bez sensu, bo Qt nie jest bibl. czasu rzeczywistego (bo jest oparta o pętlę zdarzeń, która nie gwarantuje kiedy zdarzenie zostanie obsłużone).
• Oferta komercyjnej subskrypcji rozwidlenia Qt powinna być tak atrakcyjna, że uzasadniała by ponoszone koszty. Np.: Na licencji LGPL dostępne były by konieczne narzędzia, ale tylko konsolowe. Natomiast na licencji komercyjnej udostępniane były by wygodne narzędzia5 z interfejsem graf. (w rodzaju obecnych Qt Creator, Qt Designer, Qt Linguist i Qt Assistant). Nie ma przy tym obawy o konkurencję ze s. obecnych narzędzi graf. od Qt: one też są nienormalne i popsute i wystarczy parę minut poklikać i już jest mnóstwo pomysłów jak je można by naprawić i rozwinąć. Jednak tego typu narzędzia należy zakodować od zera (ze względu na niską jakość ich kodu oraz z powodu zapewnienia sobie do nich pełnych praw autorskich);
• Należy stworzyć sklep z dodatkami dla rozwidlonego Qt, tak by udostępniać w nim dodatkowe bibl. i prog. na komercyjnych zasadach. Pomysłów jest mnóstwo: kl. do edycji dok. ODT i ODS, kl. do wyświetlania plików HTML, PDF i innych, wtyczki SQL do popularnych baz danych, bazy no-sql, hurtownie danych, popularne protokoły: HTTP, FTP, CAN, RS. Tego jest i będzie coraz więcej! Tu jest miejsce na biznes!
• Należy dbać o to by społeczność mogła też się włączyć do tego interesu. W tym celu należy zdefiniować proste zasady i jasne kryteria techniczne i biznesowe jakie pozwalają na opublikowanie rozszerzeń dla rozwidlonego Qt.
7 Bibliografia
Bibliografia
1: , Qt History, 2018, wiki.qt.io/Qt_History
2: , Qt (software), 2023, https://en.m.wikipedia.org/wiki/Qt_(software)
3: , Pricing and Packaging | Software Stack | Tech Stack | Qt, , qt.io/pricing
4: św. Mateusz, Biblia Tysiąclecia, 2002
Jacek Marcin Jaworski
Nov 26, 2023, 3:14:47 PM11/26/23
to
7. Raport Totaliztyczny: Sprawa qt.io
autor:
Jacek Marcin Jaworski
pseudonim:
Energo Koder Atlant
pomocnicy autora:
BRAK
miejsce:
Pruszcz Gd.
utworzono:
2023-08-20
wersja: 340 z dnia:
autor:
Jacek Marcin Jaworski
pseudonim:
Energo Koder Atlant
pomocnicy autora:
BRAK
miejsce:
Pruszcz Gd.
utworzono:
2023-08-20
2023-11-26
program składu:
Libre Office Writer
sys. op.:
Kubuntu
Spis treści
1 Wstęp 3
1.1 Teza 3
1.2 Streszczenie 3
1.3 Słownik Pojęć 3
2 Metoda badawcza 4
3 Fakty 4
3.1 Czym jest bibl. Qt? 4
3.2 Obecny stan prac nad Qt: 5
3.3 Czym jest QML? 5
3.4 Obecny model biznesowy qt.io 6
3.5 Rozwiązania celowo popsute w bibl. Qt (mowa tu o tym co można używać z poziomu C++) 6
4 Jakie wsk. moralnej poprawności "są na tak" a jakie "są na nie" wzg. proj. qt.io 8
5 Analiza proj. qt.io w świetle wsk. moralnej poprawności zwanym Ekonomia i własne utrzymanie 9
Libre Office Writer
sys. op.:
Kubuntu
Spis treści
1 Wstęp 3
1.1 Teza 3
1.2 Streszczenie 3
1.3 Słownik Pojęć 3
2 Metoda badawcza 4
3 Fakty 4
3.1 Czym jest bibl. Qt? 4
3.2 Obecny stan prac nad Qt: 5
3.3 Czym jest QML? 5
3.4 Obecny model biznesowy qt.io 6
3.5 Rozwiązania celowo popsute w bibl. Qt (mowa tu o tym co można używać z poziomu C++) 6
4 Jakie wsk. moralnej poprawności "są na tak" a jakie "są na nie" wzg. proj. qt.io 8
6 Podsumowanie 10
6.1 Rewelacje, zalety, wady i partactwa w proj. qt.io 10
6.1.1 Rewelacje 10
6.1.2 Zalety 10
6.1.3 Wady 10
6.1 Rewelacje, zalety, wady i partactwa w proj. qt.io 10
6.1.1 Rewelacje 10
6.1.2 Zalety 10
6.1.4 Partactwa 11
6.2 Wnioski 11
6.3 Przewidywania na przyszłość 12
6.4 Zalecenia na teraz 12
6.5 Zalecenia na przyszłość 13
6.2 Wnioski 11
6.3 Przewidywania na przyszłość 12
6.4 Zalecenia na teraz 12
• QtScript: stary potworek skryptowy z czasów Trolltech zastąpiony w czasach Noki przez potwora QML – od tamtej pory wmawia się nam że do prog. interfejsów dotykowych jest QML i że C++ „się nie nadaje”;
• QWebView: stary silnik wyświetlania plików HTML. Cechował się on dużymi możliwościami i wygodnym API;
• QWebEngine: nowy silnik wyśw. plików HTML. Mimo że powinien on mieć API w 100% kompatybilne z QWebView, to ma on zupełnie inne API – dosłownie wygląda to tak jakby ktoś stwierdził, że QWebView jest zbyt prosty w użyciu.
W przeciwieństwie do QWebView QWebEngine nigdy nie został podczepiony do listy kontrolek Qt Designer. Zrobiono to prawdopodobnie z powodu niestabilności QWebEngine.
3.2 Obecny stan prac nad Qt:
Od 2008r, czyli od sprzedaży Trolltech firmie Nokia bibl. Qt praktycznie nie jest rozwijana (innymi słowy proj. jest mrożony). Nie chodzi mi o to że nie dają nam za darmo nowych kl. w C++, chodzi mi o to, że:
• QWebView: stary silnik wyświetlania plików HTML. Cechował się on dużymi możliwościami i wygodnym API;
• QWebEngine: nowy silnik wyśw. plików HTML. Mimo że powinien on mieć API w 100% kompatybilne z QWebView, to ma on zupełnie inne API – dosłownie wygląda to tak jakby ktoś stwierdził, że QWebView jest zbyt prosty w użyciu.
W przeciwieństwie do QWebView QWebEngine nigdy nie został podczepiony do listy kontrolek Qt Designer. Zrobiono to prawdopodobnie z powodu niestabilności QWebEngine.
3.2 Obecny stan prac nad Qt:
• Jest b. mało dostępnych gotowych stylów QSS2 dla „normalnych” kontrolek dostępnych z C++;
• Nie ma wcale dostępnych gotowych stylów QSS dla twórców prog. w C++ dla ekranów dotykowych;
• Nie wiadomo jak do własnych, nowych kontrolek tworzyć nowe style QSS;
• Nie ma wcale dostępnych gotowych stylów QSS dla twórców prog. w C++ dla ekranów dotykowych;
• Zarządzanie oknami w kl. QMdiArea oraz QDockWidget (dostępnych z C++) jest od lat popsute. Należy uznać to za sabotaż qt.io mający zniechęcać do tworzenia „normalnych” prog.;
• Dom. zach. kontrolek (dostępnych z C++) jest już przestarzałe (niezgodne z intuicją), przez co zawsze wymagają one dodatkowej pracy. Np. kl. QTreeWidget mimo że węzły i liście w tej kontrolce oparte są o kl. QTreeWidgetItem i ma ona 3 stany zaznaczania, to dom. nie są one używane. Podczas gdy normalne było by zaznaczanie węzłów jako Qt::PartiallyChecked gdy część liści jest zaznaczona a część nie.
Zamiast tego wszystkiego od 2009r. wśród programistów C++ używających bibl. Qt promuje się potwora QML opartego o język skryptowy Jawa Skrypt.
Swoistym potwierdzeniem braku prac nad Qt jest brak aktualizacji firmowej s. WWW [0] na temat proj. Qt (ost. wpis dot. 20 lecia Qt jakie obchodzono w 2015r.).
3.3 Czym jest QML?
QML jest to zdegenerowany j. skryptowy oparty na Jawa Srypt. QML reklamuje się, jako j. szybkiego tworzenia aplikacji które mogą tworzyć nie tylko zawodowi programiści ale też projektanci. Ale to fikcja. Cechą szczególną QML 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 QML jest możliwa, ale potwornie trudna. Kontrolki QML nie umożliwiają nawet normalnej obsługi kliknięcia.
• Dom. zach. kontrolek (dostępnych z C++) jest już przestarzałe (niezgodne z intuicją), przez co zawsze wymagają one dodatkowej pracy. Np. kl. QTreeWidget mimo że węzły i liście w tej kontrolce oparte są o kl. QTreeWidgetItem i ma ona 3 stany zaznaczania, to dom. nie są one używane. Podczas gdy normalne było by zaznaczanie węzłów jako Qt::PartiallyChecked gdy część liści jest zaznaczona a część nie.
Zamiast tego wszystkiego od 2009r. wśród programistów C++ używających bibl. Qt promuje się potwora QML opartego o język skryptowy Jawa Skrypt.
Swoistym potwierdzeniem braku prac nad Qt jest brak aktualizacji firmowej s. WWW [0] na temat proj. Qt (ost. wpis dot. 20 lecia Qt jakie obchodzono w 2015r.).
3.3 Czym jest QML?
Pomimo 3 prób komercyjnego użycia QML dla mnie jest on tak nienormalny, że nie jestem w stanie go używać.
3.4 Obecny model biznesowy qt.io
- Tak jak wspomniałem we wstępie, Trolltech nigdy nie przynosił zysków właścicielom;
- Jak podano w wikipedia.org na s. [0]:
„In 2017, the Qt Company estimated a community of about 1 million developers worldwide[17] in over 70 industries.[18]”
Czy teraz są zyski? Chyba nie, bo od przejęcia przez f. Nokia rozwój bibl. Qt stoi w miejscu (nie naprawiają nawet poważnych błędów w kluczowych kl. - jw.).
- 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-11-25 patrząc na tabelkę subskrypcji na s. WWW [0].
- W sklepie marketplace.qt.io są bibl. i prog. 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. bibl. Qt. Ja kupowałem bibl. 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 ma zasadę, że wszystkie wydania Qt5 są programowo i binarnie kompatybilne - API i ABI są zgodne;
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 bibl. 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 bibl. Qt w innym kat. Natomiast przerabianie skryptów budowania prog. dostarczanych w paczkach z distro to masakra. Poza nie może być w sys. Linuks dwóch wer. bibl. Qt (tych samych serii gł., np. wer. 5.12 i wer. 5.15 by się gryzły).
3.4 Obecny model biznesowy qt.io
- Tak jak wspomniałem we wstępie, Trolltech nigdy nie przynosił zysków właścicielom;
- Jak podano w wikipedia.org na s. [0]:
„In 2017, the Qt Company estimated a community of about 1 million developers worldwide[17] in over 70 industries.[18]”
Czy teraz są zyski? Chyba nie, bo od przejęcia przez f. Nokia rozwój bibl. Qt stoi w miejscu (nie naprawiają nawet poważnych błędów w kluczowych kl. - jw.).
- 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-11-25 patrząc na tabelkę subskrypcji na s. WWW [0].
- W sklepie marketplace.qt.io są bibl. i prog. 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. bibl. Qt. Ja kupowałem bibl. 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 ma zasadę, że wszystkie wydania Qt5 są programowo i binarnie kompatybilne - API i ABI są zgodne;
3.5 Rozwiązania celowo popsute w bibl. Qt (mowa tu o tym co można używać z poziomu C++)
• jw.: Zarządzanie oknami w kl. QMdiArea oraz QDockWidget jest od lat popsute. Należy uznać to za sabotaż wobec twórców „normalnych” prog.;
• jw.: Wygląd i dom. zachowanie kontrolek jest niezgodne z intuicją i przestarzałe, przez co zawsze wymagają one dodatkowej pracy;
• jw.: Wariackie API kl. QWebEngine kl. do renderowania s. HTML;
• 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).
To nachalne wpychanie QML można obejść: standardowe kontrolki Qt można ostylować definiując własne pliki QSS. 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).
• Nie używanie w bibl. Qt wyjątków. Zamiast nich używa się po prostu wart. zwracanej.
• jw.: Zarządzanie oknami w kl. QMdiArea oraz QDockWidget jest od lat popsute. Należy uznać to za sabotaż wobec twórców „normalnych” prog.;
• jw.: Wygląd i dom. zachowanie kontrolek jest niezgodne z intuicją i przestarzałe, przez co zawsze wymagają one dodatkowej pracy;
• jw.: Wariackie API kl. QWebEngine kl. do renderowania s. HTML;
• 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).
To nachalne wpychanie QML można obejść: standardowe kontrolki Qt można ostylować definiując własne pliki QSS. 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).
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.
W materiałach propagandowych qt.io podaje, ż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 trzeba klepać w kółko ten sam kod obsługi błędów zwracanych przez wart.!
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.
Pierwotni założyciele projektu Qt nigdy nie przejmowali się ekonomią, bo Trolltech nigdy nie zarabiał na siebie. Dziś rzekomo mamy 1M aktywnych programistów używających Qt, ale mogę się założyć o stówę, że qt.io nie zarabia na siebie. Świadczą o tym wspomniane pow. fakty:
1. Nonsensowna i demotywująca polityka subskrypcji;
2. Nonsensowne rozw. tech. w sklepie marketplace.qt.io powodują, że nie ma mowy by czegokolwiek z tego sklepu używać na sys. Linuks. A sys. Linuks jest dziś najlepszą platformą dostępną dla cywilnych programistów;
3. Nonsensowny marketing (coś jak w Commodore w latach 1985-1994, czyli po wygnaniu założyciela Idka Trzmiela). Zupełny brak obecności w mediach: likwidacja Qt Quarterly (z końcem 2011r.), zero art. sponsorowanych w gazetach i serwisach WWW, zero info o wdrożeniach komercyjnych, zero przykładów proj. wzorcowych. Jedynie na blogu zamieszczają komunikaty typu: „Wyszła nowa wer. Qt X.XX.0, nowości brak.”, albo „Wyszła nowa wer. Qt Creator XX.0, nowości brak.”.
1. Nonsensowna i demotywująca polityka subskrypcji;
2. Nonsensowne rozw. tech. w sklepie marketplace.qt.io powodują, że nie ma mowy by czegokolwiek z tego sklepu używać na sys. Linuks. A sys. Linuks jest dziś najlepszą platformą dostępną dla cywilnych programistów;
4. Braki ideologiczne: ładują bez ograniczeń kasę w patologię (QML) zamiast programować w j. C++, który jest najbardziej normalny w tym całym szaleństwie. Nawet gorzej, bo oni i tak kodują w C++ tworząc nowe kl. dla QML;
5. To ostatnie jest szerszym zjawiskiem w branży, bo wielkie korpo kodują swoje narzędzia w C++, natomiast innym podsuwają, często za darmo, jakieś własne, patologiczne wynalazki. Tym samym qt.io dołącza do takich właśnie diabelskich korpo.
Pow. fakty jednoznacznie świadczą o łamaniu wsk. moralnej popr. Zwanego Ekonomia i własne utrzymanie. Dlatego w świetle tego wsk. proj. qt.io jest niemoralny.
6 Podsumowanie
Biblioteka Qt od momentu przejęcia norweskiej firmy Trolltech przez fińską firmę Nokia praktycznie nie jest rozwijana. Jest tak na przekór postępów w el. w tym np. pojawieniu się sprytnych tel. i tabletów z dotykowymi interfejsami użytkownika.
Aby wspierać nowe interfejsy dotykowe opracowano potwora QML jaki jest zaprzeczeniem filozofii Qt i C++. Dlatego QML jest kompletnie nie do przyjęcia dla programistów C++.
Model biznesowy qi.io to fikcja: zarówno oferta subskrypcji, jak zasada działania sklepu marketplace.qt.io. Nawet mi nasuwają się różne pomysły jak na tej bibl. można zarabiać. Obecnie już nawet nie wiadomo do kogo należy Qt Company. Dlatego należy powiedzieć w prost, że qt.io jest utrzymywana przez niejawnego sponsora. I że ten sponsor celowo chce psuć umysły programistów C++ i dla niego jest to ważniejsze niż dochodowy biznes. qt.io to trojan.
6.1 Rewelacje, zalety, wady i partactwa w proj. qt.io
6.1.1 Rewelacje
1. Zakodowanie Qt w j. C++ (to zasługa fundatorów);
6 Podsumowanie
Biblioteka Qt od momentu przejęcia norweskiej firmy Trolltech przez fińską firmę Nokia praktycznie nie jest rozwijana. Jest tak na przekór postępów w el. w tym np. pojawieniu się sprytnych tel. i tabletów z dotykowymi interfejsami użytkownika.
Aby wspierać nowe interfejsy dotykowe opracowano potwora QML jaki jest zaprzeczeniem filozofii Qt i C++. Dlatego QML jest kompletnie nie do przyjęcia dla programistów C++.
Model biznesowy qi.io to fikcja: zarówno oferta subskrypcji, jak zasada działania sklepu marketplace.qt.io. Nawet mi nasuwają się różne pomysły jak na tej bibl. można zarabiać. Obecnie już nawet nie wiadomo do kogo należy Qt Company. Dlatego należy powiedzieć w prost, że qt.io jest utrzymywana przez niejawnego sponsora. I że ten sponsor celowo chce psuć umysły programistów C++ i dla niego jest to ważniejsze niż dochodowy biznes. qt.io to trojan.
6.1 Rewelacje, zalety, wady i partactwa w proj. qt.io
6.1.1 Rewelacje
2. W bibl. Qt zastosowano mechanizm sygnał-slot oparty o prekompilator moc (to zasługa fundatorów).
6.1.2 Zalety
1. W 2023r. bibl. Qt ciągle jest dostępna.
6.1.3 Wady
1. Prog. takie jak Qt Creator i Qt Assistant są uciążliwe w użyciu3;
2. Zbędne właściwości w kl. dziedziczonych po QObject.
6.1.4 Partactwa
1. Krecia robota przeciwko społeczności programistów C++ (np. wspomniane QSizePolicy, albo QApplication::exec()).
1. Prog. takie jak Qt Creator i Qt Assistant są uciążliwe w użyciu3;
2. Zbędne właściwości w kl. dziedziczonych po QObject.
6.1.4 Partactwa
2. Brak naprawy popsutych kluczowych kl. (takich jak wspomniane QMdiArea i QDockWidget);
3. Brak aktualizacji wyglądu (brak nowych stylów QSS) i brak aktualizacji zachowania kontrolek w bibl. Qt;
4. Brak możliwości rozszerzania sys. styli QSS (tak by można je było definiować od zera w nowo tworzonych kontrolkach);
5. Niemożność w kwestii integracji zakupionych bibl. w maketplace.qt.io z sys. Linuks.
6. Niemożność w kwestii udostępnienia kl. QML na poziomie C++;
7. Niemożność w kwestii wdrożenia w bibl. Qt wyjątków;
8. Niemożność w kwestii nonsensownego marketingu;
9. Niemożność w kwestii nonsensownego modelu biznesowego;
6.2 Wnioski
Na przekór braku rozwoju Qt nie ma nic porównywalnego do tej bibl. (a przynajmniej ja o niczym takim nie słyszałem).
Czy jesteśmy skazani na Qt? W polskich warunkach niestety tak, wynika to z faktu braku środków do napisania porównywalnej bibl. bez wad Qt.
Wątpliwy jest sens przepisywania Qt od zera wynika to z wad C++:
- Braku ABI;
- Brak działania f. wirt. w konstruktorach i destruktorach;
- Brak dziedziczenia operatorów;
- Brak wybierania najlepszego dopasowania typów, gdy pojawia się jakakolwiek niejednoznaczność (przekleństwo ambigous);
Na przekór braku rozwoju Qt nie ma nic porównywalnego do tej bibl. (a przynajmniej ja o niczym takim nie słyszałem).
Czy jesteśmy skazani na Qt? W polskich warunkach niestety tak, wynika to z faktu braku środków do napisania porównywalnej bibl. bez wad Qt.
Wątpliwy jest sens przepisywania Qt od zera wynika to z wad C++:
- Braku ABI;
- Brak działania f. wirt. w konstruktorach i destruktorach;
- Brak dziedziczenia operatorów;
- Brak w kl. aut. tworzenia f. typu virtual w przypadku wszystkich f. w sekcjach public. Jest to konieczne z powodu zapewnienia elastyczności kl. w bibl. Obecnie części pomysłów nie można realizować z tego powodu, że nie wszystkie f. w sekcjach public są typu virtual (np. nie można nadpisać QWidget::update() co oznacza, że nie można swobodnie dodawać kol. el. graf. do istniejących kontrolek, bo w razie zmiany rozmiaru nie ma jak ich uporządkować przed wyświetleniem).
Jednak zdarzają się proste kl. opakowujące takie jak QRect lub QSize lub QPoint w jakich z powodów wydajności nie powinno być pub. f. typu virtual. Dlatego zwykłe f. pub. powinny być jedynie w strukturach. Wtedy struktura od kl. różniła by się 2 el.:
1. W strukturze dom. sekcją jest public, a w kl. dom. sekcją jest private (to już jest w C++);
2. W strukturze dom. f. w sekcji public nie są typu virtual, a w kl. dom. wszystkie f. w sekcji public są typu virtual (to należy dodać do C++).
Moim zdaniem w tych 5 kluczowych postulatach niczego się nie traci z obecnego C++, a zyskuje to co gdzie indziej już dawno jest (np. w j. D). Jednak w przeciwieństwie do innych j. prog. należy zachować podział na pliki deklaracji (*.h++) i pliki definicji (*.c++).
By naprawić te wady konieczne jest niewielkie zmodyfikowanie kompilatora C++ i zerwanie kompatybilności z obecnym kodem C++. Dopiero wtedy należało by stworzyć następcę Qt.
Wątpliwy jest też sens przepisywania Qt od zera w j. D wynika to z wady j. D:
- D ma format plików źródłowych w modelu Asemblera (poł. w jedno deklaracji i definicji f.) a nie w modelu j. C (osobne pliki dla deklaracji i definicji f.). Programowanie w j. D jest procesem odwrotnym do programowania w j. C i C++: w j. D najpierw koduje się definicje f. w kl. i dopiero później można wygenerować plik nagłówkowy z deklaracjami tych f. Każdy programista C i C++ potwierdzi, że to nienormalny sposób pracy (nawiasem mówiąc tak samo nienormalne jest programowanie sterowane przez testy). Wadą plików źródłowych w modelu j. C/C++ jest puchnięcie kodu o 100% w porównaniu do j. D i Pyton (sprawdziłem to kodując w tych j. przykładowy programik).
6.3 Przewidywania na przyszłość
qt.io najprawdopodobniej dalej będzie cudakować z j. QML. Będą się pojawiać nowe błędy w kl. dostępnych z C++. qt.io dalej będzie udawać, że marketing nie jest do niczego potrzebny i dalej będzie cudakować ze swoim modelem biznesowym i udawać, że jest firmą komercyjną. Wszystko to po to by niszczyć programistów C++ (bo my wiemy, że ten język jest najlepszy do programowania prog., choć nie jest idealny).
6.4 Zalecenia na teraz
Zalecenia dla programistów indywidualnych:
• Nie należy się pakować w QML bo jest to sprzeczne z ustawą o ochronie zdrowia psychicznego!;
• Dalej kodować w C++ i Qt.
• Izolować własny kod C++ od kodu bibl. Qt. W tym celu używane kl. Qt należy przezywać używając dyrektyw using i #define. Robimy to po to, by w razie konieczności przezwaną kl. rozwijać je jako typy pochodne od tych przezwanych kl.
Zalecenia dla polskich firm, oprócz pow. dodatkowo:
• Należy ostylować w QSS kontrolki Qt tak by dało się je używać na sys. z ekranami dotykowymi. Wymaga to też pewnej pracy programistycznej dotyczącej obsługi kliknięć (w Qt kliknięcie jest punktowe a na ekranach dotykowych powinno działać w określonym promieniu). To na 100% działa, bo już wdrożył nieistniejący Posbit.pl (jeszcze dziś, 2023-08-21, można to zobaczyć w terminalach płatniczych Posnet Pospay Online i Posnet Netpay).
6.5 Zalecenia na przyszłość
Zalecenie dla społeczności polskich programistów C++:
• Należy rozwidlić4 proj. Qt oraz poprawić w. wymienione wady Qt;
• Z rozwidlenia Qt należy usunąć QtScript i QML;
• Z rozwidlenia Qt należy się pozbyć całego kodu wynikającego z udostępniania Qt w j. innych niż C++ (właściwości). Nie ma sensu wlec tego balastu.
Rozwidlenie Qt nie będzie możliwe do użycia w mikrokontrolerach, bo w nich nie ma bibliotek współdzielonych jakich dystrybucji wymaga licencja LGPL.
Jednak użycie Qt w mikrokontrolerach i tak jest trochę bez sensu, bo Qt nie jest bibl. czasu rzeczywistego (bo jest oparta o pętlę zdarzeń, która nie gwarantuje kiedy zdarzenie zostanie obsłużone).
• Oferta komercyjnej subskrypcji rozwidlenia Qt powinna być tak atrakcyjna, że uzasadniała by ponoszone koszty. Np.: Na licencji LGPL dostępne były by konieczne narzędzia, ale tylko konsolowe. Natomiast na licencji komercyjnej udostępniane były by wygodne narzędzia5 z interfejsem graf. (w rodzaju obecnych Qt Creator, Qt Designer, Qt Linguist i Qt Assistant). Nie ma przy tym obawy o konkurencję ze s. obecnych narzędzi graf. od Qt: one też są nienormalne i popsute i wystarczy parę minut poklikać i już jest mnóstwo pomysłów jak je można by naprawić i rozwinąć. Jednak tego typu narzędzia należy zakodować od zera (ze względu na niską jakość kodu w prog. od qt.io oraz z powodu zapewnienia sobie do nich pełnych praw autorskich);
Zalecenia dla programistów indywidualnych:
• Nie należy się pakować w QML bo jest to sprzeczne z ustawą o ochronie zdrowia psychicznego!;
• Dalej kodować w C++ i Qt.
• Izolować własny kod C++ od kodu bibl. Qt. W tym celu używane kl. Qt należy przezywać używając dyrektyw using i #define. Robimy to po to, by w razie konieczności przezwaną kl. rozwijać je jako typy pochodne od tych przezwanych kl.
Zalecenia dla polskich firm, oprócz pow. dodatkowo:
• Należy ostylować w QSS kontrolki Qt tak by dało się je używać na sys. z ekranami dotykowymi. Wymaga to też pewnej pracy programistycznej dotyczącej obsługi kliknięć (w Qt kliknięcie jest punktowe a na ekranach dotykowych powinno działać w określonym promieniu). To na 100% działa, bo już wdrożył nieistniejący Posbit.pl (jeszcze dziś, 2023-08-21, można to zobaczyć w terminalach płatniczych Posnet Pospay Online i Posnet Netpay).
6.5 Zalecenia na przyszłość
Zalecenie dla społeczności polskich programistów C++:
• Należy rozwidlić4 proj. Qt oraz poprawić w. wymienione wady Qt;
• Z rozwidlenia Qt należy usunąć QtScript i QML;
• Z rozwidlenia Qt należy się pozbyć całego kodu wynikającego z udostępniania Qt w j. innych niż C++ (właściwości). Nie ma sensu wlec tego balastu.
Rozwidlenie Qt nie będzie możliwe do użycia w mikrokontrolerach, bo w nich nie ma bibliotek współdzielonych jakich dystrybucji wymaga licencja LGPL.
Jednak użycie Qt w mikrokontrolerach i tak jest trochę bez sensu, bo Qt nie jest bibl. czasu rzeczywistego (bo jest oparta o pętlę zdarzeń, która nie gwarantuje kiedy zdarzenie zostanie obsłużone).
• Należy stworzyć sklep z dodatkami dla rozwidlonego Qt, tak by udostępniać w nim dodatkowe bibl. i prog. na komercyjnych zasadach. Pomysłów jest mnóstwo: kl. do edycji dok. ODT i ODS, kl. do wyświetlania plików HTML, PDF i innych, wtyczki SQL do popularnych baz danych, bazy no-sql, hurtownie danych, popularne protokoły: HTTP, FTP, CAN, RS. Tego jest i będzie coraz więcej! Tu jest miejsce na biznes!
• Należy dbać o to by społeczność mogła też się włączyć do tego interesu. W tym celu należy zdefiniować proste zasady i jasne kryteria techniczne i biznesowe jakie pozwalają na opublikowanie rozszerzeń dla rozwidlonego Qt.
7 Bibliografia
Bibliografia
1: , Qt History, 2018, wiki.qt.io/Qt_History
2: , Qt (software), 2023, https://en.m.wikipedia.org/wiki/Qt_(software)
3: , Pricing and Packaging | Software Stack | Tech Stack | Qt, 2023, qt.io/pricing
• Należy dbać o to by społeczność mogła też się włączyć do tego interesu. W tym celu należy zdefiniować proste zasady i jasne kryteria techniczne i biznesowe jakie pozwalają na opublikowanie rozszerzeń dla rozwidlonego Qt.
7 Bibliografia
Bibliografia
1: , Qt History, 2018, wiki.qt.io/Qt_History
2: , Qt (software), 2023, https://en.m.wikipedia.org/wiki/Qt_(software)
Message has been deleted
Jacek Marcin Jaworski
Dec 3, 2023, 6:03:24 PM12/3/23
to
D. 2023-11-28, wto. o 21:45:54 Maciek Godek <godek....@gmail.com>:
niedziela, 20 sierpnia 2023 o 19:40:40 UTC+2 Jacek Marcin Jaworski napisał(a):
> niedziela, 20 sierpnia 2023 o 17:42:21 UTC+2 Jacek Marcin Jaworski napisał(a):
> Jest:
> - Tak jak wspomniałem Trolltech nigdy nie przynosił zysków właścicielom.
Skąd wiesz, że nie przynosił?
Aby wyjaśnić tą sprawę należy podać, że na blogu p. Haavard Nord (jednego z dwóch założycieli bibl. Qt) https://medium.com/21st-century-decision-making-for-teams/painful-lessons-from-scaling-a-software-company-1d14ee7f9ab3 było napisane w prost: Trolltech nigdy nie przynosił zysków właścicielom. Dlatego:
D. 2023-11-29, śro. o 23:44 w Messenger zadałem pyt. Haavard Nord:
Hello! I am C++ programmer. I want to thank you for your efort to bring your programming ideas in to reality. I know Qt story, but I have question: Does Quasar or Tolltech ever make profit in the bussines sense? I mean real profit: money after pay costs, taxes and amortzation.
Dodałem też poprawkę:
*amortization
Do d. 2023-12-03 do godz. 23:44 nie otrzymałem odp.
I obawiam się, że już jej nie otrzymam.
Ktoś jeszcze ma jakieś pyt.?
niedziela, 20 sierpnia 2023 o 19:40:40 UTC+2 Jacek Marcin Jaworski napisał(a):
> niedziela, 20 sierpnia 2023 o 17:42:21 UTC+2 Jacek Marcin Jaworski napisał(a):
> Jest:
> > - Tak jak wspomniałem Trolltech nigdy nie przynosił dochodów właścicielom.
> Powinno być:
> - Tak jak wspomniałem Trolltech nigdy nie przynosił zysków właścicielom.
Skąd wiesz, że nie przynosił?
Aby wyjaśnić tą sprawę należy podać, że na blogu p. Haavard Nord (jednego z dwóch założycieli bibl. Qt) https://medium.com/21st-century-decision-making-for-teams/painful-lessons-from-scaling-a-software-company-1d14ee7f9ab3 było napisane w prost: Trolltech nigdy nie przynosił zysków właścicielom. Dlatego:
D. 2023-11-29, śro. o 23:44 w Messenger zadałem pyt. Haavard Nord:
Hello! I am C++ programmer. I want to thank you for your efort to bring your programming ideas in to reality. I know Qt story, but I have question: Does Quasar or Tolltech ever make profit in the bussines sense? I mean real profit: money after pay costs, taxes and amortzation.
Dodałem też poprawkę:
*amortization
Do d. 2023-12-03 do godz. 23:44 nie otrzymałem odp.
I obawiam się, że już jej nie otrzymam.
Ktoś jeszcze ma jakieś pyt.?
0 new messages