Következő Előző Tartalom

6. Alkalmazás alapelvek

Ez a fejezet, a már említett alkalmazás fajtákról nyújt áttekintést: az MDI (Multiple Document Interface - Többdokumentumos felület) és a Dokumentum-nézet formáról lesz szó. A Kdevelop-pal történő projekt létrehozásának és a Dokumentumnézet formának az alpvető bemutatása már megtörténta The KDevelop Programming Handbook címen, de csak egy SDI-n (Single Document Interface - Egydokumentumos felület) keresztül. Mindenképpen tisztában kell lennie a KDE és a Qt osztályok alapjaival, amelyek leírását a The KDE Library Reference Guide címen nézheti meg, ahol részletes magyarázat található a háttérkönyvtárak osztályairól és azok használatáról, valamint leírás a Qt jel-fogadó machanizmusáról és eseménykezeléséről.Áttekintés arról, amit már tud:

6.1 A Dokumentumnézet forma

A Dokumentumforma, egyike a legalapvetőbb fogalmaknak a Grafikus Felhasználói Felületen történő alkalmazástervezésben. Ezért könnyű megérteni, hogy miért kell megismerni az okait annak, amiért a programozók mégis szívesen használják ezt más lehetőségek ellenére. Előszőr azonben lássuk hogyan készül egy tipikus KDE/Qt alkalmazás:Az alkalmazás kérelme adja egy program eseménykezelőjének a kiindulópontot. A programmal magával a felhasználó egy Grafikus Felhasználó Felületen keresztül kerül kapcsolatba, amit leggyakrabban főablaknak neveznek. A főablak nyújtja aztán az olyan szolgáltatásokat, mint a gyorsbillentyűk, a menüsor, az eszköztár, és állapotsor. Ennek közepén van az úgy nevezett "nézet terület", egy olyan rész, amiben más osztályok meghívhatók. Ezt általában csak "Kilátó"-nak hivják. A "kilátó" akkor kerül meghívásra, amikor a "fő ablak" egy programindításnál megnyílik és "kilátó terület" összetevőként kell hogy beállítódjon egy olyan eljárással, amit a "fő ablak" biztosít: setView(your_view) a KDE alkalmazásokhoz a KTMainWindow -t használva, setCentralWidget(your_view) a Qt alkalmazásokhoz a QMainWindow -t használva. Így nyilvánvaló, hogy a "kilátó" az a terület, amelyik felel a felhasználóval való kapcsolatért,hogy az kezelhesse azokat az adatokat, amelyek ott feltünnek. Példaként: használhats egy QMultiLineEdit-t, "kilátóként", ami által egy szövegszerkesztőhöz jut. Aztán használhatja még a "kilátó" meglevő "fogadóit", hogy kapcsolatot teremtsen a menüsor, vagy eszköztár parancshoz a következőképpen:Miközben a menüsort készítí, meg akar adni egy eljárást a "kivágás" parancsnak a "Szerkesztés" menüben:

 pEditMenu—>inseritem(BarIcon("editcut"), i18n("Cu&t"),view, SLOT(cut()),KAccel::Cut, ID_EDIT_CUT);
Ez létrehoz egy menüpontot a "Szerkesztés" menüben, amely aktiválódásakor közvetlenül hívja meg a view cut() "fogadó"-ját; tehát feltételezzük, hogy egy QMultiLineEdit -ként hozta létre és mint "kilátó területet" állította be. A multilineedit "fogadó" meghívódik, és válaszképpen kivágja a kijelölt szöveget. A működőképességet már biztosította az osztály maga, így nincsen szükség a QMultiLineEdit -től átvenni azt, hogy létrejöjjön egy "nézet terület", amelyik képes az ilyesfajta feladatok elvégzésére. Hamar készen is állnak a az alkalmazásfejlesztés elkészítésére és használatára - már csak egy alkalmazásra és a főablakra van szüksége, amelyek kapcsolatban állnak a nézet területtel, és el is készült. Ez azt jelenti, hogy egy kis szövegszerkesztőt létre lehet hozni egy egyszerű osztály megírásával, amelyik leírja a főablak viselkedését, valamint az állományok mentésének és betöltésének mikéntjét a szerkesztőben. A fő kilátónak magának, csak néhány alapvető fogadót kell lekezelnie.Lássuk az okot, amiért ezt a rejtélyes Dokumentumnézet formát bemutatjuk: önnek kell megadnia azokat az eljárásokat, amelyek olvassák és írják a szerkesztés alatt álló állományokat a QMultiLineEdit nézettel a within főablak felületen. Ez a legjobb és a leglogikusabb, amit ebben az esetben tehet. Ha az állományok tartalmára, mint egy "dokumentumra" tekint, amit a C++ terminológiájával élve "objektum"-változóként is felfoghatunk, akkor a következő lépés nagyon egyszerű. Ha van egy dokumentumunk, egy nézetünk és egy főablakunk, akkor miért ne különíthetnénk el ezt a három objektumot egymásól? Könnyedén létrehozhat egy kis osztályt, ami egy állomány szövegablakba való beolvasásáért felel, azután pedig meghívja a nézetet a szöveg láthatóvá tételének érdekében. Az állomány ismételt elmentésének érdekében ugyanez megtehető - a dokumentum osztálynak ezután biztosítania kell egy mentési eljárást, mely a nézetből visszanyeri a szöveget az állomány számára. Példánkban csak ezt a két eljárást kell végrehajtania dokumentumosztálynak, mert a szerkesztés-nézet alapvetően minden olyan eljárást biztosít a fogadók által, melyekre egy editornak szüksége van. Ezeken keresztül, ön közvetlenül kezelheti a nézet tartalmát is.A legalább kettő (nézet, főablak) helyett, három objektumra (dokumentum, nézet, főablak) történő elkülönítés alapötlete a következő kérdés felvetéséből származik: Mi van akkor, ha a felhasználónak meg akarjuk adni azt a lehetőséget, hogy egy állománnyal két, vagy több nézetben is dolgozhasson egyszerre? Ezt egy főablakban is megtehetjük osztók, vagy elválasztók segítségével, amely igy két olyan nézetet is tartalmazhat, melyek külön külön megjelenítenek egy állományt. Itt azonban előjön az aprobléma, hogy ez a megoldás csak akkor működik, ha a felhasználó megváltoztatja az állományt az egyik kilátóban, és a másik nézet is értesül erről, hogy tartalma frissülhessen. Másképpen hiba léphet fel: ha a felhasználó bezárja azt a nézetet, amelyben hozzáadott valamit az állomány végéhez, amit a másik in nézetben szereplő állomány elejéről vágott ki, akkor az állomány úgy kerül elmentésre, hogy még mindig tartalmazza a kivágott részt. Hiszen ha a nézetek nem értesülnek az adott állomány változásairól, akkor az elmentés után tartalmazni fogják mind a kivágott, mind a beillesztett részt is. Ez azt jelenti, hogy a nézeteket összhangban kell tartani, hogy az állomány változásait érzékelhessék és egyformán megjeleníthessék, bármelyik nézetben is dolgozik a felhasználó. Ezek szerint, végül is egy dokumentum osztálynak kell felügyelnie a dokumentum valós állapotát, és biztosítania kell a nézeteknek, hogy változtathassanak tartalmukon.Remélem, hogy a fent taglaltak engedtek némi betekintést ebbe a szerkezetbe; habár legtöbb esetben úgy tűnik, hogy a programozó meg lehet nélküle egy meglévő osztály nézetként való használatával, vagy egy widget megírásával, amit felhasználóval való kapcsolat kezelésére használ. Ameddig ön csak egy dokumentumot jelenít meg egy nézetben, addig a nézet képes követni az állomány változásait, és csak azokért az eljárásokért felel, amelyek beállítják, vagy visszanyerik a dokumentum tartalmát a beolvasás, vagy az elmentés során. A következő forma amit leírunk, az Összetett dokumentumfelület lesz, ami különbözik az itt leírtaktól. Meg fogja látni, hogy miért szükséges a Dokumentum nézet forma, és hogy milyen lehetőségeket biztosít.

6.2 A Többdokumentumos felület (MDI)

Az előző fejezetben leírtak alapján, talán már sejti is, hogy mit jelent az MDI. Azok a felhasználók, akik nem Unix/Linux rendszert használnak, hanem valamilyen más operációs rendszert, azok használják ezt, miként az azokra a platformokra fejlesztő programozók is. Miközben az X-Window alkalmazások hagyományosan nagyobb hangsúlyt fektetnek a stabilitásra és a funkcionalitásra, addig a Unix felhasználók egyszerű ablakokat használnak a működést biztosítására, ezért még a Dokumentum-nézet formára sincs gyakran szükség egy alkalmazás létrehozásához. A Qt-val, mint többplatformos eszközzel, a fejlesztőknek lehetőségük van mind MS Windows (tm), mind Unix rendszerek alá fejleszteni. (Ezt a mondatot nem értem!!!!!!!!!!!!!!) Olyan alkalmazások a hiányában, amelyek képesek az u.n. "child window"-k kezelésére, a Windows szabványosodott, ez a Qt könyvtárnak köszönhető, de a Unix felhasználók is profitálnak ebből a felépítésből. !!!!!!!!!!!!!Mit is jelent az MDI? Egy MDI alkalmazásnak általában u.a. a koncepciója, mint egy szokásos alkalmazásnak -amint azt feljebb már leírtuk-,hogy tartalmaz egy alkalmazást és egy főablakot. A nézet terület azonban egy kicsit más: nézetet közvetlenül nem használunk arra, hogy megjelenítse az adatokat, hogy dolgozzunk velük, hanem arra használjuk, hogy kezelje a többi ablakot, mint egy magas szintű főablak. Ezek az ablakok alkotják most az előbbi kilátó területet, valamint a fő különbség az, hogy a kapcsolat láncolata megváltozik az

alkalmazáshívás -> főablak -> kilátó -ról azalkalmazáshívás -> főablak -> kilátó -> aktív "child window" -ra
A nézet így számos tevékenység elvégzésére képes: Most, már "teljes" elemeket használunk -pl a QMultiLineEdit- "child windiws"-ként, mondjuk egy alkalmazáshoz, amelyik egy ablakkal rendelkezik és minden "child window" a saját adataiért felel. Ez nevezhető "Multiple Document Interface - Összetett dokumentumfelület"-nek, ahol minden "child window" olyan, mint egy dokumentum. Az alkalmazás biztosítja azokat az eljárásokat, amelyekre a "child window"-knak szükségük van, mint pl. a kivágás, másolás. Ennek a dokumentumnézet koncepciónak a kiterjesztésével további lehetőségekhez jutunk: képzeljük el, hogy a főablakban annyi "child window"-t nyithatunk meg, amennyit szeretnénk, és hogy az új "child window"-k egészen új nézetét adhatják annak a dokumentumnak, amelyet egy másik "child window" már mutat. Ennek megszervezéséhez szükség van a már leírt három objektumos formába való elkülönítésre, de ez nem korlátozza a megnyitott dokumentum példányinak számát, ugyanúgy, ahogy nézetek számát sem.Szerencsére a Qt 2.1 rendelkezik azzal a lehetőséggel, hogy ilyen alkalmazásokat hozzunk létre, és a Kdevelop is biztosítja ezt keretalkalmazásaival, mind a csak Qt programoknál, mind a KDE 2 alkalmazásoknál ugyanazon a felületen; tehát szabadon megválasztható, hogy melyik típushoz szeretnénk fejleszteni. A KDE 2 felületek még több lehetőséget kínálnak a könyvtár-funkciók, és a végrehajtás közbeni kommunikáció által, de ezeknek a technikáknak a bemutatása egy újabb leírásnak képezhetik csak tárgyát.Most már felkészült a KDE 2-re való fejlesztésre - csak kövesse a következő fejezetet, hogy megismerje a Kdevelop által, az alkalmazásfejlesztéshez biztosított funkciókat. Előállítjuk majd a KScribble példaalkalmazásunk keretét és elolvashatja az MDI alkalmazások programozásának praktikus szempontjait.
Következő Előző Tartalom