Kiadták a Qt 6.0-t

Programozás

A mai napon kiadták a Qt keresztplatformos fejlesztői keretrendszer új major verzióját, a 6.0-t.

Pár újdonság a teljesség igénye nélkül:

  •  C++17 támogatása
  • "Új generációs" QML
  • Új grafikai architektúra
  • Alapértelmezett build rendszer a cmake (a 6.x támogatni fogja a qmake-t, de a qmake távolabbi sorsa bizonytalan)

Vannak modulok/eddig támogatott platformok amik még nem támogatottak a 6.0-s releaseben (pl.: qtcharts, QNX support), ezek támogatásának visszatérése a következő minor releasekben várható.

Bővebb infó itt található.

( blueghost | 2020. 12. 09., sze – 10:43 )

Windows 10-nél régebbi windows-ok nem támogatottak. Szomorú, de érthető.

( zolti v | 2020. 12. 09., sze – 11:21 )

Vannak modulok/eddig támogatott platformok amik még nem támogatottak a 6.0-s releaseben (pl.: qtcharts, QNX support), ezek támogatásának visszatérése a következő minor releasekben várható.

Múlt héten néztem rá az egész websocket-re azt írta nem támogatott. A string.split-re depreaced warning-ot dobott, de nem igazán láttam mást helyette. Szóval még erősen béta volt.

( denesb | 2020. 12. 09., sze – 11:36 )

Akkor itt az ideje a KDE6-nak is, az 5-ös amúgy kezd túl stabil lenni (nem tudom igazából mert otthagytam instabilitás miatt).

:wq

Én pont ezért nem bánom. A KDE5 és Qt5 sose volt igazán kellően stabil. Utoljára a KDE3/Qt3 volt normálisan megcsinálva, a 4-es verziók elmentek még, igaz volt 1-2 bug, de egész használható volt még. Az 5-ös ág sose volt normálisan megcsinálva, kezdettől fogva egy tákolás volt. Reméljük a 6-ra összeszedik magukat. Nem mintha használnék ilyesmit, de azért egy nagy DE meg toolkit ne legyen már ilyen instabil, ha már ennyi dolog épül rá.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

KDE5 kellően stabil, inkább funkcióbeli visszalépés volt, mert Framework-ösítették a KD4 -> KDE5 átálláskor és hullott a feature forgács. A KDE4 volt ami nem volt normálisan megcsinálva, és bár működött, de nehéz volt karbantartani. Kíváncsi vagyok mit hoz majd a KDE6 váltás, nem vagyok túl bizakodó...

( carlcolt | 2020. 12. 09., sze – 17:12 )

Szerkesztve: 2020. 12. 09., sze – 17:13

Eddig nem volt motivaciom valtani Archrol a kisgepen.

De amint becsomagoljak az elso erre epulo KDE-t, valtok valami mas KDE5/Qt5-os disztro LTS-ere. :)

( efel | 2020. 12. 09., sze – 17:39 )

Sokan fognak kényszerből váltani rá. Mostantól az újabb 5.x verziók csak a fizetős ügyfeleknek lesz elérhető.

https://www.qt.io/blog/qt-5.15-released: While Qt 5.15 is supported as usual for all our users, Qt 5.15 will also provide long-term support for three years to all commercial license holders. Ebből nekem nem az látszik, hogy a forrás ingyenes lesz. De legyen neked igazad, az mindenkinek jobb lenne!

Update: https://lists.qt-project.org/pipermail/interest/2020-December/036082.html

Patch releases during the LTS part of Qt 5.15's life will be opensourced a year after their release. 
With the exception of security fixes, and the entire module of QtWebEngine, which will remain open throughout.

Szóval a nem-security hibajavításokra egy évet kell várni.

( uid_21365 | 2020. 12. 10., cs – 02:58 )

Ezt a cmake meg qmake idiótaságot már jó lenne elfelejteni de örökre.

Nekem már az autoconf/automake se tetszik.

Igazából úgy simán mindent ellenzek amihez több kell mint a sima make. De a közönséges configure még hagyján, oké, régóta itt van, megszoktuk (én mondjuk nem...), elviselem. De ez hogy újabb meg újabb felsőbb rétegeket építenek fölé, ez már tényleg a borzalom. És mindezt csak azért, mert a programozók képtelenek megírni tisztességesen egy Makefile-t.

Oké, én is képtelen vagyok rá, elismerem. Összehozok valamit ami működik, szó se róla, de az olyan is. A céljaimnak viszont megfelel... Ha nagyobb projecten dolgoznék, nyilván bővíteném ezirányú tudásomat. Elvégre ha már van egy eléggé standardnak tekinthető eszköz, használjuk azt. Az a megoldás. És nem az, hogy azt megpatkoljuk újabb meg újabb abstraction layer-ekkel...

FIXME

Ezek nem plusz rétegek, hanem az eddigieket cserélik le:

  • qmake-hez nem kell configure, aztán mehet a make
  • cmake-hez nem kell configure, sem make
  • meson-hoz nem kell configure, ninja-hoz nem kell make

Miért? Nekem laikusként sokkal értelmezhetőbb pl, egy CMakeLists.txt, vagy meson.build, mint egy configure script, vagy make fájl.

Eszerint a qmake és cmake mégis egy plusz réteg a make fölé. Ha egyszer kell utánuk a make.

A meson-ról és ninja-ról nem írtam semmit, azokkal még nem találkoztam, de így első hallásra amikor most olvastam a postodban hogy van ilyesmi, ez volt az első gondolatom:

„Oh my God, szóval még annál is több ilyen szarság van mint amiről tudtam”!

Röviden: ez az ügy a fülemnek olyan mint a poulseaudio vagy a systemd esete. Mindegyikre jellemző hogy volt már egy egész jól működő megoldás (például az ALSA ugye), erre néhány eszement nekiáll és elterjeszt valami teljesen más akármit, csak azért hogy annyi közös pont se legyen a Linux disztrókban mint ami eddig volt. De nekem amúgy a Grub2 is ilyen, a Grub1 tökéletes volt. Nem kellett volna bántani. Azt még értettem is remekül. A Grub2-t nem tanultam meg részleteiben, egyszerűen mert minek? Mert félek attól, mire megtanulom lesz Grub3 vagy valami más akármi.

Na és épp ez a helyzet a cmake meg qmake meg más anyámkínja esetén is. Ott a make, az önmagában is elég. De kitalálták hogy configure ami igenis egy plusz réteg a szememben a make fölött. De oké, már elég sok ideje létezik, hozzászoktunk. Erre most megy az hogy egy csomó akármit kitalálnak hogy ezt is lecseréljék, ahogy azt a fent említett példákban is írtam. Tök ugyanaz a tendencia. Sőt rosszabb, mert van ami csak a configureüt cseréli le, de van ami a make-t is, ha igaz amit írtál hogy van ez a meson meg nija izé is. Szóval még nagyobb a zűrzavar.

ÉS VALAKI EZT NEVEZI HALADÁSNAK?!

Borzalmas, na.

laikusként sokkal értelmezhetőbb pl, egy CMakeLists.txt, vagy meson.build, mint egy configure script,

Legyek őszinte - nem bántásként írom - de aki ennyire laikus az ne fordítson forrásból olyasmit ami annyira bonyolult hogy túl nehéz lenne kezelni egy sima Makefile-val. Ezt annak ellenére mondom hogy egy configure script megértése akárcsak úgy-ahogy is nekem is súlyos nehézségeket okoz egy bizonyos bonyolultsági szint felett. Mégis, erre nem az a megoldás hogy kidobjuk a fenébe a már hosszú ideje bizonyított eszközeinket valami más eszköz érdekében, hanem hogy fejlesztjük a mi saját tudásunkat.

Mert ez ami itt megy ugyanaz a szemlélet amiért sokan már meg se akarják tanulni a C nyelvet mert „elavult”, „túl nehéz” stb, aztán inkább mindent „magas szintű” nyelveken írnak, mert ugye az könnyű. Na ja, csak ami kód utána keletkezik, minden csak nem hatékony...

Mindig meg lehet ideologizálni a lustaságot és tanulni nem akarást.

Amikor hosszú időre beszüntették a GoboLinux fejlesztését, egy darabig én is próbálkoztam más, „könnyebb” disztrókkal mint Ubuntu, PuppyLinux, stb, volt még Arch meg Gentoo meg Sabayon is (oké, elismerem, a Gentoo nem könnyebb mint a GoboLinux, de kipróbáltam...), és maradhattam volna ezek bármelyike mellett is, ha nem akarok tanulni. De VÁLLALTAM, így lett LFS végül, a saját igényeim szerint Gobo-szerűre szabva. Mert vállaltam a tanulást. Nehéz volt? IGEN. Az. De megérte.

Ebből csak azt akarom kihozni, az hogy engednek a fejlesztők a „könnyebb út” csábításának, nem jó. Minden ilyesmi megbosszulja magát előbb vagy utóbb. Performanciában is, meg abban is hogy az ő saját fejlesztői tudásuk se nő, s nyilván még sok más módon is.

És mindezt csak azért, mert a programozók képtelenek megírni tisztességesen egy Makefile-t.

Oké, én is képtelen vagyok rá, elismerem. Összehozok valamit ami működik, szó se róla, de az olyan is. A céljaimnak viszont megfelel... 

Na hát egyesek céljainak meg ez felel meg. Plusz addig minek ugatsz bele amíg te magad sem tudsz összerakni egy normális Makefile-t?

Ha ennyire zavarnak a rétegek, miért írsz saját "nyelveket"? Írj gépi kódokat, legyen az a regényeid része. De lehetne ez még tovább csupaszítani.

Mindig meg lehet ideologizálni a lustaságot és tanulni nem akarást.

Tökéletes összefoglalója annak amit hosszan fejtegettél, ez pontosan te vagy.

Pontosításként, mert úgy látom ezt félreolvastad: a cmake mellé nem kell make sem. 

Legyek őszinte - nem bántásként írom - de aki ennyire laikus az ne fordítson forrásból olyasmit ami annyira bonyolult hogy túl nehéz lenne kezelni egy sima Makefile-val.

Jajj már haroldking uram, nem azt írtam hogy nem megy a configure script meg Makefile olvasása, hanem hogy jóval könnyebb egy CMakeLists.txt, vagy egy meson.build. Amúgy úgy veszem észre te is elég laikus vagy a témában, vagy inkább tájékozatlan. Elég sokat fordítgatok forrásból, lehet azért találkoztam már olyasmivel is, amivel te uram még nem ;) Remélem nem baj, vagy hagyjam azonnal abba ezt a fajta magatartást, uram?

Na, de hogy megértsd a lényegét az első hozzászólásomnak: ezek nem plusz rétegek, hanem új dolgok a régi helyett. Nem kötelező használnod saját projektnél, ha nem akarod. A világ meg olyan, hogy egy állandó dolog van, az pedig a változás. Nem mindig jó irányba, az már biztos, de mindig változik. Lehet ellene kapálózni, vagy elfelejted az ideológiákat, erőt veszel magadon (legyőzöd a lustaságot) és tanulsz. Vaaagy uram, ha akkora géniusz vagy, te magad is befolyásolhatod a változást, hogy arra menjen amerre neked tetszik. De jól vigyázz uram, akkor is változni fog, csak a te szájad íze szerint, uram.

Látszik, nem értetted meg amit írtam. Ha valamihez kell a jó öreg make, akkor az nyilvánvalóan egy réteg a make fölé.

Világosan kifejtettem azonban azt is, hogy az általad ilyen értelemben vett „új” dolgoknak is ellene vagyok. És amiatt vagyok ellene (többek közt, bár nem kizárólagosan), mert nincs igazad hogy nem kell használnom. KELL, sajnos. Állandóan belefutok ezekbe a szutykokba LFS építés közben. Rém idegesítő. Messze sokkal nehezebben adaptálhatóak a fájlrendszer-hierarchiámhoz, mint a közönséges make, akár van ahhoz még configure is, akár nincs.

Jó, neked jó volna csak a make. Nem túl sok projekt van,  ami kizárólag csak make-et használ,  ennek gondolom van oka. Minden developer meg tán csak nem lusta rendesen megtanulni a make használatát. Egyáltalán van nagyobb projekt, ami csak natúr make-et használ? 

Messze sokkal nehezebben adaptálhatóak a fájlrendszer-hierarchiámhoz,

Minden tool ismeri a destdir-t, onnantól meg azt csinálsz vele amit akarsz, úgyis az a vége (ha jól emlékszem), hogy konzervatív fájlrendszer-hierarchiába linkeled az egészet. Ezt nem is értem. 

Egyáltalán van nagyobb projekt, ami csak natúr make-et használ? 

Én a flashromot ismerem (már ha az nagyobb projektnek minősül).
Ott is kb. sajtreszelővel rejszolás a dolog használata, többször felmerült már a leváltása.
Egy ideje van már meson alapú build is, csak ugye ember nincs aki az összes Makefile-ba hakkolt hacket átírná, így marad a két build rendszer párhuzamos használata.

erre nem az a megoldás hogy kidobjuk a fenébe a már hosszú ideje bizonyított eszközeinket valami más eszköz érdekében, hanem hogy fejlesztjük a mi saját tudásunkat.

Gondolom te a középkorban valami olyan szerzetes lettél volna, akik ostorral verték saját magukat. Látom, hogy inkább a szenvedést választod és utálod azt, ha valami könnyebben/egyszerűbben használható.

Készíthetnénk a gépi kódú programokat lyukszalagra a mai napig is, de rajtad kívül senkinek nem tetszene. Igen, meg lehet tanulni, lehet az embernek a saját tudását fejlesztenie, de valaki egyszer régen úgy gondolta, hogy legyenek magas szintű nyelvek és legyen a számítógépnek memóriája, ahová gyors háttértárról be lehet tölteni a megírt programot, és kidobták/lecserélték a már hosszú ideje bizonyított eszközöket a felhasználás nagy részében. Mert sokszor az, hogy meg lehet tanulni valami bonyolult és nehézkes dolgot, az nem elég. Ha helyette meg lehet tanulni valami egyszerű és könnyed dolgot is, ami ugyanazt az eredményt adja, akkor az emberek nagy része nem azt fogja választani. És bárki, aki pl. az alkalmazottait az eltöltött idő alapján fizeti, nem azt fogja választani.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Ez persze valóban igaz egy bizonyos pontig, a baj csak az hogy ezzel az elvvel gátlástalanul visszaélnek állandóan. És emiatt van az, hogy manapság a személyi számítógépek memóriája és műveletvégző sebessége a sokezerszerese az 1990-es évek elején kaphatókénak, miközben a Word vagy LibreOffice ugyanolyan lassú foshalom mint régen a Word6.0 volt, vagy még annál is rosszabb. És ezt azzal próbálják igazolni hogy hát többet tud. Frászt! Kicsit talán csicsásabbak az ikonok, meg tetszetősebb az ablakkezelő ami ott dübörög alatta. Igazi lényegi különbség azonban nincs. Mégis lassú, és minden más program is az, mert mindet ilyen elvek alapján írták meg mint amit fentebb kifejtettél. És ez vár majd még a Linux kernelre is, ha áttérnek a C-ről a Rust-ra vagy valami más nyelvre.

Nesze neked HALADÁS©!

Nekem már az autoconf/automake se tetszik. Az automake/autoconf párosnál borzasztóbbat elképzelni is nehéz. Lassú mint a dög, a különböző verziók nem kompatibilisek. Undorító szintaxis.

Ezekkel ellentétben a cmake jól értelmezhető és rendesen működik.

Annak kellett volna a pöcsét előbb jól keményre simogatni majd egy hirtelen karateütéssel ketté törni, aki megengedte a szóköz használatát állománynevekben... AZ ÉN DISZTRÓMBAN ILYESMI NINCS. Mármint olyan programokban biztos nem amiket én magam telepítek. És ha letöltök valami akármit, akár egy zenei fájlt is, első dolgom átnevezni, úgy, hogy kigyilkolok belőle minden szóközt, minden nem ASCII karaktert, de a zárójeleket meg más különleges karaktereket is.

( kisg v | 2020. 12. 11., p – 01:19 )

A Qt szerintem egy legacy technológia, amiről két irányba érdemes migrálni (nem csak a licencelési ügyeskedésük miatt):

1. Aminek nem kell nagy teljesítményű grafika (mondjuk így a WebGPU hajnalán már kezd elmosódni ez a határ), azt web alapúra érdemes csinálni (Electron, PWA, NativeScript / React-Native irány), természetesen TypeScripttel.

2. Ha komolyabb 3D grafika kell (vagy kisebb erőforrásigény / tárhely igény, mint egy Electron), akkor a Godot Engine 4 elég jó alternatíva lesz. Mi már a 3.2-vel is csináltunk desktop appot, szerintem még Qml-hez képest is kellemes élmény, természetesen nem kötelező GDScriptet használni, lehet C++-t, C#-ot, meg még egy sor egyéb nyelvet használni.

Érdemes követni a fejlesztést: https://godotengine.org/news

Tudom, hogy elvileg játékengine, de elég korrekt 2D UI képességei vannak, és a 4-ben jön korrekt RTL támogatás meg jóféle text rendering fejlesztések. És teljesen multiplatform, még böngészőben is lehet futtatni.

És Godotban az easter egg autó / repülőszimulátort is könnyebb lesz megcsinálni. :)

A Qt szerintem egy legacy technológia, amiről két irányba érdemes migrálni

Mondanál egy-két érvet is emellett, azonkívül, hogy "nem javascript tehát legacy".

(nem csak a licencelési ügyeskedésük miatt)

Milyen licencelési ügyeskedés? Az hogy próbálnak megélni és kifizetni az alkalmazottaikat... netán még neadj-Isten profitot is termelni? Amikor egy cég próbál "licencelési ügyskedésekkel" ügyfeleket fizetős változatok felé terelni mindenki felhörldül, hogy mégis hogy képzelik, hogy nem adják ingyen amit csinálnak? Amikor bejön a fizetés a számládra akkor is így felhördülsz, hogy mégis mit ügyeskednek itt, amikor te mindent jószívből ingyen csinálsz?

:wq

Ez az ára annak, hogy megmaradt. Kerülhetett volna az Nokiával eggyütt az MS-hez is. Gondolom ugyannara a sorsra jutott volna, mint a Nokia, vagy lenne most egy MsQt ?

Egyébként szerintem lehet benne zárt forrású kereskedelmi projektet is fejleszteni, ha dinamikusan linkeled. Változott ez valamit ?

Nem változott, a legtöbb fontos modul LGPL alatt is elérhető.

Viszont énis azért managerek által kitalált licensz ügyeskedésnek tartom, hogy az LTS verziók javításait csak 1 évvel később kapod meg, ha nem fizetsz.
Illetve van még az, hogy source eléhető, de akkor az nem világos számomra, hogy az LTS verziók forrása is elérhető lesz-e, vagy sem.