KDE arhitektuuri ülevaade

Tänapäeval on 3D graafika renderdamise de facto standard OpenGL. Selle spetsifikatsiooni teostusi pakuvad Microsoft Windows, Mac OS X ja XFree86, mis tihti toetavad ka nüüdisaegsete graafikakaartide pakutavaid riistvaralise kiirendamise võimalusi. OpenGL ise tegeleb ainult renderdamisega konkreetses pildimälu piirkonnas GL konteksti vahendusel ega suhtle mingil määral keskkonna tööriistakomplektiga.

Qt pakub vidinat QGLWidget, mis kapseldab akna sellega seotud GL kontekstiga. Põhimõtteliselt tähendab see selle muutmist alamklassiks ja mõningate meetodite taasteostamist.

Üldiselt toimib QGLWidget nagu üks vidin ikka, s.t. et on võimalik hiiresündmusi töödelda nagu tavaliselt, vidina suurust muuta ja kombineerida seda esitamisel muude vidinatega.

---

---

Qt sisaldab mõningaid näiteid QGLWidgeti kasutamise kohta oma demos. Õppevahendid leiab siit, rohkem infot ja OpenGL selgitusi aga OpenGL koduleheküljelt.

OpenGL on 3D graafika joonistamise suhteliselt süvataseme liides. Nii nagu annab QCanvas programmeerijate käsutusse kõrgtaseme liidese objektide ja nende omaduste käsitlemiseks, nii on olemas kõrgtaseme liidesed ka 3D graafika puhul. Üks menukamaid on Open Inventor. Algselt töötas selle välja SGI, tänapäeval on aga olemas ka vaba tarkvara teostus Coin, mida on täiendatud seda Qt-ga siduva tööriistakomplektiga SoQt.

Open Inventori aluseks on niinimetatud stseen. Stseeni võib hoida kõvakettal salvestatuna spetsiaalsesse vormingusse, mis on lähedane VRML-vorminguga. Stseen koosneb objektidest, mida nimetatakse sõlmedeks. Open Inventor pakub omalt poolt arvukalt taaskasutatavaid sõlmi, näiteks kuubid, silindrid ja võrgud, samuti valgusallikad, kaamerad jne. Sõlmi esindavad C++ klassid ning neid võib kombineerida ja alamklassiks muuta.

Open Inventori sissejuhatuse leiab siit (üldiselt võib seda artiklit lugedes mõttes SoXt asemele panna SoQt).

Toimingumuster lubab küll kapseldada kasutaja käivitatud toimingud objekti, mille saab "torgata" kuhugi menüü- või tööriistaribale, kuid see ei lahenda veel menüü enda konstrueerimise probleemi. Tuleb ju kõik hüpikmenüüd luua C++ koodis ja selgelt lisada sinna toimingud teatud järjekorras, pidades silmas standardtoimingute stiilijuhiseid. Nii on üsna raske lubada kasutajal kohandada menüüsid või muuta kiirklahve oma vajadustele kohasemaks ilma lähtekoodi ennast muutmata.

Selle probleemi lahendab klasside kogum nimetusega XMLGUI. Põhimõtteliselt eraldab see toimingud (C++ koodis) nende esinemisest menüü- ja tööriistaribadel (XML koodis). Ilma lähtekoodi muutmata saab menüüsid hõlpsasti kohandada lihtsalt XML-faili muutes. Lisaks aitab see tagada, et standardtoimingud (näiteks Fail->Ava või Abi->Info) esinevad just seal, kus stiilijuhised ette näevad. XMLGUI on eriti oluline moodulprogrammides, kus menüüriba elemendid võivad pärineda erinevatelt pluginatelt või komponentidelt.

KDE tipptaseme akna klassi KMainWindow eellane on KXMLGUIClient, mistõttu see toetab automaatselt XMLGUI-d. Kõigi selles loodud toimingute eellane peab olema kliendi actionCollection(). Siis loob createGUI() väljakutse terve menüü- ja tööriistaribade komplekti, mida defineerib rakenduse XML-fail (mugavuse mõttes on see sufiksiga ui.rc).

Järgnevas võtame näiteks KDE pildinäitaja KView. Sellel on ui.rc fail nimega kviewui.rc, mis on paigaldatud koodijupiga Makefile.am

rcdir = $(kde_datadir)/kview
rc_DATA = kviewui.rc

See on katke failist kviewui.rc. Lihtsuse mõttes näitame ainult menüü Vaade definitsiooni.

<!DOCTYPE kpartgui>
<kpartgui name="kview">
  <MenuBar>
    <Menu name="view" >
      <Action name="zoom50" />
      <Action name="zoom100" />
      <Action name="zoom200" />
      <Action name="zoomMaxpect" />
      <Separator/>
      <Action name="fullscreen" />
    </Menu>
  </MenuBar>
</kpartgui>

Vastav osa C++ keeles kõlab:

KStdAction::zoomIn    ( this, SLOT(slotZoomIn()), actionCollection() );
  KStdAction::zoomOut   ( this, SLOT(slotZoomOut()), actionCollection() );
  KStdAction::zoom      ( this, SLOT(slotZoom()), actionCollection() );
  new KAction           ( i18n("&Half size"), ALT+Key_0, 
                          this, SLOT(slotHalfSize()), 
                          actionCollection(), "zoom50" );
  new KAction           ( i18n("&Normal size"), ALT+Key_1,
                          this, SLOT(slotDoubleSize()), 
                          actionCollection(), "zoom100" );
  new KAction           ( i18n("&Double size"), ALT+Key_2, 
                          this, SLOT(slotDoubleSize()), 
                          actionCollection(), "zoom200" );
  new KAction           ( i18n("&Fill Screen"), ALT+Key_3, 
                          this, SLOT(slotFillScreen()), 
                          actionCollection(), "zoomMaxpect" );
  new KAction           ( i18n("Fullscreen &Mode"), CTRL+SHIFT+Key_F, 
                          this, SLOT(slotFullScreen()), 
                          actionCollection(), "fullscreen" );

Sellise GUI definitsiooni põhjal loodud menüü Vaade näeb välja niisugune:

---

---

XML-fail algab dokumenditüübi deklaratsiooniga. Kpartgui DTD leiab kdelibs'i lähtekoodis failis kdeui/kpartgui.dtd. Faili väliseim element sisaldab atribuudina rakenduse eksemplari nime. See võib sisaldada ka versiooninumbrit kujul "version=2". Viimane on kasulik rakenduse uue versiooni korral, kui menüüstruktuuri on muudetud, näiteks lisatud uusi võimalusi. Kui suurendada faili ui.rc versiooninumbrit, kontrollib KDE, et faili kohandatud versioonid eemaldataks ja kasutataks just uut faili.

Järgmine rida <MenuBar> sisaldab menüüriba deklaratsiooni. Lisada võib ka suvalise arvu <ToolBar> deklaratsioone, kui soovid tööriistaribasid luua. Menüü sisaldab alammenüüd nimega "view". See nimi on juba eelnevalt defineeritud ja nii võibki pildil näha sõna "View" (eestindatud menüüs oleks see "Vaade"). Kui deklareerida oma alammenüü, tuleb nende nimetus vahetult lisada. Nii on rakendusel KView alammenüü "Image" (eestindatult "Pilt"), mis tuleb deklareerida nii:

<Menu name="image" >
   <text>&amp;Image</text>
   ...
</Menu>

KDE automake-raamistik võimaldab sellised nimetused automaatselt välja noppida ja panna rakenduse .po faili, mida siis tõlkijad saavad tarvitada rakenduse emakeelde panekul. Pane tähele, et kiirklahvi tähis "&" tuleb kirjutada XML-i reeglitele vastavalt "&".

Vaatame uuesti meie näidet. KView menüüs Vaade on mitu kohandamistoimingut: zoom50, zoom100, zoom200, zoomMaxpect ja fullscreen, mis on deklareeritud elemendiga <Action>. Pildil nähtavale eraldusjoonele vastab element <Separator>.

Pane tähele, et mõnel elemendil ei ole XML-failis vastet. Need on niinimetatud standardtoimingud, mille loob klass KStdAction. Kui lood mingeid toiminguid oma rakenduses (nagu ülaltoodud C++ näites), lisatakse standardtoimingud automaatselt eelnevalt määratud asukohta, mõnikord kaasnevad nendega ka ikoon ja kiirklahv. Neid asukohti saab tuvastada kdelibs lähtekoodi failis kdeui/ui_standards.rc.

Tööriistaribade puhul vaatame nüüd Konquerori GUI definitsiooni. See katke määratleb asukohariba, mis sisaldab endas URL-ide sisestamise välja.

<ToolBar name="locationToolBar" fullWidth="true" newline="true" >
  <text>Location Toolbar</text>
  <Action name="clear_location" />
  <Action name="location_label" />
  <Action name="toolbar_url_combo" />
  <Action name="go_url" />
</ToolBar>

Märkame kohe, et siin on märksa rohkem atribuute kui menüüribal, sealhulgas:

On ilmne, et XML saab sisaldada ainult kasutajaliidese staatilist kirjeldust. Sageli esineb aga menüüsid, mis käivitamisel muutuvad. Näiteks Konquerori menüü Asukoht sisaldab rea elemente Ava kasutades XXX, kus XXX asemel seisab rakendus, mis võib antud MIME tüübiga faili avada. Dokumendi muutumisel muutub ka nende menüüelementide nimekiri. XMLGUI suudab selliste juhtumitega toime tulla niinimetatud toimingunimekirjadega. XML-failis deklareeritakse toimingunimekiri ühe elemendina, kuid see sisaldab mitu toimingut, mis lisatakse menüüsse käivitamisel. Meie toodud näide teostatakse Konquerori XML-failis järgmise deklaratsiooniga:

<Menu name="file">
  <text>&amp;Location</text>
  ...
  <ActionList name="openwith">
  ...
</Menu>

Näidatavate toimingute lisamiseks kasutatakse siin funktsiooni KXMLGUIClient::plugActionList(), eemaldamiseks aga funktsiooni KXMLGuiClient::unplugActionList(). Uuendamisrutiin näeb välja selline:

void MainWindow::updateOpenWithActions()
{
    unplugActionList("openwith");
    openWithActions.clear();
    for ( /* iterate over the relevant services */ ) {
        KAction *action = new KAction( ...);
        openWithActions.append(action);
    }
    plugActionList("openwith", openWithActions);
}

Pane tähele, et erinevalt staatilistest toimingutest ei ole need loodud eellasest toimingukogu baasil ja sestab tuleb sul endal nende kustutamise eest hoolt kanda. Lihtsaim viis selleks on kasutada - nagu ülaltoodud näites - openWithActions.setAutoDelete(true).

Toodud näidetes oli tegemist ainult peaakna menüüriba ja tööriistaribade loomisega. Sellisel juhul on nende loomise protsess kasutaja eest täielikult peidetud väljakutse createGUI() taha (kui sul pole just kohandatud konteinereid). Kuid võib esineda juhtumeid, kus soovid konstrueerida muid konteinereid ja täita need XML-failist võetavate GUI definitsioonidega. Üheks näiteks võivad olla kontekstimenüüd. Kontekstimenüü viida saamiseks tuleb seda küsida kliendi "tehaselt" (factory):

void MainWindow::popupRequested()
{
    QWidget *w = factory()->container("context_popup", this);
    QPopupMenu *popup = static_cast<QPopupMenu *>(w);
    popup->exec(QCursor::pos());
}

Meetod KXMLGUIFactory::container() püüab leida XML-failis antud nimega konteinerit. Seega võib definitsioon välja näha näiteks nii:

...
<Menu name="context_popup">
  <Action name="file_add"/>
  <Action name="file_remove"/>
</Menu>
...

MIME tüüpe kasutatakse kirjeldamaks failide või andmekogumite sisu tüüpi. Algselt võeti need kasutusele pildi, helifailide jne. saatmiseks e-postitsi (MIME tähendabki "mitmeotstarbelised e-kirja laiendid", inglise keeles "Multipurpose Internet Mail Extensions"). Hiljem hakati neid kasutama ka veebilehitsejas selle määramiseks, kuidas esitada veebiserverist kasutajale saadetavaid andmeid. Näiteks HTML-leheküljel on MIME tüüp "text/html", PostScript-failil aga "application/postscript". KDE kasutab MIME tüüpe päris paljudes kohtades:

Toodud näidetest peaks selguma, et MIME käsitlemine on päris keerukas. Esmalt on vaja luua failinimede seosed MIME tüüpidega. KDE astub veel sammukese edasi ja lubab isegi faili sisu MIME tüübiga siduda, kui näiteks failinimi ei peaks kättesaadav olema. Teiseks tuleb MIME tüübid siduda rakenduste või teekidega, mis suudavad teatud tüüpi faili näidata või redigeerida või sellele pisipildi luua.

Andmete või failide MIME tüübi selgitamiseks on mitmeid API-sid. Üldiselt tähendavad nad kõik teatud kompromissi kiiruse ja usaldusväärsuse vahel. Failitüübi võib leida ainult failinime vaadates (s.t. enamikul juhtudel failinime laiendit uurides). Näiteks foo.jpg on tavaliselt "image/jpeg". Kui laiendit ei ole, pole see meetod mõistagi eriti turvaline ja tuleb vaadata faili sisu. See on loomulikult aeglasem, eriti failide korral, mida tuleb HTTP abil kõigepealt alla laadida. Sisupõhine meetod tugineb failile KDEDIR/share/mimelnk/magic, mida siinkohal on keerukas pikemalt käsitleda. Kuid üldiselt saab MIME tüübi info süsteemile suhteliselt lihtsalt teatavaks teha .desktop-faili paigaldades ning seda kasutatakse agaralt ja tõhusalt kõigis KDE teekides.

Defineerime oma uuele programmile foobar tüübi "application/x-foo". Selleks tuleb kirjutada fail foo.desktop ja paigaldada see kataloogi KDEDIR/share/mimelnk/application (see on tavapärane asukoht, mis distributsiooniti võib siiski erineda). Selleks tuleb failile Makefile.am lisada:

mimedir = $(kde_mimedir)/application
mime_DATA = foo.desktop
EXTRA_DIST = $(mime_DATA)

Fail foo.desktop peaks välja nägema selline:

[Desktop Entry]
Type=MimeType
MimeType=application/x-foo
Icon=fooicon
Patterns=*.foo;
DefaultApp=foobar
Comment=Foo Data File
Comment[et]=Foo andmefail

Kirje "Comment" on mõeldud tõlkimiseks. Et .desktop-fail määrab ka ikooni, tuleb paigaldada ikoon fooicon.png, mis näitab faili näiteks Konqueroris.

KDE teekides on selline tüübidefinitsioon seotud KMimeType eksemplariga. Kasuta seda umbes nii, nagu alljärgnevas näites:

KMimeType::Ptr type = KMimeType::mimeType("application/x-foo");
cout << "Type:    " << type->name() < endl;
cout << "Icon:    " << type->icon() < endl;
cout << "Comment: " << type->icon() < endl;
QStringList patterns = type->patterns();
QStringList::ConstIterator it;
for (it = patterns.begin(); it != patterns.end(); ++it)
  cout << "Pattern: " << (*it) << endl;

Kiire meetod failitüübi määramiseks on KMimeType::findByURL(). See otsib URL-i stringi ja enamasti määrab tüübi laiendi põhjal. Teatud protokollide (nt. http, man, info) korral seda aga ei kasutata. Näiteks Perlis kirjutatud veebiserverite CGI skriptidel on sageli laiend .pl, mis osutab tüübile "text/x-perl". Samas on serveri edastatud fail hoopis selle skripti väljund, milleks on enamasti HTML. Sellisel juhul tagastab KMimeType::findByURL() MIME tüübi "application/octet-stream" (kasutatav KMimeType::defaultMimeType() vahendusel), mis osutab võimetusele tüüpi tuvastada.

KMimeType::Ptr type = KMimeType::findByURL("/home/bernd/foobar.jpg");
if (type->name() == KMimeType::defaultMimeType())
    cout << "Could not find out type" << endl;
else
    cout << "Type: " << type->name() << endl;

(sellel meetodil on veel mõningaid argumente, kuid need on dokumenteerimata, mistõttu võib nad antud juhul kõrvale jätta)

Sellisel juhul võib olla mõttekam tuvastada MIME tüüp faili sisu, mitte aga faili nime järgi. See on usaldusväärsem, kuid ka aeglasem meetod, sest selleks tuleb lugeda vähemalt osa failist. Seda teeb klass KMimeMagic, mille veakäsitlus on veidi teistsugune:

KMimeMagicResult *result = KMimeMagic::self()->findFileType("/home/bernd/foobar.jpg");
if (!result || !result->isValid())
    cout << "Could not find out type" << endl;
else
    cout << "Type: " << result->mimeType() << endl;

Selle funktsiooni variant võimaldab määrata ka mälutüki tüüpi. Seda kasutab näiteks Kate esiletõstmise režiimi tuvastamiseks:

QByteArray array;
...
KMimeMagicResult *result = KMimeMagic::self()->findBufferType(array);
if (!result || !result->isValid())
    cout << "Could not find out type" << endl;
else
    cout << "Type: " << result->mimeType() << endl;

Mõistagi suudab isegi KMimeMagic määrata failitüüpi ainult kohalike failide sisu põhjal. Võrgufailide jaoks on veel üks võimalus:

KURL url("http://developer.kde.org/favicon.ico");
QString type = KIO::NetAccess::mimetype(url);
if (type == KMimeType::defaultMimeType())
    cout << "Could not find out type" << endl;
else
    cout << "Type: " << type << endl;

See käivitab KIO töö, laadides alla osa failist ja uurides seda. Arvesta, et see funktsioon on tõenäoliselt päris aeglane ja blokeerib programmi töö. Tavaliselt on seda mõtet kasutada ainult siis, kui KMimeType::findByURL() tagastab "application/octet-stream".

Kui sa aga ei soovi rakenduse tööd blokeerida, võib ka vahetult käivitada KIO töö ja luua ühenduse selle mõningate signaalidega:

void FooClass::findType()
{
    KURL url("http://developer.kde.org/favicon.ico");
    KIO::MimetypeJob *job = KIO::mimetype(url);
    connect( job, SIGNAL(result(KIO::Job*)),
             this, SLOT(mimeResult(KIO::Job*)) );
}

void FooClass::mimeResult(KIO::Job *job)
{
    if (job->error())
        job->showErrorDialog();
    else
        cout << "MIME type: " << ((KIO::MimetypeJob *)job)->mimetype() << endl;
}

Rakenduse paigaldamisel paigaldab see oma .desktop-faili, mis sisaldab loetelu MIME tüüpidest, mida rakendus suudab avada. Ka komponendid, näiteks KParts, teatavad samasugust infot oma .desktop-failide vahendusel. Nii on enamasti olemas mitu programmi ja komponenti, mis suudavad antud MIME tüüpi käsitleda. Nende nimekirja võib leida klassist KServiceTypeProfile:

KService::OfferList offers = KServiceTypeProfile::offers("text/html", "Application");
KService::OfferList::ConstIterator it;
for (it = offers.begin(); it != offers.end(); ++it) {
    KService::Ptr service = (*it);
    cout << "Name: " << service->name() << endl;
}

Selle funktsiooni tagastatav väärtus ongi pakutavate teenuste nimekiri. KServiceOffer objekt liidab KService::Ptr eelistuse numbriga. KServiceTypeProfile::offers() tagastatav nimekiri on järjestatud vastavalt kasutaja eelistustele. Kasutaja saab seda muuta, kutsudes välja "keditfiletype text/html" või valides HTML-faili korral Konquerori kontekstimenüüst kirje Redigeeri failitüüpi.

Toodud näites nõuti rakenduste nimekirja, mis toetaks tüüpi text/html. Nimekiri sisaldab muu hulgas HTML-redaktoreid, näiteks Quanta. Teise argumendi "Application" võib anda ka "KParts::ReadOnlyPart". Sellisel juhul tagastatakse põimitavate komponentide nimekiri, mis suudavad HTML-i esitada, näiteks KHTML.

Enamasti puudub vajadus saada teada kõiki MIME tüübi ja teenuse tüübi kombinatsiooni käsitleda suutvaid teenuseid. Siis sobib kasutada mugavat funktsiooni, mis tagastab ainult kõige eelistatuma teenuse:

KService::Ptr offer = KServiceTypeProfile::preferredService("text/html", "Application");
if (offer)
    cout << "Name: " << service->name() << endl;
else
    cout << "No appropriate service found" << endl;

Keerulisemate päringute jaoks on mõeldud võimas CORBA taoline maakler.

Rakenduse teenuse käivitamiseks mõne URL-iga on kasutatav KRun:

KURL::List urlList;
urlList << "http://www.ietf.org/rfc/rfc1341.txt?number=1341";
urlList << "http://www.ietf.org/rfc/rfc2046.txt?number=2046";
KRun::run(offer.service(), urlList);

Selles osas toome ära mõned API-d, mis on teatud määral seotud meie eelneva jutuga.

Ikooni hankimine URL-ile. See uurib URL-i tüüpi ja tagastab sellega seotud ikooni.

KURL url("ftp://ftp.kde.org/pub/incoming/wibble.c");
QString icon = KMimeType::iconForURL(url);

URL-i käivitamine. See uurib URL-i tüüpi ja käivitab kasutaja antud tüübi korral eelistatud programmi.

KURL url("http://dot.kde.org");
new KRun(url);

Veebiajastul on äärmiselt oluline, et rakendused võiksid kasutada ressursse kõikjal internetis: nad peavad suutma tõmmata faile veebiserverist, salvestada faile FTP serverisse või lugeda veebiserverist e-posti. Tihtipeale nimetatakse sellist võimet kasutada faile sõltumata nende asukohast võrguläbipaistvuseks.

Minevikus üritati seda saavutada mitmel erineval moel. Eakas NFS failisüsteem proovis teostada võrguläbipaistvust POSIX-i API tasandil. See toimib päris hästi kohalike suletud võrkude korral, kuid jääb jänni ressurssidega, mille kasutamine ei pruugi alati õnnestuda ja ühendus millega võib olla aeglane. Seepärast on oluline asünkroonsus: kui ootad, et veebilehitseja laeks alla mingi saidi, ei pea see blokeerima kasutajaliidest. Samuti ei peaks veebilehekülje renderdamine algama alles siis, kui kätte on saadud kogu lehekülg, vaid käima regulaarselt vastavalt uute andmete saabumisele.

KDE teekides teostab võrguläbipaistvuse KIO API. Selle arhitektuuri keskne mõiste on IO töö. Töö võib faile kopeerida, kustutada vms. Töö käivitamisel tegutseb see taustal ega blokeeri rakendust. Kogu töö tagasiside rakendusele, näiteks andmete edastamine või edenemisinfo, käib läbi integreeritud Qt sündmusesilmuse.

Töötamiseks taustal on mõeldud konkreetseid ülesandeid täitvad IO moodulid. IO moodulid käivitatakse eraldi protsessidena ja nendega suheldakse UNIX-i domeeni pesade vahendusel. Sel moel ei ole vajalik mitmelõimsus ning ebastabiilsed moodulid ei tekita neid kasutava rakenduse krahhi.

Failide asukohti väljendavad tavapäraselt URL-id. KDE puhul aga ei laienda URL-id lihtsalt kättesaadavate failide vahemikku väljapoole kohalikku failisüsteemi, vaid toimivad ka vastupidi, lubades näiteks sirvida pakitud tar-faile. See saavutatakse URL-ide pesastamisega. Nii võib näiteks HTTP-serveris asuval tar-arhiivi failil olla URL

http://www-com.physik.hu-berlin.de/~bernd/article.tgz#tar:/paper.tex

Enamasti luuakse tööd KIO nimeruumis funktsioone välja kutsudes. Need funktsioonid kasutavad argumendina üht või kaht URL-i ja võib-olla vastavalt vajadusele veel mõningaid parameetreid. Kui töö on lõpetatud, väljastatakse signaal result(KIO::Job*). Signaali väljastamise järel kustutab töö iseenda. Toome siin tüüpilise kasutamise näite:

void FooClass::makeDirectory()
{
    SimpleJob *job = KIO::mkdir(KURL("file:/home/bernd/kiodir"));
    connect( job, SIGNAL(result(KIO::Job*)), 
             this, SLOT(mkdirResult(KIO::Job*)) );
}

void FooClass::mkdirResult(KIO::Job *job)
{
    if (job->error())
        job->showErrorDialog();
    else
        cout << "mkdir went fine" << endl;
}

Sõltuvalt töö tüübist võib olla vajalik ühenduse loomine ka muude signaalidega.

Toome siin ülevaate võimalikest funktsioonidest:

Nii töö KIO::stat() kui ka töö KIO::listDir() tagastavad oma tulemused vastavalt tüübina UDSEntry ja UDSEntryList. Viimane on defineeritud kui QValueList<UDSEntry>. UDS tähendab "universaalne kataloogiteenus" (inglise keeles "Universal Directory Service"). Selle taga seisab põhimõte, et kataloogikirje sisaldab ainult seda infot, mida IO moodul suudab pakkuda. Näiteks ei paku http moodul infot kasutamisõiguste või faili omaniku kohta. UDSEntry on UDSAtom-ite loend. Iga aatom pakub teatud konkreetse infoühiku. See koosneb tüübist, mille on salvestanud m_uds, ning sõltuvalt tüübist kas täisarvulisest väärtusest (m_long) või stringilisest väärtusest (m_str).

Praegu on defineeritud järgmised tüübid:

Kuigi failiinfo salvestamise viis klassis UDSEntry on paindlik ja praktiline IO mooduli seisukohalt vaadates, on see rakenduse programmeerija vaatevinklist korralik segadik. Näiteks faili MIME tüübi tuvastamiseks tuleb ükshaaval läbi uurida kõik aatomid ja kontrollida, kas m_uds on ikka UDS_MIME_TYPE. Õnneks on olemas API, mida on palju lihtsam kasutada: klass KFileItem.

Sageli on KIO asünkroonne API liiga keerukas kasutada, seepärast ei ole ka täieliku asünkroonsuse teostamine esmatähtis. Näiteks programmi korral, mus suudab korraga käsitleda ainult üht dokumenti, ei ole nagunii midagi teha, kui programm parajasti dokumenti alla laeb. Sellistel lihtsatel juhtudel on olemas märksa lihtsam API staatiliste funktsioonide kogumi näol KIO::NetAccess-is. Näiteks faili kopeerimiseks kasuta:

KURL source, target;
source = ...;
target = ...
KIO::NetAccess::copy(source, target);

See funktsioon tagastab pärast terve kopeerimisprotsessi lõpetamist. Siiski pakub see meetod edenemisdialoogi ja kontrollib, et rakendus töötleb ümberjoonistamissündmusi.

Eriti huvitav funktsioonide kombinatsioon o download() koos funktsiooniga removeTempFile(). Esimene tõmbab määratud URL-iga faili ja salvestab selle unikaalse nimega ajutise failina. Nimi salvestatakse teise argumendina. Kui tegemist on kohaliku URL-iga, faili alla ei laeta ja teiseks argumendiks määratakse kohaliku faili nimi. Funktsioon removeTempFile() kustutab argumendina antud faili, kui see on varasema allalaadimise tulemus. Kui mitte, siis ei tee see midagi. Nii on sellise kombinatsiooni abil väga hea laadida faile alla sõltumata nende asukohast järgmise koodijupiga:

KURL url;
url = ...;
QString tempFile;
if (KIO::NetAccess::download(url, tempFile) {
    // load the file with the name tempFile
    KIO::NetAccess::removeTempFile(tempFile);
}

Nagu eespool nägime, on IO tööde liides üpris abstraktne ega võta arvesse infovahetust rakenduse ja IO mooduli vahel, mis on protokollipõhine. Alati selline lähenemine ei sobi. Näiteks võid soovida anda HTTP moodulile teatud parameetrid kontrollimaks puhvri käitumist või saata koos sooviga kimbu küpsiseid. Selleks on sisse toodud metaandmed. Töö loomisel saab seda seadistada metaandmeid lisades. Iga metaandmete ühik sisaldab võtme-väärtuse paari. Näiteks selleks, et HTTP moodul ei laeks veebilehekülge puhvrist, võib kasutada:

void FooClass::reloadPage()
{
    KURL url("http://www.kdevelop.org/index.html");
    KIO::TransferJob *job = KIO::get(url, true, false);
    job->addMetaData("cache", "reload");
    ...
}

Sama meetodit saab kasutada ka teistpidi, s.t. moodulilt rakendusele suunduva suhtlemise korral. Meetod Job::queryMetaData() pärib mooduli edastatud võtme väärtust. HTTP mooduli korral võib näiteks olla võti "modified", mis sisaldab (stringi kujul) kuupäeva, millal veebilehekülge viimati muudeti. Toome ka kasutamisnäite:

void FooClass::printModifiedDate()
{
    KURL url("http://developer.kde.org/documentation/kde2arch/index.html");
    KIO::TransferJob *job = KIO::get(url, true, false);
    connect( job, SIGNAL(result(KIO::Job*)),
             this, SLOT(transferResult(KIO::Job*)) );
}

void FooClass::transferResult(KIO::Job *job)
{
    QString mimetype;
    if (job->error())
        job->showErrorDialog();
    else {
        KIO::TransferJob *transferJob = (KIO::TransferJob*) job;
        QString modified = transferJob->queryMetaData("modified");
        cout << "Last modified: " << modified << endl;
}

KIO API kasutamisel ei ole tavaliselt vajalik pead vaevata IO moodulite käivitamise ja nendega suhtlemise üksikasjade pärast. Kõige tavalisem on käivitada töö teatud parameetritega ja tegelda töö väljastatud signaalidega.

Tagaplaanil on aga kõik palju keerukam. Tööd luues seatakse see järjekorda. Kui rakendus läheb tagasi sündmusesilmusesse, eraldab KIO mooduliprotsessid järjekorras olevatele töödele. Esimese töö korral on kõik lihtne: käivitatakse vajaliku protokolli IO moodul. Kuid pärast töö lõpetamist (näiteks allalaadimist HTTP-serverilt) ei tapeta tööd otsekohe, vaid see lükatakse jõude moodulite puhvrisse ja tapetakse pärast seda, kui see on olnud mingi aja mitteaktiivne (praegu on väärtuseks 3 minutit). Kui saabub uus soov samale protokollile ja masinale, võetakse moodul uuesti kasutusele. Selle ilmne eelis on tõik, et nii saab tunduvalt kärpida sama masina puhul sarnaseid töid ette võttes muidu uute protsesside loomisele ja võib-olla ka autentimisele kuluvaid ressursse ja aega.

Mõistagi on taaskasutamne võimalik ainult siis, kui olemasolev moodul on oma varasema töö juba lõpetanud. Kui uus soov saabub ajal, mil mooduliprotsess veel käib, tuleb käivitada uus protsess. Ülaltoodud API näiteks ei olnud piiratud uute mooduliprotsesside loomine: kui käivitad järjest 20 erineva faili allalaadimise, käivitab KIO 20 mooduliprotsessi. Sellist moodulite omistamist töödele nimetatakse vahetuks omistamiseks. See ei ole aga mitte alati eelistatav viis, sest võib nõuda hulganisti mälu ja koormata tugevasti nii kliendi kui serveri masinat.

Seepärast on olemas ka teine võimalus: töid saab ajastada. Sellisel juhul luuakse protokolli kohta ainult teatud arv (praegu 3) mooduliprotsesse. Kui lood rohkem töid, seatakse need järjekorda ja täidetakse siis, kui mooduliprotsess jääb jõude. See käib nii:

KURL url("http://developer.kde.org/documentation/kde2arch/index.html");
KIO::TransferJob *job = KIO::get(url, true, false);
KIO::Scheduler::scheduleJob(job);

Kolmas võimalus on ühendusepõhine. Näiteks IMAP mooduli korral ei ole erilist mõtet käivitada ühe ja sama serveri puhul mitu protsessi. Nii või teisiti saab korraga toimida ainult üks IMAP ühendus. Sellisel juhul peab rakendus otseselt suhtlema mooduliga, kõrvaldades mooduli teatud ühenduselt ja seejärel omistama kõik tööd, mis käivad üle ühe ühenduse, samale moodulile. Ka selleks sobib suurepäraselt KIO::Scheduler:

KURL baseUrl("imap://bernd@albert.physik.hu-berlin.de");
KIO::Slave *slave = KIO::Scheduler::getConnectedSlave(baseUrl);

KIO::TransferJob *job1 = KIO::get(KURL(baseUrl, "/INBOX;UID=79374"));
KIO::Scheduler::assignJobToSlave(slave, job1);

KIO::TransferJob *job2 = KIO::get(KURL(baseUrl, "/INBOX;UID=86793"));
KIO::Scheduler::assignJobToSlave(slave, job2);

...

KIO::Scheduler::disconnectSlave(slave);

Moodul on mõtet lahti ühendada alles pärast seda, kui kõik sellele omistatud tööd on kindlasti lõpetatud.

Siin vaatame nüüd seda, kuidas lisada süsteemile uus IO moodul. Sarnaselt teenustele teeb uue IO mooduli süsteemile teatavaks väikese konfiguratsioonifaili paigaldamine. Järgnev Makefile.am koodijupp paigaldab FTP protokolli:

protocoldir = $(kde_servicesdir)
protocol_DATA = ftp.protocol
EXTRA_DIST = $(mime_DATA)

Faili ftp.protocol sisu on selline:

[Protocol]
exec=kio_ftp
protocol=ftp
input=none
output=filesystem
listing=Name,Type,Size,Date,Access,Owner,Group,Link,
reading=true
writing=true
makedir=true
deleting=true
Icon=ftp

Kirje "protocol" määrab, millise protokolli eest antud moodul hoolt kannab. "exec" on (vastupidi sellele, mida sa vahest naiivselt arvasid) moodulit teostava teegi nimi. Mooduli käivitamisel käivitatakse "kdeinit", mis omakorda laeb antud teegi enda aadressiruumi. Nii võib töötavat moodulit käsitleda praktikas küll omaette protsessina, kuigi tegelikult on see teostatud teegina. Selle eeliseks on asjaolu, et nii saab säästa hulgaliselt mälu ja kahandada käivituslinkurile vajalikku aega.

Praegu ei ole kasutusel read "input" ja "output".

Ülejäänud .protocol-faili read määravad ära mooduli omadused. Üldiselt on võimalused, mida moodul peab teostama, palju lihtsamad kui võimalused, mida KIO API rakendustele pakub. Selle põhjuseks on keerukate tööde jagamine mitmeks alamtööks. Näiteks kataloogi sisu näitamiseks rekursiivselt käivitatakse üks töö tippkataloogis. Seejärel käivitatakse iga alamkataloogi sisu leidmiseks uued alamtööd. KIO ajastaja tagab, et korraga ei oleks aktiivsed liiga palju töid. Ka võib KIO näiteks faili kopeerimiseks protokolli korral, mis ei toeta vahetult kopeerimist (näiteks ftp:), lugeda lähtefaili ja seejärel kirjutada andmed sihtfaili. Selleks peab .protocol-fail tegema teatavaks, milliseid toiminguid antud moodul toetab.

Kuna moodulid laetakse jagatud teegina, kuid kujutavad endast autonoomseid programme, erineb nende koodi raamistik mõnevõrra tavalistest jagatud teegi pluginatest. Mooduli käivitamiseks välja kutsutav funktsioon kannab nime kdemain(). See sooritab teatud initsialiseerimine ning läheb seejärel sündmusesilmusesse ja ootab rakenduse soove. Välja näeb see nii:

extern "C" { int kdemain(int argc, char **argv); }

int kdemain(int argc, char **argv)
{
    KLocale::setMainCatalogue("kdelibs");
    KInstance instance("kio_ftp");
    (void) KGlobal::locale();

    if (argc != 4) {
        fprintf(stderr, "Usage: kio_ftp protocol "
                        "domain-socket1 domain-socket2\n");
        exit(-1);
    }

    FtpSlave slave(argv[2], argv[3]);
    slave.dispatchLoop();
    return 0;
}

Moodulid teostatakse KIO::SlaveBase alamklassidena (ülaltoodud näites FtpSlave). Nii vastavad .protocol-failis loetletud toimingud teatud KIO::SlaveBase teatud virtuaalsetele funktsioonidele, mida mooduli teostus peab taasteostama. Toome siin ära võimalike toimingute ja neile vastavate virtuaalsete funktsioonide loendi:

Lisaks on taasteostatavaid funktsioone, mida ei ole ära toodud .protocol-failis. Nende tegevuste puhul määrab KIO automaatselt, kas need on toetatud või mitte (s.t vaiketeostus tagastab vea).

Kõik teostused peavad lõppema ühga kahest väljakutsest: kui tegevus oli edukas, peavad nad kutsuma välja finished(), kui aga tekkis viga, siis tuleb välja kutsuda error() koos veakoodiga esimese ja stringiga teise argumendina. Võimalike veakoodide loendi annab KIO::Error. Teine argument on tavaliselt asjakohane URL. Seda kasutab näiteks KIO::Job::showErrorDialog() inimestele mõistetava veateate loomisel.

Võrguprotokollidele vastavate moodulite puhul võib huvi pakkuda meetodi SlaveBase::setHost() taasteostamine. See kutsutakse välja teatamaks mooduliprotsessile masinat ja porti ning sisselogimiseks vajalikku kasutajanime ja parooli. Üldiselt saab rakenduse saadetud metaandmete päringuks kasutada SlaveBase::metaData(). Teatud võtme metaandmete olemasolu kontrollimiseks on mõeldud SlaveBase::hasMetaData().

Mooduli teostatud toimingute tulemusel saadud andmed tuleb mingil moel tagastada mooduliprotsessi kasutavale rakendusele:

Mõnikord on moodulil vaja suhelda kasutajaga: infosõnumid, autentimisdialoogid või kinnituse küsimine faili ülekirjutamisel.