Qt 6.3

Programozás

Megjelent a Qt (widget toolkit) 6.3-as kiadása. Részletek a bejelentésben.

( bimi3 | 2022. 04. 13., sze – 19:30 )

Azoknak, akik foglalkozik GUI fejlesztéssel: Munkavégzés szempontjából a Qt-t szereti jobban, vagy a GTK-t?

Amikor még foglalkoztam ilyennel, a QT-val lényegesen gyorsabban lehetett haladni…

de ma már nem tudnám elképzelni a helyzetet, hogy amire anno QT-t használtam, azt ne b@sznám bele egybe egy webszerverbe vagy electronba, aztán fut chrome-on, joccak.

sajna a fejlődés iránya pont ez, félreértés ne essék, nagyjából mindent le lehet implementálni QT-ban is, csak nagyon ritka az a határhelyzet, amikor grafikus felület kell, de a gép nem bírja el a chrome-ot (ilyen pl. a BKK utastájékoztató felületei a járművekben, azok QT-ban is vannak tudtommal).

Qt-t nagyon szeretem hasznalni is, es fejleszteni is. Utobbi par projectemet PyQt5-tel csinaltam, konnyu haladni vele, van szerkeszto, stb.. kollegaim is dicsertek, foleg aki vxwidgets utan latta.

Gtk-bol meg valami nagyon regit hasznaltam csak, az is mukodott vegulis, de annak a szerkesztoje nagyon instabil volt, es messze nem ilyen kenyelmes.

A strange game. The only winning move is not to play. How about a nice game of chess?

( bocs | 2022. 04. 14., cs – 15:55 )

Qt minőségre meglehetősen jó, ámde jönnek vele anyagi meg licensz megfontolandó dolgok (ha mikro cég vagy, akkor nem drága, minden más esetben keményen fizetni kell; ha egyszer Open Source licensz alatt kezdél fejleszteni, akkor nincs visszaút stb).

Ami jól is van így.

Ami nincs jól, hogy ha pl. fentebb kommentelő, fősodratú, házi UX-webökrünk úgy határoz, hogy Electronba gányolja össze a szoftverét, akkor sokkal nagyobb árat (környezetszennyezést, villanyszámlát, gépkidobást) fizetnek a felhasználók a bloated szutyok futtatásával.

Nem értek egyet ezzel a szemellenzős fújjolással.

Ebben van pl a Visual Studio Code írva.
Amennyit elért a Microsoft Electron segítségével X év fejlesztéssel, annak a töredéke sikerült volna, ha más GUI technológiát választanak, a funkcionalitás építése helyett saját GUI tákolásba fulladt volna a dolog.

Sajnos c++-hoz nincs magától értetődő GUI library, ez van.

Sajnos c++-hoz nincs magától értetődő GUI library, ez van.

Ami igazán szemellenzős dolog, ezt állítani úgy, hogy a Microsoft már több GUI libraryt is megírt saját maga

Fltk, FOX, Qt, Ultimate++, wxWidgets, csakhogy a legismertebbeket említsem.

https://en.wikipedia.org/wiki/List_of_widget_toolkits

Egyszer a Microsoftnál biztosan elhangzott ez a párbeszéd, két divatvezető-divatfejlesztő között: Te mondd hazudd, hogy nincs, a te hangod mélyebb.

Semmi gond, a világ dollármilliárdos szoftvermultijainak erőforrásokon való spúrkodását a világ dollármilliárdos hardvermultijait még milliárdosabbá téve fizeti meg a felhasználó, amikor új gépet kell vennie az Electronos (és nem Electronos) JS-bloat szutykok erőforrászabálása miatt.

Ezt a listát én is ismerem, ugyanis végigpróbáltam kb mindegyiket - erősen hagynak maguk után kívánnivalót ezek a libek, meg vannak amik egyemberesek, vagy évek óta haldokolnak, stb.

A Qt minimum 10x kiforrottabb ezeknél, de gyakorlatilag minden, hobbinál komolyabb felhasználásra meglehetősen drága (~300 USD/fejlesztő/hónap, az 10 fejlesztős csapatnál kb havi egy misi, csak egy szoftver komponens licenszért... ez már azért tétel).

Elektron vs natív c++ libek:

A mérnöki szemlélet az, ami hiányzik belőled: nem abszolút legjobbra, egy szempont alapján optimalizálunk (matematikus), hanem a döntésbe beleszámoljuk az optimalizálás költségét is.
Ha egy fejlesztés 10x lassabb és/vagy drágább, mert csak a tiszta elveinknek megfelelő eszközt vagyunk hajlandó használni, akkor az általában nem jó döntés - kompromisszumra van szükség.

Nekem is ez a bajom:

  • A Qt tök jó, csak licensz, meg hozzá értő fejlesztő beszerzése nehéz
  • A GTK annyira nem jó, dolgoztam vele, mindent meg lehet benne írni, csak fogcsikorgatva
  • a wxWidgets olyan, hogy csak akkor érdemes használni, ha a felhasználónak is MSc mérnökdiplomája van, de legalább természettudományos (atomtudós, biológus, stb). Egyszeri embernek való felületre nem alkalmas
  • A Windows MAUI (született UWP) igazából semmit nem tud egy HTML platformhoz képest, cserébe nincsenek libek, csak VS tooling, és nem véletlen, hogy úgy kell kiguglizni
  • A VCL Delphi, találj 50 év alatti Delphi fejlesztőt
  • Az MFC f@sza, kár, hogy Windows only, meg nem nyúltak komolyabban hozzá 1995 óta

A másik oldalon meg ott van a rengeteg JS UI lib, legyen a Google Material alapú cuccok (Flutter, Vue, stb), legyen a Microsoft Fabric, de ott a Prime NG, ott a Kendo, és fut mindkét mobil, mindhárom desktop oprendszeren by default, le se kell fordítanod.

Az üzemeltetésről meg még nem is beszéltem: elég a szervereket felfrissítened, a kliensek szépen frissülnek azonnal, nincs az, hogy rendszergazdákkal levelezgetsz a group policy-ről meg a hogyan akar tömegesen deployolni meg mikor… ha cloudban fut, ez triviális, de ha valami Nagy Tűzfal mögé kellett berakni, akkor is csak egy dolgot kell piszkálni.

ja, cserébe RAM-ban meg CPU-ban drága, az lehet, viszont olyan fejlesztési költség különbség van, hogy ha mellécsomagolnánk minden új user accounthoz egy 4GB-os RAM modult, az esetek döntő többségében még mindig olcsóbb lenne, mint lefejleszteni C++-ban.

Gyakorlatilag levezetted az önigazolásod arra, hogy a felhasználóval fizettesd meg azt, amit megspóroltált a fejlesztéssel.

A felhasználó előbb-utóbb kénytelen olyan gépet venni, amin a babzsákfejlesztők által kényelmeskedés okán használt bloat frameworköt fejlesztették. Ez környezetszennyezést eredményez, az új gép legyártását, 6000 km-ről idepöfögtetését és rendszerfrissítés esetén a felhasználó tudásának gyors elévülését eredményezi, ami felfogható időben megfizetett járulékos költségnek. A régi gépet a felhasználó kidobja (ha nem azonnal, majd 5-10 év múlva, tehát a lényeg, hogy kidobja) és megfelelően ami szintén környezetszennyezést eredményez. Nem beszélve arról, hogy ha a felhasználó laptopon, mobilon vagy tableten használja a szutykod, akkor az akksi gyorsabban merül a bloat miatt, ez által a hosszútávú élettartama is gyorsabban csökken. Tehát szintén egy drága és környezetszennyező erőforrást tékozlunk el a fejlesztői kényelmeskedés égisze alatt. Ha pedig ez még mindig nem lenne elég, akkor ott van az a tény, hogy egy szoftvert rendszerint több felhasználó használ, mint ahányan fejlesztették, tehát a kényelmeskedés eredményezte bloat sokszorozódik, ez által a környezetszennyezés, a gépkidobás, az újravásárlás is sokszorozódik. Más szóval ezt arroganciának hívják, mivel a kényelmeskedő fejlesztő csak és kizárólag a saját érdekeit, járulékos költségeit veszi figyelembe.

a wxWidgets olyan, hogy csak akkor érdemes használni, ha a felhasználónak is MSc mérnökdiplomája van, de legalább természettudományos (atomtudós, biológus, stb). Egyszeri embernek való felületre nem alkalmas

Ezt én nem a wxWidgets számlájára írnám, hanem az általad is istenített, óvodás szintre butított, majd korporatokrata erővel elterjesztett, animációbuzi Material, tehát a Google számlájára. A felsorolt GUI toolkitekkel tervezhetők professzionális felhasználói felületek. A Material-lal csak áttekinthetetlen, konzumer játékszerek.

A VCL Delphi, találj 50 év alatti Delphi fejlesztőt

Vagy akár képezhetsz is egyet.

ja, cserébe RAM-ban meg CPU-ban drága, az lehet, viszont olyan fejlesztési költség különbség van, hogy ha mellécsomagolnánk minden új user accounthoz egy 4GB-os RAM modult, az esetek döntő többségében még mindig olcsóbb lenne, mint lefejleszteni C++-ban.

Három évente pedig csomagolhatsz mellé új gépet is. Meg csomagolhatsz mellé annyi fát, napfényt és beparkosítható földterületet, amennyi a 6000 km-ről idepöfögtetést legalább CO2-tekintetben semlegesíti. Csomagolhatsz mellé annyi készpénzt, amiből a felhasználó régi gépét elszállítja valaki a szeméttelepre, vagy annyi energiát, amennyiből újrahasznosítja. Csomagolhatsz mellé annyi időt, amennyit elveszít egy új gépen lévő új OS-re való átállással, a még jobban lebutított, kiherélt, vagy csak felületen máshová átpakolt funkciók miatt. Sok mindent csomagolhatnál mellé és akkor már nem érné meg.

Persze, továbbra is ringatod magad a megéri™ illúziójában és mással fizeted meg a kényelmeskedés költségeit, sőt kiakadsz azokra, akik veled fizettetnék meg egy normálisan megírt, natív, optimalizált alkalmazással.

Mert önző vagy és arrogáns.

Szerintem te ideologizálod meg a dolgot: konkrétan környezetvédelemmel foglalkozunk, és cseréltük le a desktop rendszereinket webre. Tudtommal a level 3 upstream PCF-je kisebb (azaz kevesebb széndioxid kibocsátással jár). Látom én futni 10 éves gépeken is, nagy baja nincs, 10 évnél a probléma már inkább az szokott lenni, hogy kipusztul alóla a gép, és nem találnak alkatrészt.

A UX-esnek az első a user, és interjúkon jön ki az, mire van szüksége. Idézhetném a Microsoft 22 éves kutatásait (inductive user interface, mai napig fennvan, az XP-vel jött ki), a lényeg, hogy azok a rendszerek, amik a wxWidgets-szerű stílusban készültek, rengeteg mentális energiát vettek el a felhasználóktól. Azt, hogy a rendszereink mekkora erőfeszítést jelentenek, kérdőívekkel mérjük elsősorban (NASA TLX, System Usability Scale), de van pulzusmérős, ha nagyon akarom, kortizolos labor is, ami kiméri, ha kell. 

Minél kisebb oktatás kell a szoftverhez, annál valószínűbb, hogy az egyszeri munkás használni fogja. Ez egy környezetvédelmi, munkavédelmi szoftvernél különösen fontos, mert “amúgy” meg lehet lenni nélküle is, legalábbis amíg nincs baleset, meg nem fulladunk bele az egészbe. Ha egy operatív kisvezetőnek, akinek 25 millió dolga van egy gyárban, kezébe nyomnék egy wxWidgets szoftvert, hát tudod, mikor rögzítene benne bármit is.
 

Ha ennyire bennvagy a fenntarthatóságban, te is tudod, hogy teljes életciklusra számolunk: persze, kiképezhetek egy Delphi programozót, csak akkor desktop lesz a program, és üzemeltethetem, meg hirtelen “különleges” technológiám van, a programozó addig is fogyaszt és szén-dioxidot bocsát ki, amíg tanulja, nem vagyunk előbbre. Ráadásul vannak más szempontok is: ha történik egy vegyi baleset, a munkásnak meg kell, hogy nyíljon a telefonján a biztonsági adatlap (MSDS), meg a tűzoltó készüléket is jobb, ha simán lecsippantod egy akármilyen mobillal, minthogy papír üzemeltetési naplót bogarássz rajt. Hogy milyen mobilja van a munkásnak? Veszélyhelyzetben lesz.rom, de Delphiben nem tehetném meg.

Szóval ja, pont azért használjuk ezeket a technológiákat,hogy minél később haljunk ki.

Engem érdekelne, hogy milyen kutatásban jött az ki, hogy a mai divatos UI designok kellemesebb élményt nyújtanak, mint a régebbiek? Kevesebb információ/oldal, jóval több görgetés, egybefolyó felületek - ez tényleg jobb? Vagy inkább az jött ki, hogy kis kijelzőkre ez kell, a hagyományos desktop meg kit érdekel.

Használhatósági teszteléseken, de attól függ, mit mire.

a használhatósági tesztelés nem egy bonyolult dolog, fogsz egy delikvenst, adsz neki egy feladatot (mittom, konfiguráljon be egy tűzfalat úgy, hogy a gyerekek este 10 után ne tudjanak netezni), adsz neki egy tesztelendő terméket (pl. egy routert), és végignézed, ahogy csetlik-botlik, szándékosan nem beleszólva.

a trükk az, hogy ha ezt nem csak a baráti körben teszed, hanem tényleges demográfián (pl. éttermi rendszert pincéreken és pultosokon), hát a linuxos kocka szoftverek baromi gyorsan elvéreznek.

de a desktop nem irtódik ki, csomó folyamatban az látszik, hogy még a kékgallérosok is keresnek egy számítógépet, amin van billentyűzet, meg értelmezhető méretű képernyő, és azon próbálják megoldani. A nagy kihívás gyakran az, hogy elérjük, hogy lekonvertáljon akár mobilon is (mert amire géphez jut, elfelejti), de speciel ezek a környezetvédelmi szoftverek néhány nagyon specifikus esetet kivéve tisztán asztali rendszereken futnak egyelőre, a legtöbb környezetvédelmi folyamat olyan, amihez inkább leülsz, nyugiba, nem a gyártósor mellől intézed.

Mint fejleszto egyetertek, hogy Electron/Node/JS mind szutyok. Btw. QML is JS a C++ reszet (QWidgets) mar reg nem fejlesztik.

Fejlesztunk egy monitorozo szoftvert, ha Qt-ba irnank 40-50K euroba kerulne evente, ha Electron/Flutter 0. Qt-val a CPU es mem felhasznalas sokkal kisebb, de a tobbivel is csak 10-15% CPU es 30% MEM szoval nem erdekes. Evente kb. 20-50 eszkozt szallitunk le szoval nem tetel.

Qt-t foleg autoiparban hasznaljak ahol szet lehet optimalizalni gyengebb hw-re es mondjuk 1M autonal nem mindegy hogy 50 euro vagy 200 a board.

Qt jo ceg volt, dolgoztam ott 11evet, de amikor leleptem nagyon nem jo iranyba mentek a dolgok, glassdoor meg egy kis googli eleg jo kepet add arrol, hogy hova megy a penz. Azok a nagyon jo programozok es baromi jo fejek nagy resze mar nem volt ott amikor leptem.

Csak bizonyos Qt modulok érhetőek el LGPL-ben, és pl. device-ra nem fejleszthetsz vele, szóval van itt meglepi bőven.
Plusz ha LGPL-el kezdtél, akkor nem mehetsz át commercial-re, ezért kb örökre le kell mondanod bizonyos funkcionalitásról.

Szóval elég kényelmetlenre van megcsinálva, hogy ne legyen triviális a választás (pl van small business licensz max 4 fejlesztővel, de az sem használható device-okra stb).
Erősen meggondolandó a Qt, ha zöldmezős fejlesztésről van szó.

Akkor már inkább Flutter-rel érdemes kínlódni és azt összeházasítani c++ - al.