Programming | UNIX-Linux » X-Window, KDE fejlesztés

X-Window / KDE development A Linux dokumentációk legfőbb lelőhelye: http://www.linuxdocorg Minden HOWTO elérhető a http://www.linuxdocorg/docshtml#howto kiindulva. oldalról 1 X Window architektúra (forrás: X Window System Architecture Overview HOWTO, továbbiakban “X Window HOWTO”) 1.1 Bevezetés (X Window HOWTO / 2.) • • • • • • A GUI rendszert a Xerox laboratóriumaiban fejlesztették ki az 1970-es évek tájékán. A GUI illeszkedése a UNIX multitaszkos világához. A UNIX GUI-ja az X Window rendszer. Az MIT-s Athena projekt keretében fejlesztették ki. A UNIX a kezdetek óta rendelkezik a multiuser, multitaszk képességekkel. A hálózatok elterjedése óta támogatja a távoli bejelentkezést. Az X architektúráját is úgy alakították ki, hogy illeszkedjen ebbe az elképzelésbe. Az X az Athena projekt keretében, 1984-ben jött létre. 1988-tól az X konzorcium felügyeli e fejlesztést és a terjesztést. Az X Linuxos implementációja az

Xfree86. 1.2 X Window architektúra (áttekintés) (X Window HOWTO / 3.) • • • • Az X kliens-szerver architektúrájú. Az applikációk (kliensek) kommunikálnak a szerverrel. Kéréseket küldenek, és információkat kapnak Az X szerver kezeli a képernyőt. A programok nem nyúlnak a grafikus eszközhöz, csak az X szervert kérik meg rá. Így csak a szerver kommunikációt kell implementálni az eszközvezérlést nem. A kliensnek és a szervernek nem kell ugyanazon a gépen futnia. A kliens-szerver kommunikáció hálózaton keresztül is megvalósítható. (Elsősorban TCP/IP-n) Az X szerver fogadja a bemenő eszközök (billentyűzet, egér) jeleit is és továbbítja az információt a klienseknek. • Az X csomag tartalmaz egy Xlib könyvtárat, amelynek függvényei kezelik az alacsony szintű kliens-szerver kommunikációkat. A programjainkban ezeket a függvényeket kell használnunk. 1.3 Window Manager-ek (X Window HOWTO / 4.) • • • • • •

Szükség van arra, hogy legyen valamilyen kontrollunk a kliens ablakok fölött. Ezt az X szerver nem kezeli. Az X egyik alapvető jellemzője, hogy megadja az ablakok kezeléséhez szükséges mechanizmust, de nem köti meg az ablakok menedzselésének módszerét. (Erre azért is szükség volt, hogy a különböző gyártók a saját elképzeléseik szerint alkothassák meg.) Ezekből következik, hogy az ablakok, ablakkeretek, gombok, desktop kezeléséhez egy külön programot használunk. Ezt nevezzük Window Manager-nek A Window Manager is csak egy kliens program, habár speciális jogokkal bír. Nagyon sok Window Manager létezik. Pl: twm, fvwm, icewm, afterstep, sawfish, enlightement. Mindenki válogathat az ízlése szerint (Akár on the fly lehet cserélgetni őket.) A Window Manager egy meta-client. Fő feladata a kliensek ablakainak menedzselése, azonban emellett különböző egyéb funkciókkal is rendelkeznek. Az egyik ilyen általános funkció a kliens programok

inditása. 1.4 Kliens applikációk (X Window HOWTO / 5.) • • Ha X alá írunk kliens programot, használhatjuk az X csomagban lévő Xlib könyvtárat. Azonban ebben csak az alapvető műveletek vannak benne, és használata nehézkes. (példa: Xlib-hello/HelloXcpp) (Tapasztalhatóak hasonlóságok a Win32 API-val.) Az Xlib segítségével kontroll elemeket elővarázsolni elég nehézkes. Ebben segítenek a Widget Library-k. Ezek tartalmazzák az alapvető kontroll elemek implementációit, a programunkból csak használni kell őket. 1.5 Widget Library-k (X Window HOWTO / 6.) • • Az Athena projektben eredetileg kifejlesztett könyvtár az Athena Widget Library. Csak a legalapvetőbb elemeket tartalmazza, és a kontroll elemek kezelése eltér a manapság használatosaktól. A korai toolkit-ekből egy jól ismert az Open Software Foundation (OSF) Motif csomagja. Tartalamaz egy window manager-t és a hozzátartozó widget library-t • • • 1980-tól a korai

1990-es évekig volt elterjedt. A legkomolyabb hibája, hogy súlyos összegekbe kerül a developer license. Manapság már vannak jobb alternatívák árban, sebességben, szolgáltatásokban. Ilyen a Gtk, amely a GIMP projekthez készült. Aránylag kicsi, sok szolgáltatással, bővíthető, és teljesen ingyenes. Másik népszerű toolkit a Qt. A KDE projekt óta ismert igazán, mivel a KDE alapját szolgáltatja. A forráskódja nem, de a használata ingyenes További alternatíva a LessTif, amely egy ingyenes API kompatibilis helyettesítője a Motif-nak. 1.6 Problémák a koncepcióval (X Window HOWTO / 7.) A korábbiakból látható, hogy választhatunk window manager-t kedvünk szerint, és a programok írói is választhatnak widget library-ket. Azonban ennek a nagy szabadságnak megvannak a hátrányai: • A kliens program írója határozza meg, hogy milyen widget library-t használ. Azonban ezen könyvtárak kontroll elemei nagyban különbözhetnek. Így előfordulhat,

hogy ahány program van a desktop-on, annyi féle módon kell kezelni. • Ezek a widget library-k általában dinamikusan vannak a programokhoz hozzálinkelve. Azonban ha a kliens programjaink különbözőket használnak, akkor az plussz memóriát igényel. • A window manager-ek is sokfélék, különböző kezelési koncepciókkal. • Az egész felület ezeknek következtében nem áll össze egy egységes egésszé. Nem lehet egyben konfigurálni a kinézetét, kezelését. 1.7 Desktop Environment (a probléma megoldása) (X Window HOWTO / 8.) A megoldás egyszerű, szabványosítani kell. A desktop environment tartalmaz szolgáltatásokat és módszertanokat, amellyel a felület egységesíthető és a fenti problémák leküzdhetőek. • A desktop environment ugyanolyan egységes kinézetet ad, mint pl. a Windows, vagy a MacOS felülete. • Azért alakult az X története így, mert a fejlesztői a flexibilitásra, és a használók szabadságára helyezték a hangsúlyt,

ellentétben a Windows és a MacOS megkötöttségeivel, zártságával. Azonban ez a korábban említett helyzethez vezetett, ezért előtérbe került a komplex felület létrehozása a szabadsággal szemben. (Azonban szabadon választhatunk a korábbi helyzet, vagy a több Desktop Environment közül.) • Példaként tekintsük a KDE-t. Ez tartalmaz: o Egy window manager-t (kwm). o Grafikus eszközkészletként a Qt-t használja, amelyet kibővít környezet specifikus funkciókkal (kdelibs). Ezzel a programozók számára egy eszközkészletet ad, hogy egyszerűen fejleszthessenek azonos kinézetű programokat. o Továbbá a környezetet kiegészíti olyan elemekkel, mint a launcher panel (klauncher), általános file manager (Konqueror), konfigurációs program (control panel) amellyel a felület általánosan konfigurálható, stb. 1.8 Ismertebb Desktop Environment-ek (X Window HOWTO / 9.) • • • • CDE (Common Desktop Environment): Az egyik legelső Desktop

Environment. Célja egy szabványosított felület létrehozása volt a különböző UNIX rendszerek számára. Egyik hibája, hogy nem volt elég szolgáltatás gazdag De a legnagyobb hibája, hogy drága volt, így a szabad szoftverek világéból lényegében ki is halt. Linux alatt a legelterjedtebbek a KDE és a GNOME. Ezen kívül még akadnak mások is azért: GNUStep, ROX, GTK+Xfce, UDE, stb. Azonban a KDE és a GNOME rendelkeznek a legnagyobb támogatással, így ők a legjelentősebbek. KDE (K Desktop Environment): erről már volt szó az előző részben. GNOME: o A GNOME megszületésének is ugyanazok az okai, mint a KDE-nek. Egy jól használható, ingyenes Desktop Environment az ingyenes rendszerek számára. Hasonlítanak is egymásra A legjelentősebb különbség, hogy a GNOME nem rendelkezik saját window manager-el. Nem akarták megkötni a felhasználó kezét abban, hogy melyik window manager-t választja. (Korábban a fejlesztők az Enlightenment window

manager-t favorizálták, jelenleg a Sawfish-t.) o A GNOME a Gtk toolkit-re építkezik, a gnome-libs könyvtárával ezt egészíti ki. A fejlesztők ezek felhasználásával készíthetnek ebbe a környezetbe illeszkedő programokat. o Részei: launcher panel: panel, file manager: gmc (és a Nautilus), control panel: control center 1.9 Távoli kommunikáció (forrás: Remote X Apps mini-HOWTO) Mint már volt róla korábban szó, az X architektúrájában lehetőség van rá, hogy az X szerver (a kezelői felület) az egyik gépen fusson, míg a kliens program egy másikon, és a hálózaton keresztül kommunikáljanak. Ez az X protokoll-on keresztül zajlik (Ezt lehet tömöríteni is a lassú kapcsolatokhoz: LBX-HOWTO.) • A lokális géppel (X szerver) közölnünk kell, hogy fogadja a távoli gép kapcsolódását. • • A távoli géppel (kliens program) közölnünk kell, hogy a kimenetét a lokális gépünkre irányítsa. Lehetséges, hogy egy gépen több X

szervert használjunk, vagy több felhasználó által futtatott programok egy X szerveren jelenjenek meg. Ezeket is a távoli elérésnél használatos módszerekkel szabályozhatjuk. 1.91 Az X kliens kimenetének átirányítása (Remote X Apps mini-HOWTO / 4-5.) • A DISPLAY környezeti változón keresztül adhatjuk meg az X applikációknak, hogy melyik X szerverhez kapcsolódjanak. DISPLAY=:0 DISPLAY=localhost:1 DISPLAY=x.autbmehu:0 A DISPLAY változó egy host névvel kezdődik, ami opcionális. Követi egy “:” Utána az X szerver sequence száma következik. Ha egy gépnek több display-e van, vagy csak több X szervert futtatunk, akkor ez az indexe az azonosításhoz. (Kiegészíthető meg egy screen numberrel is: Hostname:Display.Screen módon.) • A kliens programok induláskor megvizsgálják a DISPLAY környezeti változót, hogy hova kell kapcsolódniuk. Azonban ezt felülírhatjuk a –display paraméterrel, ami után ugyanúgy kell megadnunk a display

leírását mint korábban a DISPLAY változónál. • Példák: (a Xclient> az applikációt (X kliens) futtatógép promptja) Xclient> export DISPLAY=x.autbmehu:0 Xclient> xterm & Xclient> DISPLAY=x.autbmehu:0 xterm & Xclient> xterm –display x.autbmehu:0 & 1.92 A jogosultság beállítása az X szerveren (Remote X Apps mini-HOWTO / 6.) • • Az X szerver nem fogad kapcsolódást bárhonnan. Ha nem így lenne az biztonságilag nagyon kellemetlen lenne: o Bárki bármit odarakhatna a képernyőnkre, o és monitorozhatná a billentyű leütéseinket, egér-eseményeket, stb. Az authentikációra kétféle metódus használatos: o a host listát használó mechanizmus (xhost), • o és a magic cookie-t használó xauth xhost o Az X szerver egy listát kezel a kapcsolódásra jogosult gépek neveiről. Ehhez a listához hozzáadhatunk és elvehetünk gép neveket: Xserver> xhost +xclient.autbmehu Xserver> xhost –xclient.autbmehu o De akár

teljesen ki is kapcsolhatjuk (mindenkit engedélyezünk), de ez természetesen nem javasolt, mert a fentebb említett biztonsági problémákat veti fel. Xserver> xhost + o Visszaállítása: Xserver> xhost – • o Az xhost, mint látható, nem biztonságos megoldás. Egyrészt nem különbözteti meg az adott gépen lévő felhasználókat, másrészt gépnév alapján dolgozik, ami félrevezethető. Így ezt csak olyan hálózaton használjuk, ahol megbízunk a felhasználó társainkban. xauth o Az xauth azon klienseknek engedi a kapcsolódást, amelyek ismerik a titkos jelszót (authorization record vagy magic cookie a hivatalos neve). o A cookie-k a ~/.Xauthority állományban tárolódnak (Vigyázni kell a jogoknál, hogy csak a tulaj olvashassa.) o Az xauth program kezeli. o Az X szervert a –auth <authfile> paraméterrel kell indítani. o Kezelése nehézkesebb, mint az xhost-os megoldásé. (A kezelésről további információk, példák a forrás

dokumentumban.) o Az authentikációs kommunikáció kódolatlanul zajlik a hálózaton, ezért a biztonság szempontjából érdemes lehet egy kódolt csatornával kiegészíteni: ssh. 2 KDE, KDE fejlesztés (forrás: KDE 2.0 Development könyv”) 2.1 KDE • • • • • • • • • • http://www.kdeorg/ A KDE egy korszerű, network transzparens, ingyenes desktop environment a UNIX munkaállomások számára. Tartalmaz sok hasznos, egységes felülettel rendelkező applikációt. Rendelkezik egy office környezettel. És egyben egy programfejlesztési framework. Hasonlít a MacOS és MS Windows alatt található kezelői felületekre. Miért van szükség a KDE-re? – Az X11 desktop-nak van néhány hiányossága o Nincs általános drag and drop protokoll. o Nincs egyszerűen kezelhető, dialógus alapú konfiguráció. o Nincs általános help rendszer. o Nincs általános programfejlesztési framework o Nincs összetett dokumentum framework o Hiányzik az

aplikációk szintjén a hálózat kezelés átlátszósága. o A jogosultságok kezelése az X11 applikációknak nehézkes és fárasztó. A KDE a felhasználók szemszögéből: o Korszerű felület. o A környezet network transzparens. o Integrált, egységes help rendszer a KDE-hez és applikációihoz. o Egységes kinézet és kezelhetőség minden KDE applikációnál. o Szabványosított menük, toolbar-ok, gyorsító billentyűk, színsémák, stb. o Nemzetköziség: több mint 40 nyelvre fordították már le. (Köztük a magyar is szerepel.) o Központosított, dialógus alapú konfiguráció. o Nagy számú, hasznos KDE applikáció. A KDE disztribúció részei: o KDE-Libs: Különböző run-time könyvtárak o KDE-Base: A főbb komponensek o KDE-Graphics: Grafikus programok (KDVI, KGhostview, KPaint, KFax, .) o KDE-Utilities: Segédprogramok (KEdit, KCalc, KNotes, .) o KDE-Multimedia: Multimédia applikációk (KMidi, KSCD, Kaiman, .) o KDE-Games: Játékok (KAsteroids,

KPat, Ktetris, .) o KDE-Admin: A rendszeradminisztráció programjai. o KDE-Network: Hálózati programok (Kppp, KNode, KMail, .) A KDE története o 1996. októberében született és indult útjára o 1997.aug15: Az első KDE találkozó o 1997.okt20 beta1 verzió • • • o 1998.jul12 10 verzió o 1999.feb6 v11, 1999máj5 v111, 1999szept13 v112, 1999dec15 v1.89, 2000máj11 v190 o A 2.0-ás stabil verziót 2000 október 23-án adták ki o 2000.dec5 v201, 2001febr26 v21, 2001márc27 v211, 2001aug15 v2.2, 2001szept19 v221 o Jelenleg a KDE 2.22 stabil verziónál (2001nov21) és 30Alpha1 fejlesztői verziónál (2001.okt5) tartunk A KDE struktúrája a fejlesztők számára nagy vonalakban a következő ábrán látható. o A KDE egy a Microsoft MFC/COM/ActiveX technológiájához hasonlító fejlesztői eszköztárat ad. (A KParts a KDE komponens rendszere) Linkek: o KDE main site: http://www.kdeorg o KDE developer site: http://developer.kdeorg o KOffice site:

http://koffice.kdeorg o KDevelop site: http://www.kdeveloporg (Az installálás részletei a könyv 9. oldalától) 2.2 KDE Development 2.21 Gyerünk programozni  • Szükségünk van egy szövegszerkesztőre, fordítóra, debuggerre. Ehhez célszerű a KDevelop IDE környezetet használni. Ez működéséhez igényli a gcc fordítót, a KDE és Qt könyvtárakat, és a gdb debuggert. • Először is nézzük meg a szokásos “hello world” programot KDE alatt és a fordításhoz szükséges make file-t. (KDE-hello néven megtalálható a példaprogramok között.) 2.22 Általános programstruktúra Egy szokásos KDE program struktúrája a következő: • • • • A KApplication alacsonyszintű applikáció szolgáltatásokat nyújt. A KTMainWindow programozó barát bázis osztálya az applikáció fő ablaként szolgáló KMyMainWindow osztálynak. A KMenuBar, KToolBar, KStatusBar osztályok a nevükben is szereplő ablakelemet valósítanak meg, és a fő ablak

osztály kezeli őket. A KMyContent különböző widget-ekből származhat, és a fő ablak kezeli. A KSimpleApp példa program bemutatása. • • main függveny: o A main függvényben hozunk létre egy példányt a KApplication osztályból. o A konstruktorban átadjuk az argumentum paramétereket. Az utolsó paraméter a program neve, de az ikonok megadására is szolgál. o A KApplication::isRestored() függvény megmondja, hogy session manager indította (és próbálja visszaállítani) a programunkat vagy sem. Ha visszaállításról van szó, akkor a RESTORE makró elvégzi a feladatot. Normál esetben a fő ablakból létrehozunk egy példányt és megjelenítjük. o A main függvény végén meghívjuk a KApplication::exec() függvényt. A fő ablak konstruktora: o A fő ablak a KTMainWindow-ból származik. o Legelőször is létrehozunk két action-t (olyasmi, mint a Windows-nál a menü/toolbar/gyorsítógomb esemény). Az első egy egyedi esemény Ezzel lehet

majd a szöveg rendezését állítani. KAction *reposition = new KAction(“&Reposition Text”, QIconSet(BarIcon(“idea”)), CTRL+Key R, this, SLOT(slotRepositionText()), this);    Az első paraméter az action neve. (Ez a menüben látható szöveg) A & jel ugyanúgy működik, mint windows-nál. A második paraméterben meghatározott ikon szerepel a menüben és a toolbar-on. A harmadik paraméterben szerepel a gyorsító billentyű, amivel elérhetjük ezt az action-t.  • Majd szerepel, hogy melyik objektum melyik slot függvénye hívódjon meg az action-re. (A signal/slot mechanizmusról később lesz szó.) o A “Quit” action-nél a standard ikont és gyorsító billentyűt állítjuk be. Meghívja a CloseAllWindows függvényt, amivel bezárja az applikációt. o Majd létrehozzuk a lenyíló menü elem objektumot a QPopupMenu osztályból. o A action-ket a plug tagfüggvényükkel elhelyezzük benne. (plussz egy szeparátort) o És az így

elkészült lenyíló menüt hozzáadjuk az applikáció menüjéhez. (Szükség szerint a menuBar függvény létre is hozza a KMenuBar-ból a menü objektumot az applikációnak.) o A következő sorban elhelyezzük a “reposition text” action-t a toolbar-on is. (A toolBar függvény egyben létre is hozza a toolbar-t a KToolBar osztályból.) o Hasonlóan a statusBar függvény is első meghívásakor létrehozza a statusbar-t a KStatusBar osztályból. Ebben a sorban egyből be is állítunk egy szöveget. o Majd létrehozzuk az ablak tartalmául szolgáló objektumot a QLabel widget osztályból. o Ezen beállítjuk a szöveget, a rendezést, majd beállítjuk, mint View. A slotRepositionText slot függvény: o Ez a függvény hívódik meg a “Reposition Text” action-re. (Mint egy esemény lekezelő függvény a Windows-nál.) o Átállítjuk benne a view szövegrendezését. o És beállítjuk a statusbar szövegét. 2.23 Signal-slot modell • • • • • A

signal-slot modell a Qt egyszerű eseménykezelési módszere és egyben az egyik legfontosabb része. A Qt library bázis osztálya a QObject. Minden olyan osztály, amely a signal-slot modellt implementálja közvetlenül, vagy követetve, de ebből az osztályból kell, hogy származzon. A signal-ok jelzik, hogy történt valami esemény. Ha a felhasználó lenyom egy gombot, vagy kattint az egérrel, az mind signal-t generál. De ha a gépben történik valami, pl. a belső óra jelez, az is egy signal-t adhat ki A slot-ok azok a függvények, amelyek a signal-ok hatására végrehajtódnak, lekezelik azt. Fontos, hogy a program reagáljon a signal-okra, ellenkező esetben úgy néz ki, mintha lefagyott volna. Márpedig ez nem megengedhető A signal-ok és a slot-ok objektum függetlenek. A slot függvény, amely lekezel egy bizonyos signal-t, a program bármelyik objektumában elhelyezkedhet. Továbbá a signal-t küldő objektumnak semmit nem kell tudnia a slot függvényről,

vagy arról melyik objektumban helyezkedik el. • • • Bár a signal-slot modell elsődleges funkciója az esemény lekezelés, használható kommunikációra is az objektumok között. Például amikor két ablaknak kell kommunikálnia egymással ez a módszer egyszerűbb, mint pointerekkel elérni a másik objektumot. Sok más toolkit-nél (és az MFC is idetartozik) az eseménykezelés callback függvényekkel történik. Azonban ezeknél nincs típus ellenőrzés és paraméterezésük is korlátozott, nem úgy, mint a signal-slot modellnél. Nézzük, hogyan is készítünk egy slot-ot: o Először is az osztályunknak a QObject osztályból kell származnia. o Továbbá az osztály definíciós állományban el kell helyeznünk a Q OBJECT kulcsszót. (Ezt a Qt moc fordítója fogja értelmezni) o A slot is csak egy szokásos tagfüggvény, azonban a slot szekcióban kell deklarálnunk. A slot függvények is lehetnek public, protected, és private típusúak. o Egy

példa a definicióra: class MyObject : public QWidget { Q OBJECT public: MyObject(); public slots: void myslot(); }; o Az implementációja egyezik a szokásos tagfüggvény implementációval. • A signal-ok definiálása hasonló: o Mielőtt egy signal-t küldhetnénk, definiálnunk kell. o A signal-ok definiálására ugyanazok a szabályok érvényesek, mint a slotoknál, annyi különbséggel, hogy a signal szekcióban kell definiálni. o Egy példa a signal-ok definiálására: class MyObject : public QWidget { Q OBJECT public: MyObject(); signals: void mysignal(); }; o Signal-okat az emit függvénnyel küldhetünk: emit mysignal(); • A slot-okat és a signal-okat össze kell kapcsolnunk. Erre szolgál a connect függvény: connect(srcobj, SIGNAL(signal()), dstobj, SLOT(slot())) o srcobj: Azon objektumra mutató pointer, amelytől a signal származik. o signal: A kezelendő signal. Az srcobj objektumnak kell küldenie o dstobj: Azon objektumra mutató pointer,

amelynek fogadnia kell a signalt. o slot: A dstobj slot tagfüggvénye, amely lekezeli a signal-t. • • • Egy signal-hoz akár több slot-ot is kapcsolhatunk. Az eddig elhangzottakhoz nézzük meg a signal-slot példa állományokat. A signal-slot mechanizmust használhatjuk paraméterekkel is. Ebben az esetben a signal-nak és a slot függvénynek a paraméterei meg kell hogy egyezzenek. Erre is nézzünk példát: class MyWindow : public QWidget { Q OBJECT public: MyWindow(); private slots: void slotChanged(int i); signals: void changed(int i); }; MyWindow::MyWindow() : QWidget() { connect(this, SIGNAL(changed(int)), this, SLOT(slotChanged(int))); } 2.24 Meta Object Compiler (moc) A Meta Object Compiler (moc) fordító a Qt része. Ez az eszköz fordítja le a Qt osztály definíciókat C++ osztály definícióra, tehát nem igazi fordító. • A moc értelmezi a Q OBJECT, public slots:, protected slots:, private slots:, signals: kulcsszavakat. • A Q OBJECT kulcsszó

mondja meg a moc-nak, hogy Qt osztály definícióról van szó. • • Minden slot függvénynek a slots kulcsszók alatt, a signal-oknak a signals kulcsszó alatt kell szerepelnie. A moc ezeket értelmezi és a Qt osztály definiciót átkonvertálja C++ kódra. A kódba a moc által előállított C++ header file-t kell include-olni. 2.25 Egy egyszerű származtatott widget • • • • • • • • • A widget-ek a grafikus felhasználói felület elemei. Különböző kontroll elemek mint egy nyomógomb, vagy egy felirat. A QWidget kezel számos ablakokra vonatkozó rendszer signal-t. Azt hogy ezeket a lekezelő slot függvényeket hogyan implementáltuk attól függnek a jellegzetességei, attól lesz nyomógomb, vagy editbox, stb. A widget által kapott rendszerüzenetek az alábbiak: o Kirajzolásra, áthelyezésre, átméretezésre vonatkozó események. o Egér, billentyűzet események. o Fókusz megkapása, elvesztése. o stb. Az egyik legfontosabb a

paintEvent függvény. Ebben a lekezelő függvényben implementálhatjuk a widget megjelenését. A paintEvent lekezelő függvény meghívását a QWidget::update() függvénnyel a programból is kiválthatjuk. Ebben az esetben generálódik egy signal, aminek hatására meghívódik a függvény, letörlődik a widget felülete, és az egész újra rajzolódik. A QWidget::update(int x, int y, int width, int height) vagy a QWidget::update(QRect rectangle) függvénnyel egy regiót is újrarajzoltathatunk. A QWidget::repaint(int x, int y, int width, int height, bool erase) függvénnyel is kiválthatjuk az újrarajzolást. (Több formája is létezik hasonlóan az update függvényhez.) Azonban ilyenkor a paintEvent függvény közvetlenül hívódik meg és nem signal-on keresztül. Tehát a frissítési kérelem nem kerül be az események várakozó listájába a többi esemény közé, mint az update esetén. Ezért vigyáznunk kell, hogy ha egy ciklusból a repaint-et

hívogatjuk, akkor addig a rendszer más eseményekre nem fog reagálni. Ahhoz, hogy a régiókat újra tudjuk rajzoltatni, és ne rajzolja mindig az egész felületet újra, a paintEvent implementációban ezt kezelnünk kell. További rajzolással kapcsolatos információk: o A QPainter osztály tartalmazza a rajzoló elemeket. Képernyőre való rajzoláshoz, vagy postscript printer információ előállításához egyaránt használható. Tipikusan a következő objektumokra rajzol: QPaintDevice; QWidget, QPixmap, QPrinter, és QPicture. o A QPicture osztályból származtatott objektummal felvehetjük a rajzolás folyamatát, és később visszajátszhatjuk a felvételt. Akár a képernyőre való rajzoláshoz, akár printeléshez. Azonban komplex rajzolások esetén túl sok időt igényelhet egy ilyen visszajátszás, vagyis érdemesebb a virtuális ablakok módszerét használni. • A widget implementációra példa a tictactoe. (Ez egy KDevelop-al generált projekt.)

2.26 Standard dialógusablakok A KDE is rendelkezik standard dialógus ablakokkal, akárcsak az MFC. • KFileDialog: Állományok kiválasztása • KFontDialog: Font kiválasztása • KColorDialog: Szín kiválasztása • KMessageBox: Rövid üzenetek, kérdések megjelenítése Példaként a KStandardDialogs mutatja be a használatukat. 2.27 Standard akciók • • • Korábban már találkozhattunk a KAction osztállyal. Ezzel állíthatunk elő akciókat, amelyeket a menükben, toolbar-on elhelyezhetünk. Azonban sok applikációban találhatóak meg ugyanazok a menü elemek. Ezek egységes implementálását a KStdAction osztály valósítja meg. Ezeket a standard akciókat a következő módon használhatjuk: KStdAction::stdActionName(this, SLOT(receiver()), actionCollection()); • Az akciók listája megtalálhatjuk a KStdAction osztály help-jénél. 2.28 Konfigurációs állományok • • • A konfigurációs állományok tárolása KDE-ben

emberek által értelmezhető formában, szöveg állományokban történik. (Hasonlít az MFC ini file kezelésére) Az applikációk általában a felhasználó beállításait tárolják ezekben az állományokban. Az információkat kulcs – érték párokban tárolja a rendszer. Ezeket az értékeket csoportosíthatjuk is. (lásd MS Windows ini állományok) #KDE Config File DefaultHeight=300 [Options ] BackgroundColor=255,255,255 ForegroundColor=100,100,255 • • • Az állomány tartalmazhat kommenteket is. Ezek a sorok #-al kezdődnek Ezek az állományok a felhasználó home könyvtárában a .kde/share/config könyvtárban tárolódnak. Minden applikáció generál egy alapértelmezett állományt kappnamerc néven, amiből a kappname az applikáció neve. A konfigurációs állományok kezelésére a KConfig osztály szolgál. • • Az alapértelmezett config file objektuma a KApplication::config() függvénnyel érhető el. Példa olvasásra:

kapp->config()->setGroup(“LineEditor”); str=kapp->config()->readEntry(“Text”,“Hello”)); o Ha nem állítjuk be a group-ot, akkor az alapértelmezett “unnamed” csoportban keresi a rendszer a kulcs-értek párost. o A readEntry függvény visszaadja a “Text” kulcshoz tartozó értéket. Ha ezt nem találja, akkor az alapértelmezett érték a “Hello” lesz. • Példa írásra: kapp->config()->setGroup(“LineEditor”); kapp->config()->writeEntry(“Text”,“Value”); kapp->config()->sync(); o A writeEntry beállítja a “Text” kulcshoz a “Value” értéket. o Az írás művelet cache-elve van, ezért kell meghívni a sync függvényt. 2.29 Egyéni dialógusablakok 2.291 A dialógusablak összeállítása • A GUI-val rendelkező applikációk egyik fontos eleme a dialógus ablak. Ezeknek jól megtervezettnek kell lennie, hogy az applikáció megfelelően használható legyen. • Egyrészt találhatunk megfelelő

tervező készleteket (pl. Qt designer), amellyel ezek az ablakok megtervezhetőek. (Mi a gyakorlati részben most ezt az esetet vizsgáljuk meg.) • Másrészt a KDE interface library elemek úgy lettek megtervezve, hogy támogassák a kódban való összeállítást. • Ezt megtehetjük fixen a koordináták megadásával. • Azonban erre különböző layout-ok is léteznek, amelyek a beléjük implementált logika szerint elrendezik a felület elemeket. Miért is kell ez: o Ha átméretezzük az ablakot, akkor a rajta lévő elemeknek valamilyen logikával alkalmazkodniuk kell ehhez. o Ha egy elemet leveszünk, vagy hozzáteszünk, akkor túl sok munkával jár, mert át kell rendezgetni a felületet. o Alkalmazkodni kell a font mérethez és annak változásához. o Ha a feliratok többnyelvűek (márpedig a KDE-nél így van), akkor alkalmazkodni kell a felirat változásaihoz. • Erre szolgálnak a QLayout-ból származtatott osztályok. (Saját layout managert is

implementálhatunk. 2.292 Modális és nem modális dialógus abalkok • KDE alatt is léteznek modális és nem modális dialógus ablakok. Ezeknek elmélete, működése megegyezik az MS Windows-nál megtapasztaltakkal, így erre nem térünk ki. • Azt hogy egy dialógus ablak modális legyen vagy sem, a konstruktorában szereplő paraméterrel adhatjuk meg. (Az alapértelmezett a nem modális szokott lenni.) • A modális dialógus ablakokat az QDialog::exec() függvénnyel jeleníthetjük meg. Ez a függvény előhozza a dialógus ablakot, és csak akkor tér vissza, amikor az ablakot bezárjuk. • Modális dialógus ablak objektumot. a stack-ben és a heap-ben (new operátorral) is létrehozhatunk. • Nem modális dialógus ablakokat a heap-ben, a new segítségével hozzuk létre és a show() függvénnyel tudjuk megjeleníteni. Ez azonnal visszatér, nem várja meg az ablak bezárását. • A memory leak-ek elkerülése végett gondoskodnunk kell az objektum

megsemmisítéséről itt is. Mikor is lehet ezt megtenni: o Ha az ablak kevés memóriát eszik, és gyakran kell, akkor az ablakot elrejthetjük, és később megint előhozhatjuk. Vagyis elég az applikáció bezárásánál. o Ha a dialógus gyorsan létrehozható vagy ritkán használt, akkor az elrejtésekor vagy bezárásakor megsemmisíthető.  Önmagából sose töröljük a dialógus ablak objektumot. Az a baj vele, hogy a signal az adott objektumból ered és az emit signal csak akkor tér vissza, ha az összes slot függvény befejeződött. Márpedig ebben az esetben hamarabb, egy slot függvényben törölnénk az objektumot. Az a baj, hogy néha működne, néha nem, ami nem túl bíztató.  A megsemmisítés megkönnyítéséhez egy KDialogBase::hidden() signal-t ad ki az objektum. Ez használható erre a feladatra. Azonban az előző megkötések ugyebár itt is előjönnek. Egy trükkös megoldás erre egy egyszeri 0 delay-es timer felhúzása, ami az előző

probléma nélkül meg tudja oldani a dolgot. Erre példa: void KJotsMain::configure() { if(mOptionDialog==0) { mOptionDialog=new ConfigureDialog(topLevelWidget(),0,false); if(mOptionDialog==0) { return; } connect(mOptionDialog,SIGNAL(hidden()),this,SLOT(confi gureHide())); connect(mOptionDialog,SIGNAL(valueChanged()), this,SLOT(updateConfiguration())); } mOptionDialog->show(); } void KJotsMain::configureHide() { QTimer::singleShot(0,this,SLOT(configureDestroy())); } void KJotsMain::configureDestroy() { if(mOptionDialog!=0 && mOptionDialog->isVisible()==false) { delete mOptionDialog; mOptionDialog =0; } } 2.293 Előre kész dialógusok • Természetesen mielőtt dialógus ablak készítésbe kezdünk, ellenőrizzük le, hogy nincs-e már arra a funkcióra kész a KDE vagy a Qt library-ben. A korábban már felsorolt standard dialógus ablakokon kívül továbbiak is léteznek. (pl KLineEditDlg) Természetesen ha találunk mindkettőben az adott funkcióra, akkor a

KDE-s a javasolt. 2.210 Dialógus alapú applikáció • Dialógus alapú applikációt könnyen készíthetünk. Az eddig megismerthez képest a különbség abban jelentkezik, hogy a main függvényben nem az applikáció exec() függvényét hívjuk meg, hanem létrehozunk egy modális dialógus ablakot és annak az exec() függvénye lesz a programunk fő ciklusa. 2.211 KDevelop • • • • Létrejöttének oka, hogy szükség volt egy kényelmes fejlesztői környezetre (IDE). A KDevelop egy jól használható C++ fejlesztői környezet. Ez azért szükséges, mert a Qt és természetesen a belőle származó KDE library is C++ alapú. Azonban más nyelvek alatt is fejleszthetünk vele. Viszont nem csak a kényelmes IDE megvalósítása a célja. Egy szoftvernél fontos a project management is. Főként a UNIX világban ahol a különböző konfigurációkhoz illesztenünk kell a projectet. Erre szolgál a /configure script. Továbbá a project-ünk több forrás

file-ból áll amiket különböző módon kell lefordítanunk és beillesztenünk. Erre szolgálnak a make beállítások (A KDevelop felületének megismerésére, használatára itt nem térünk ki. A gyakorlaton látható.)