A Qt 4.4.0 technikai előzetes új funkcióinak áttekintése

Címkék

A Trolltech nemrég kiadta a 4.4.0 verziójú Qt technikai előzetesét, mellyel a fejlesztők megtapasztalhatják, tesztelhetik az új képességeket.
A Qt egy nyílt forráskódú fejlesztői eszköztár, ami jelentősen egyszerűsíti a keresztplatformos programozást.
A Qt olyan népszerű alkalmazások alapja, mint az Opera böngésző, a Skype, a Google Earth, az Adobe Photoshop Elements és nem utolsó sorban az egész KDE rendszer.

A 4.4.0 technikai előzetese fejlettebb XML támogatást, a Phonon média keretrendszert és egy integrált, WebKiten alapuló widgetet nyújt. Továbbá ez az első verzió, mely engedi a widgetek renderelését a GraphicsView komponensen – egy olyan képesség ez, mellyel a Qt fejlesztők jóval gazdagabb és dinamikusabb felhasználói felületet hozhatnak létre.

Phonon

A Phonon multimédia keretrendszer egy átjáróréteg, ami lehetővé teszi a fejlesztőknek, hogy úgy váltsanak a médiakönyvtárak között, hogy ne kelljen újraírni a kódot.
A Phonont eredetileg a KDE 4-hez fejlesztették, de a Trolltech is belevette a Qt kódjába, miközben sok új backendet készített hozzá, melyet természetesen megosztott a KDE közösséggel is; a fejlesztés pedig továbbra is a KDE berkein belül marad.

A támogatott Phonon backendek többek között Xine, GStreamer, Quicktime 7 Mac OS X-en és DirectShow 9 Windowson. A Mac és Windows támogatása egyúttal azt is jelenti, hogy a fejlesztőknek már nem kell platformfüggő kódot írniuk ahhoz, hogy több operációs rendszer alatt működő multimédia alkalmazást írjanak. Ha pedig a fentebb említett motorok közül valamelyik API kódja megváltozik, elég egy helyen – a Qt kódjában – módosítani a szükséges sorokat, nem pedig minden alkalmazásban.
Bár a Phonon egyszerűsíti a keresztplatformos médialejátszást és felvételt, de léteznek korlátai is, így nem ajánlott olyan célszoftverek esetén, mint amilyen a kép- vagy hangszerkesztők.

Webkit

Nem a Phonon az egyetlen olyan dolog a Qt 4.4.0-ban, ami KDE-s gyökerekkel rendelkezik. A technikai előzetes tartalmazza még a WebKitet is, amit az Apple fejlesztett tovább a KDE KHTML keretrendszeréből. A motort a Safari böngészőn kívül még használja a Nokia, az Adobe és a Google is. A Trolltech pedig közvetlenül a Qt-ba ágyazta ezt, újfent könnyítve a programozók életén.
A WebKitet a QWebView widgeten keresztül lehet elérni, amit ugyanúgy lehet használni és ugyanolyan tulajdonságokkal is rendelkezik mint bármely más Qt widget.
A lenti képen a Qt Designerben látható ez:

Widgetek a QGraphicsView-ban

A leglátványosabb újítás kétségkívül a widgetek megjelenítése a QGraphicsView-ban.
A QGraphicsView maga a Qt 4.2-től része a rendszernek és a QCanvas felváltására született. Célja, hogy objektumorientált modellt szolgáltasson a 2D-s grafikus elemek elhelyezésének és módosításának. A technikai előzetesben már Qt widgetek is hozzáadhatók és módosíthatók, úgy mint bármely más grafika. Ráadásként a képesség teljes bemeneti átirányítással lett implementálva, tehát a felhasználó közvetlenül tudja használni a módosított, renderelt widgetet.
A widgeteken sokféle módosítást végre lehet hajtani, például támogatják az átméretezést, a forgatást, a szögmódosítást, a színszűrők alkalmazását stb.

Sok kis alkalmazást mellékelnek, hogy bemutassák, hogyan használhatják hasznosan a fejlesztők ezt a funkciót. Az egyik bemutató például egy párbeszédablakot jelenít meg, ami egy bizonyos szögben felugrik, ha a felhasználó fölé ér az egérrel. Egy másik gombok sorát mutatja egy lapos panelen, ami úgy tűnik, mintha forogna és widgeteket mutat a hátulján, a kattintások hatására.

A következő képen pedig a QWebView használata látható hasonló körülmények között. Például olyanokra lehet ezt használni, mint a lapok animált váltására a böngészőkben.

A QGraphicsView-hoz való widgettámogatás hozzáadása egyértelműen nehéz vállalkozás volt. A Trolltech fejlesztők láthatóan elég büszkék arra, amit sikerült véghez vinniük. Az egyik októberi blogbejegyzésből Andreas Hanssen fejlesztő néhány részletet mesél akkorról, mikor megvalósították ezt a képességet:

„Korábban sok dolog miatt aggódtam. A 4.2-ig majdhogynem teljesen őrültségnek tartottam a beágyazott widgetek hozzáadását a Graphics View-hoz. Visszanézve nem tudom, hogy csináltuk meg. Majdnem minden egyes problémára találtunk megoldást, majd még több problémát sikerült felfednünk. Aztán azokat is megoldottuk. És amink van, amit készítettünk, amit fentünk, stabilizáltunk, tesztelünk ezekben a napokban, az tesz büszkévé. Olyan jól sikerült, olyan jól illik minden egymásba, hogy azt hinnéd, hogy nem is mi találtuk fel ezt az API-t, hanem valahonnan, a múltból vettük őket.”

A néhány, még létező probléma pedig megoldás alatt van. Csak két helyen problémás a QGraphicsView. Az első a felbukkanók (mint a menü, ami egy választó listából jön elő); ezek még nem rendesen jelennek meg. Hanssen már javította a problémát, de a javítás nem került be a technikai előzetesbe. A másik probléma a teljesítmény. A QGraphicsView-on widgeteket használó alkalmazások elég sok erőforrást emésztenek fel. Ezt a hibát is javítják jelenleg.
Annak fényében, hogy ez egy technikai előzetes, az ilyen hibák teljesen megengedhetőek, és valószínű, hogy a végleges kiadásban már nem lesznek benne.

IPC keretrendszer

A Qt 4.4 egy IPC keretrendszert tartalmaz majd.
(IPC-ként használható többek között a D-Bus, a KDE DCOP-ja, a SOAP vagy a Microsoft világából lehet ismerős a COM+ vagy a DDE.)
A megosztott memóriaosztályok megosztott memóriaszegmenseket engednek létrehozni, csatolni, lecsatolni és törölni. A rendszerzárak (System Locks – IPC locks) osztályok támogatják a rendszerzárak létrehozását, megszerzését, elengedését és megsemmisítését.

Konkurencia keretrendszer

A Qt konkurencia keretrendszer úgy teszi lehetővé a többszálú programok írását, hogy azoknál nem kell használni az alapvető szinkronizálási primitíveket, mint a mutexek vagy várakozási feltételek.
A keretrendszer így egyszerűsíti a programozó munkáját, hiszen nem kell aggódnia a szálkezelésért, a programok az elérhető hardverre méreteződnek.

Fejlesztett XML támogatás

Az XML-t egyre többen használják adattárolásra és átvitelre, így egyre nagyobb az igény, hogy egyszerűsödjön az XML-ben tárolt adatok lekérdezése. A Qt 4.4 az ilyen lekérdezéseket úgy teszi egyszerűbbé, hogy támogatást nyújt az XQuery 1.0 szabványhoz, amiben benne foglaltatik az XPath 2.0 is. A minimális megfelelőségen túl a teljes tengely és szerializáció (axis and serialization) támogatott lesz. Ezt vagy egy parancssoros alkalmazáson keresztül (webalkalmazásoknál és háttérfeladatoknál jöhet szóba) vagy egy Qt API-n keresztül lehet használni. Az XQuery motor nem egy állandó tárolóval dolgozik (pl. egy relációs adatbázissal), hanem például XML fájlokkal.

Új súgórendszer
Az új QHelpSystem az Assistant következő lépcsőfoka. Ahelyett, hogy egy különálló alkalmazást képezne, a QHelpSystem egy könyvtár, ami különböző összetevőket kínál, amik bármilyen alkalmazásba beágyazhatók.
Ez a fejlesztőknek jóval nagyobb rugalmasságot biztosít, amikor a súgót integrálják az alkalmazásaikba.
A kényelmességet pedig tovább fokozza, hogy a Qt egy megjelenítőt is kínál, ami tulajdonképpen az Assistant egy új, QHelpSystem alapú verziója. A súgó pedig nem közvetlenül HTML fájlokkal dolgozik, hanem egy SQLite adatbázisból olvassa a dokumentáció minden részét. Ez lehetővé teszi, hogy bármennyi Qt dokumentációt megjelenítsen egy időben, ami nem volt lehetséges a Qt Assistanttal.

Ezt a rengeteg új funkciót látva egyre jobban kezd érthetővé válni a Trolltech szlogenje: „Code less. Create more.

A források és további információk megtalálhatók az

Hozzászólások

Mivel én már olvastam az eredeti cikkeket, így állíthatom, hogy egy nagyszerű kis írást hoztál össze a témában. Csak így tovább!

Ha lehet hinni a mostani terveknek, akkor a KDE 4.1 fog erre épülni. De még a KDE4.0.0 sem jelent meg, így nincs igazából hivatalos terv a KDE4.1-re. Az viszont tudható, hogy pár terv azért nem valósult meg a KDE4.0.0 kiadására, mert azokkal bevárják a QT4.4.0-t és a Webkit-et.

pidginben is lesz webkit, elég érdekesnek (pozitív értelemben) tűnik

Egész jó, határozottan tetszenek a felsorolt dolgok.

nekem ez boven eleg, mivel cross-platform fejlesztek. innentol kezdve eleg gaz, ha az alkalmazasom csak linux alatt tud nativ kinezetet produkalni, es a tobbi platformon is a sajat fajl kivalaszto ablakat erolteti (linux alatt szeretem a gtkfilechoosert, de win32/osx alatt jo lenne a grafikus felulet altal mindenhol mashol hasznalt parbeszedablakot hasznalni).

milyen konkretumot hianyolsz?

linux alatt szeretem a gtkfilechoosert, de win32/osx alatt jo lenne a grafikus felulet altal mindenhol mashol hasznalt parbeszedablakot hasznalni

Erősen kellett hozzá gugliznom, de azért asszem meglett:
http://www.ecn.wfu.edu/~cottrell/gtk_win32/

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

szubjektív véleményem a gtk filechooser-éről: egy nagy hányás (legalábbis a kde-jéhez képest)
másik: lehet, hogy gnome alatt a gtk (hogyhogy, hogynem ;) ) felveszi a "natív" kinézetet, de valahogy nálam kde alatt messze nem úgy néznek ki a gtk-s programok mint ahogy annak kellene (tehát nekem nem natív a kinézetük)!

Ezt azért olyan hangosan nem mondanám, ugyanis a kde-s progik minden további nélkül natív kinézettel, probléma nélkül mennek mind gnome mind pedig xfce alatt. Csak a gtk-nak vannak ezzel problémái, (pl: firefox filechooser vs. opera filechooser)
____________________________________________________________
Slackware 12/current - linux-2.6.23.9-olorin - KDE 3.5.8

"Ezt azért olyan hangosan nem mondanám, ugyanis a kde-s progik minden további nélkül natív kinézettel, probléma nélkül mennek mind gnome mind pedig xfce alatt."

neked. ha pedig már kellően körbeimádtátok a kde-t / qt-t / egymást, akkor nyugodtan viszsa lehet szállni a valóság talajára

natív felület kb. ez: azon desktop környezet vagy window manager (akármi) amit elindítottam. ha ez KDE, akkor legyen KDE az alapkinézet(és persze nem QT), ha GNOME akkor legyen GNOME a natív kinézet (és nem GTK), ha valami más (mittomén mik vannak még, e17 akármi ...) akkor meg nyílván az, ennyi.
és persze alapkinézeten/natív felületen nem azt értem, mint az openoffice esetén, hogy talán nagyjából úgymond úgyahogy megpróbálok kicsit hasonlítani a befogadó környezet kinézetére.
natív felületen nyílván nem azt értem, hogy ha 50 féle programot elindítok akkor 50 féle toolkitet betöltök, 50x annyi ideig darálom a winchestert és 50x annyi ideig tart elindítani mely 50x annyi memóriát használ és ez legalább még 50x annyi "megpróbálok egységes kinézetet kifacsarni" című gányt eredményezzen ....

Nem csak en hianyoltam anno egy egyseges, minden rendszeren jelenlevo modern widget set-et. De a helyzetre megoldas lenne egy, a kulonfele widgetek kozott atjarhatosagot biztosito layer is, ami kezdetnek integralna magaba QT-t es GTK-t. Valoszinuleg lassabb lenne tole az alkalmazas egy kicsit, de valamit valamiert.

---
pontscho / fresh!mindworkz

szerintem is ez a definicio a legelfogadhatobb, de akkor bandix kollega nem igazan mond igazat. ezek alapjan ha mondjuk elinditom a kbabelt gnome alatt (forditas miatt sokszor megteszem), akkor a gnome temajanak ikonjait kene hasznalnia + a gnome-fele (aka. gtk) parbeszedablakokat. szoval csak ez alapjan fakkolni a gtk/gnome parost, es eltetni a kde/qt-t teljesen ertelmetlen, mert mindegyik ugyanolyan kutyauto.

de meg elofordulhat, hogy a freedesktop csoport kitalal valami hasonlot, mint amit pontscho felvazolt... majd ha eljon a linux desktop eve ;)

Érdekes, én nem tudtam olyan KDE témáról, ami felvenné a GTK kinézetet, legfeljebb hasonló Qt és GTK témát lehet használni, és olyanról se tudtam, hogy KDE alkalmazások fel tudják venni a GNOME dialógusait. Fordítva viszont igen. Tökéletes persze nem lehet, csak a widget-ek kinézetét veszik fel, a működését nem (pl. a GTK alkalmazásokban továbbra is GTK stílusú a lenyíló lista).

Arra gondoltam közben, hogy az Adobe az Elements alapjául használja a Qt-t, esetleg elképzelhető-e, hogy a jövőben a többi programját is migrálja, és talán kihozza őket Linux alá?
Persze erősen feltételes minden, de hátha...

--
- Name ONE thing that your Linux computer can do that my MAC can't!
- Right click.

Erdekes. Valamint az is, hogy ha ennyire fos a WebKit, akkor miert mindenhol azt kezdik el hasznalni es nem Gecko engine-t? :]

---
pontscho / fresh!mindworkz

Elég komolynak tűnik. Azt hiszem a Qt egy igen jó példája, hogy hogyan tudja az üzleti fejlesztő és a nyílt forráskódú közösség jól kiegészíteni egymást.

Például olyanokra lehet ezt használni, mint a lapok animált váltására a böngészőkben.

Azbeszmegb*szta ezt az intergalaktikus innovációt! :)))) Véletlenül nem comittolt kódot a Qt-ba mostanság az Intézet is? :)

--
Sokan nincsenek tudatában annak, / hogy egyszer mindenki meghal. / Akik ráébrednek erre, / azonnal abbahagyják az ellenségeskedést.

Nem tudtam hogy a GoogleEarth is qt...
Na de viszont ha igen, tessek modnani, miert ilyen bun csunya es hasznalhatatlan a guija? (nem azt cafolom hogy qt, csak kerdezem hogy megis, miert?!)
_________________
*̡͌l̡*̡̡ ̴̡ı̴̴̡ ̡̡͡|̲̲̲͡͡͡ ̲▫̲͡ ̲̲̲͡͡π̲̲͡͡ ̲̲͡▫̲̲͡͡ ̲|̡̡̡ ̡ ̴̡ı̴̡̡ *̡͌l̡*

Kieg: ami számomra izgalmasan hangzott és ha jól tudom bekerül a 4.4-be az a push jellegű SQL kezelés. Azaz nem kell a programnak nézegetnie, hogy változott-e az adatbázis, hanem a megfeleően beállított adatbázis szól, hogy "hé hozzáadtak a táblámhoz valamit". Lehet, hogy ez máshol már evidencia, meg 1872-ben is volt már, nekem új :)