Lars Knoll a Qt 5-ről

Szoftver

Lars Knoll (R&D igazgató, Nokia) a Qt-Labs blogon vázolta a következő Qt főverzióval kapcsolatos terveket:

  • A fejlesztés az első pillanattól kezdve nyílt a Qt Open Governance-nek megfelelően.
  • Az új verzió nem lesz bináris kompatibilis a 4-essel, de törekednek a forrás szintű kompatibilitásra, a váltás nem lesz olyan nehéz, mint a Qt3 -> Qt4-es időkben.
  • Átszervezik a grafikus alrendszert, a jobb GPU kihasználhatóság és az egyszerűbb UI tervezés érdekében, a központi elem a QML és a Scene Graph lesz.
  • A QWidget/QPainter API megmarad, de a Scene Graph felett. Megjelenik egy QtWidgets modul.
  • Minden port a Project-Lighthouse-on fog alapulni. Így a portolás a korábbinál egyszerűbb lesz.
  • Elsődleges (Nokia által támogatott) platformok: Linux Wayland, Linux X11, Mac OSX, Microsoft Windows.
  • További platformok támogatása a közösség igényinek/hozzájárulásának megfelelően lehetséges.
  • A JavaScript motor a V8 lesz mind QML mind QtScript mind QtWebkit alatt.
  • Az első béták 2011 végén, a végleges verzió 2012-ben várható. (Idén még lesz egy Qt 4.8.)

Bővebben a Qt-Labs blogon és a Whitpaper-ben.

( kmARC v | 2011. 05. 10., k – 13:47 )

Nagyon félek. Hogy kikerült a közösség kezébe.

:(

Én azt látom, hogy számukra is világosak a veszélyek, és megpróbálják okosan csinálni.
Valami olyasmit akarnak ami a Linux kernelfejlesztőknél már működik, hogy minden modulnak lesz egy kinevezett atyaúristene. Ez egy működőképes módszer (talán az egyetlen működőképes), a nehézség abban áll, hogy a megfelelő emberek kerüljenek oda. Gyanítom kezdetben mind ex-troll lesz, azok akik már most is lényegében ezt csinálják...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

Igen... Ha a Qt szétmegy, nem sok minden használható marad a helyébe (flamebait).

Például előfordulhat, hogy itt is az lesz, mint a legtöbb nyílt forrású projektnél: a dokumentáció a használhatatlan doxygenes nullává változik. Pedig a Qt egyik legnagyobb előnye a dokumentáltság.

Az hogy bevonják a közösséget nem jelenti azt, hogy szétmegy, de még azt se, hogy átkerül a közösség kezébe.

De még ha át is kerül... egy közösség is képes lehet dokumentációt kiizzadni. Főleg mivel szerintem mindenki látja és érzi, hogy ez egy olyan fontos pontja a Qt-nak amit nem szabad veszni hagyni.

"De még ha át is kerül... egy közösség is képes lehet dokumentációt kiizzadni."

Amikor meg azt fejtegetem, hogy az open source libek dokumentációja átlagosan mennyire el van maradva, akkor meg én vagyok a troll...

Persze, részemről gyanús, hogy akik azzal jönnek, hogy dehát ott van, azok még az életben nem próbáltak azokból a "dokumentációkból" valós alkalmazást előállítani.

(Vagy csak szimplán zsenik és a kisujjukból kiszopkodják, hogy a fejlesztő így gondolta, így kellene használni, ilyen architektúrájú rendszerben, stb. ami nyilván nem derül ki egy legalapabb bevezetőből és egy függvényreferenciából. )

----------------
Lvl86 Troll

( manfreed (nem ellenőrzött) | 2011. 05. 10., k – 15:34 )

Örvendetes látni, hogy már készülnek a wayland-re :)

( turul16 v | 2011. 05. 10., k – 17:24 )

Kivallo alkalom lenne UTF-8 cserelni a (belso) QString abrazolast.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Kötődik:
http://labs.qt.nokia.com/2011/03/26/on-utf-8-latin-1-and-charsets/
http://labs.qt.nokia.com/2011/03/25/qstrings-and-unicode-optimising-qst…

A végleges "megoldás" a C++0x lenne, ha véglegesítették volna, és már több év eltelt volna, és a compilerek felkészültek volna. Volna.

Majd Qt6-ra. Addig elég gyors lesz ez így.

Úgy tudtam pont az az UTF-16 lényege, hogy jóval több nyelv karakterkészlete ábrázolható vele fix szélességben, míg mondjuk UTF-8 esetén már a magyar betűk is változó szélességűek. És amennyire tudom C++-ban a változó szélességű karakter nem éppen a programozók legjobb barátja.

Ha rosszul tudom persze javítsatok ki, mert érdekel a téma.

Tekintve, hogy a QString belső ábrázolása UTF-16-os, így pontosan ugyanazok a jelek ábrázolhatóak vele mint UTF-8-cal.

A lényeges különbség, hogy UTF-8 esetén csak a latin betűk tárolódnak egy byte-on, de minden más abc betűi 2-4 byte-on tárolódnak, még a magyar abc ékezetes betűinek egy része is. Ami azért gond, mert bár helytakarékos megoldásnak tűnhet így, de cserébe a karakterek indexelése/kezelése sokkal nehezebb. Illetve az általad emlegetett orosz/török/arab nyelvek majd minden karaktere 2-4 byte-os.

Ezzel szemben UTF-16-nál egy betű vagy 2 vagy 4 byte-os lehet. Tehát a latin abc összes betűje 2 byte-ot foglal. Ez pazarlásnak tűnhet, de ezen a 2 byte-on elfér a teljes Basic Multilingual Plane, ami tartalmazza lényegében az összes mai beszélt nyelv teljes abc-jét, az arabtól a kínaiig.
Ebből következik, hogy ha egy figyelmetlen/lusta programozó nem kezeli le a változó hosszú karaktereket, akkor a szoftver működni fog mindaddig, amíg a szoftvert nem használja valaki holt nyelvek, vagy zenei és egyéb jelek feldolgozására.
Plusz az összes a latintól nagy részben különböző abc-jű nyelv kevesebb helyet foglal mint UTF-8-cal.

Az UTF-8 egyetlen valódi előnye, hogy a már létező 8-bites stringeket váró C és egyéb kód esetleg működhet vele, ha az nem törődik sokat a string valódi tartalmával. De az ég világon semmi értelme nem lenne egy UTF-16-os rendszert "visszabutítani". Ha Qt-ből külső 8-bites kódot akarsz használni, akkor meg a toUtf8, fromUtf8 fv a barátod...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

Ez már a Qt3 óta így van és jó lenne ha nem piszkálnák. A QChar UTF-16 kódolású és erre támaszkodik a QString. Amikor a Qt-vel kezdtem foglalkozni eleinte azt hittem hogy belül UTF-8 és nem értettem hogy miért működnek "fordítva" a toUtf8() és a fromUtf8() függvények. Aztán rájöttem hogy én látok fordítva. (Tudom, nem függvénynek nevezik őket, de én megmaradtam ennél.)

Nem csak a meglevo C, hanem velhetoleg az ujabb C libek is az UTF-8 -at fogjak preferalni.

A kulvilag, protokollok, sok fileformatum utf-8 -at preferalja, Qt -nak I/O -kor tobbnyire karakter konverziot kell vegeznie.

Lehet hogy egyes emberi nyelveken tobbet fogalalnak dolgok utf-8 -ban, de egy szamitogepes program valoszinuleg joval tobb olyan stringel talalkozik ami az also 7 bitre szoritkozik.

Gondoljunk csak arra, hogy egy XML -ben a tagek es attrinutumok nevet angolul illik megadni.

UTF-16 -nak akkor volt elonye amikor nem volt magasabb kodpont. Manapsag semmilyen tenyleges elonye sincs.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Linuxon/Unixon. Kivéve Qt persze.
Win-en wchar van mindenhol, OS-X-en nem tudom.
Egyébként nem hiszem, hogy ez akkora bottleneck lenne. Ha meg mégis, ott a QByteArray, ami kb mindent tud mint a QString, és elég konvertálnod mikor pl kiírsz valamit a képernyőre, de a feldolgozás lehet 8-biten.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

Valóban megvan, de tekintve, hogy ez az élő nyelvek esetében nem jelentkezik, egyéb jelek esetén meg valószínűleg pont nem érdekel, hogy egy karakter hány byte, így a gyakorlatban nem nagyon jelentkezik a probléma.

Az UCS-4 az már talán tényleg pazarlás, a teljes kódtábla nagyobb része tök üres... :)

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

Plusz tegyük hozzá, hogy az UTF-8 az egyetlen normális karakter-ábrázolás, amelyik nem szenved a "*-endian" problémától. Bizony ilyen szempontból az UTF-16 sokkal butább, amúgy manapság már melyik rendszer vígan és gyorsan pozicionál UTF-8-ban is.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)

( tr3w v | 2011. 05. 11., sze – 17:34 )

Elnézést lemaradt a felsorolásból, hogy:

  • A QT5 futtatásához OpenGL (ES) 2.0 támogatás szükséges.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

A natív hívások Win alatt sem a képernyőre rajzolnak, hanem QImage-re (valójában valószínűleg QPixmap-ra). Már feltéve, hogy ilyen magasszintű hívások mennek, és nem csak lekérdezi mondjuk a színeket és rajzol valami hasonlót saját kódból... (Ezt pontosan nem tudom, valószínűleg valahol a kettő között.)

Alapvetően most is lehetett OpenGL és raster engine között választani, ha így nézzük, most a raster engine megy a levesbe.

Az alapvető változás az, hogy eddig minden rajzolás a QPainter osztályon keresztül történt, ami eredetileg szoftveres volt, majd átírták, hogy OpenGL-t is használjon. Ez viszont messze nem volt optimális, mert szoftver esetén mindegy, de az OpenGL jobb szereti ha a hasonló feladatok csoportosítva vannak, és nem összevissza kell váltania a módok között.
Itt jön a képbe a QSceneGraph, ami pont ezt a csoportosítást csinálja. Qt5-ben ezen fog keresztülmenni minden rajzolás (de persze a QPainter sem megy sehova, a widgetek továbbra is azt használják, de az eredményt a QSceneGraph kapja meg).

Elméletileg lehetne szoftveres QSceneGraph-t is írni, de nem akarnak, mert minek, már mindenhol lesz OpenGL. (2012-ről beszélünk.)
Ha mégsem, akkor léteznek szoftveres OpenGL rendszerek, de azzal már a Qt nem kíván foglalkozni...

(Osx, win nem probléma, többnyire Linux sem, ott úgyis ott a mesa, meg készül az Gallium-hoz az LLVMpipe, ami elég jó ahhoz, hogy ez ne legyen gond...)

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

( Csab | 2011. 05. 14., szo – 16:57 )

A Qt3-4 váltás több évbe került a KDE-nek.

Kicsit félek a Qt5-től. Mert ugye ha 10 hónapig szórakoznak a portolással, az is kisebb váltás.

Jó, de úgy tudom, hogy a KDE 4-et újraírták, vagy legalábbis valami hasonlót csináltak. Meg a Qt5 az forráskód kompatibilis lesz a Qt4-gyel, valamennyire (legalábbis azt állítják még). Úgyhogy én nem félek annyira, ha csak a KDE csapat nem vállalkozik megint valami nagyra.
---------------------------
Oszt jónapot!