>Teek tdecore on iga KDE rakenduse põhiraamistik. See pakub ligipääsu seadistamissüsteemile, käsurea võimalustele, ikoonide laadimisele ja nende käsitlemisele, mõningaid spetsiaalseid protsessidevahelise kommunikatsiooni võimalusi, failikäsitlust ning rea muid vahendeid. </para
> pakub hulganisti vidinaid ja standarddialooge, mis Qt-l puuduvad või millel on rohkem võimalusi kui nende Qt analoogidel. Samuti kuulub siia mõningaid vidinaid, mis on Qt vastavate vidinate alamklassid ning kasutaja seisukohalt vaadates KDE töölauaga paremini integreeritud. </para
> sisaldab vahendeid asünkroonseks ja võrguläbipaistvusega sisend-väljundoperatsioonideks ning ligipääsu MIME tüüpide käsitlemisele. Samuti pakub see KDE failidialoogi ja selle abiklasse. </para
>Qt süvataseme pildiloome tugineb neile X11 ja muude aknasüsteemide võimetele, mille jaoks on olemas Qt pordid. Kuid see ka laiendab neid, teostades täiendavaid võimalusi, näiteks teksti ja pikselrastrite afiinsed transformatsioonid. </para>
<para
>Qt 2D joonistamise keskne graafikaklass on <ulink url="kdeapi:qt/QPainter"
></ulink
>. Selle aluseks on <ulink url="kdeapi:qt/QPaintDevice"
></ulink
>. Teostatud on kolm võimalikku joonistamisseadet. <ulink url="kdeapi:qt/QWidget"
></ulink
> esindab vidinat ekraanil. <ulink url="kdeapi:qt/QPrinter"
></ulink
> esindab printerit ja loob PostScript väljundi. <ulink url="kdeapi:qt/QPicture"
></ulink
> tuvastab joonistamiskäsud ja võib salvestada need kettale ning neid hiljem taasesitada. Joonistamiskäskude võimalik salvestusvorming on W3C standard SVG. </para>
<para
>Nii on võimalik renderduskoodi, mida kasutad vidina näitamiseks, pruukida ka trükkimiseks, kusjuures toetatud on samasugused võimalused. Praktikas kasutatakse koodi mõistagi veidi erinevas kontekstis. Vidina kujutamine tehakse peaaegu eranditult vidinaklassi meetodiga paintEvent(). </para>
<programlisting
>void FooWidget::paintEvent()
{
QPainter p(this);
// Setup painter
// Use painter
}
</programlisting>
<para
>Printeri korral tuleb kontrollida, et kasutusel oleks QPrinter::newPage(), mis lõpetab lehekülje ja alustab uut. See ei ole mõistetavalt joonistamisvidinate juures kuigi oluline. Trükkimisel oleks mõttekas ka kasutada koordinaatide arvutamiseks <ulink url="kdeapi:qt/QPaintDeviceMetrics"
>seadmemeetrikat</ulink
>. </para>
</simplesect>
<simplesect id="qpainter-transformations">
<title
>Transformatsioonid</title>
<para
>Vaikimisi joonistab QPainter kasutatud seadme loomulikus koordinaatide süsteemis. See tähendab, et kui joonistad horisontaalteljel joone pikkusega 10 ühikut, joonistatakse see ekraanil 10-pikslise pikkusega rõhtjoonena. Kuid QPainter võib rakendada enne kujundite ja kõverate tegelikku renderdamist ka afiinseid transformatsioone. Afiinne transformatsioon seob x- ja y-koordinaadid lineaarselt x' ja y'-ga vastavalt maatriksile </para>
>Selle 3x3 maatriksi saab määrata funktsiooniga QPainter::setWorldMatrix() ning selle tüüp on <ulink url="kdeapi:qt/QWMatrix"
>QWMatrix</ulink
>. Tavaliselt on see identsusmaatriks, st. m11 ja m22 on üks ning muud parameetrid null. Põhimõtteliselt on olemas kolm erinevat transformatsioonigruppi: </para>
<itemizedlist>
<listitem
><formalpara>
<title
>Lüke</title>
<para
>See liigutab objekti kõik punktid määratud hulga võrra mingis suunas. Lükkemaatriksi saab välja kutsuda QWMatrixi funktsiooniga m.translate(dx, dy). See vastab maatriksile </para>
>See laiendab või ahendab objekti koordinaate, muutes selle ilma moonutusteta suuremaks või väiksemaks. Skaleerimist saab QWMatrixile rakendada m.scale(sx, sy) väljakutsumisega. See vastab maatriksile </para>
>Pöörab objekti. Pööramist saab rakendada m.rotate(nurk) väljakutsumisega. Arvesta, et nurk tuleb anda kraadides, mitte matemaatilise nurgana! Vastav maatriks on </para>
>Transformatsioone võib kombineerida elementaarmaatrikseid korrutades. Arvesta, et maatriksioperatsioonid ei ole üldiselt kommuteeruvad, mistõttu nende mõju tervikuna sõltub sellest, millises järjekorras neid korrutatakse. </para>
</simplesect>
<simplesect id="qpainter-strokeattributes">
<title
>Jooneatribuutide määramine</title>
<para
>Sirgete, kõverate ja polügoonide piirjoonte renderdamist saab modifitseerida spetsiaalset pliiatsit määrates, mida teeb funktsioon QPainter::setPen(). Selle funktsiooni argument on <ulink url="kdeapi:qt/QPen"
>QPen</ulink
> objekt. Selles salvestatud omadused on stiil, värv, ühendusstiil ja otsastiil. </para>
<para
>Pliiatsistiil on loendi <ulink url="kdeapi:qt/Qt#PenStyle-enum"
>Qt::PenStyle</ulink
> liige ning sellel võivad olla järgmised väärtused: </para>
>Polügoonide, ringjoonte või ristkülikute täitestiili saab muuta spetsiaalse pintsli määramisega funktsiooniga QPainter:.setBrush(). See funktsioon kasutab argumendina <ulink url="kdeapi:qt/QBrush"
>QBrush</ulink
> objekti. Pintslit saab konstrueerida neljal moel: </para>
<itemizedlist>
<listitem>
<para
>QBrush::QBrush() - loob pintsli, mis ei täida kujundeid.</para>
</listitem>
<listitem>
<para
>QBrush::QBrush(Pintslistiil) - loob musta pintsli ühega all näidatud vaikemustritest.</para>
</listitem>
<listitem>
<para
>QBrush::QBrush(const QColor &, Pintslistiil) - loob värvilise pintsli ühega all näidatud mustritest.</para>
</listitem>
<listitem>
<para
>QBrush::QBrush(const QColor &, const QPixmap) - loob värvilise pintsli omaloodud mustriga, mis antakse teise parameetrina.</para>
</listitem>
</itemizedlist>
<para
>Vaikimisi pintslistiil pärineb loendist <ulink url="kdeapi:qt/Qt#BrushStyle-enum"
>Qt::BrushStyle</ulink
>. Toome siin ära pildi kõigi eelnevalt määratud mustritega: </para>
>Pintsli käitumist saab veel täpsemalt kohandada funktsiooniga QPainter::setBrushOrigin(). </para>
</simplesect>
<simplesect id="qpainter-color">
<title
>Värv</title>
<para
>Värvidel on oma osa nii kõverate esitamisel kui kujundite täitmisel. Qt-s esindab värve klass <ulink url="kdeapi:qt/QColor"
>QColor</ulink
>. Qt ei toeta selliseid graafilisi võimalusi, nagu ICC värviprofiilid ja värvikorrektsioon. Värvid konstrueeritakse tavaliselt nende punast, rohelist ja sinist komponenti määratledes, kuna RGB on ka viis, millega esitatakse pikslid monitoril. </para>
<para
>Võimalik on küll kasutada ka tooni, küllastust ja väärtust. Selline HSV on kasutusel GTK värvidialoogis, näiteks rakenduses Gimp. Siin vastab toon värviketta nurgale, küllastus aga tähistab vahemaad ketta keskpunktist. Väärtuse saab määrata eraldi liuguriga. </para>
</simplesect>
<simplesect id="qpainter-paintsettings">
<title
>Muud seadistused</title>
<para
>Tavaliselt asendavad joonistusseadmel joonistades joonistatavad pikslid seal varasemad pikslid. See tähendab, et kui joonistad teatud piirkonna punasega ning hiljem joonistad sama piirkonna sinisega, jääb nähtavaks ainult sinine. Qt graafikamudel ei toeta läbipaistvust, s.t. joonistatud esiplaani kokkusulamist taustaga. Siiski võib üsna hõlpsasti kombineerida tausta ja esiplaani tõeoperaatorite abil. Meetod QPainter::setRasterOp() määrab kasutatavad operaatorid, mis on pärit nimekirjast <ulink url="kdeapi:qt/Qt#RasterOp-enum"
>RasterOp</ulink
>. </para>
<para
>Vaikeväärtus on CopyROP, mis ignoreerib tausta. Teine levinud valik on XorROP. Kui joonistad selle operaatoriga musta joone värvilisele kujutisele, inverteeritakse kaetud ala. Seda efekti on näiteks kasutatud mitmetes pilditöötlusrakendustes pildiosade valimisel niinimetatud "marssivaid sipelgaid" kujutava valikukasti tekitamisel. </para>
</simplesect>
<simplesect id="qpainter-primitives">
<title
>Graafikaprimitiivide joonistamine</title>
<para
>Järgnevalt toome ära QPainteri toetatud elementaarsete graafikaelementide loendi. Enamik neist on olemas mitmes versioonis, mis võivad kasutada erineval hulgal argumente. Näiteks ristkülikuid puudutavad meetodid kasutavad tavaliselt argumendina <ulink url="kdeapi:qt/QRect"
>QRect</ulink
> nelja täisarvu. </para>
<itemizedlist>
<listitem>
<para
>Ühe punkti joonistamine - drawPoint().</para>
</listitem>
<listitem>
<para
>Sirgjoonte joonistamine - drawLine(), drawLineSegments() ja drawPolyLine().</para>
</listitem>
<listitem>
<para
>Ristkülikute joonistamine ja täitmine - drawRect(), drawRoundRect(), fillRect() ja eraseRect().</para>
</listitem>
<listitem>
<para
>Ringjoonte, ellipsite ja nende osade joonistamine ja täitmine - drawEllipse(), drawArc(), drawPie ja drawChord().</para>
</listitem>
<listitem>
<para
>Tavaliste polügoonide joonistamine ja täitmine - drawPolygon().</para>
>Qt pakub piltide esitamiseks kaht väga erinevat klassi. </para>
<para
><ulink url="kdeapi:qt/QPixmap"
>QPixmap</ulink
> vastab otseselt X11 pikselrasterobjektidele. Pikselrastrid on serveripoolsed objektid, mis moodsate graafikakaartide korral võivad olla isegi vahetult kaardimällu salvestatud. See muudab pikselrastrite edastamise ekraanile <emphasis
>äärmiselt</emphasis
> tõhusaks ja kiireks. Pikselrastrid toimivad ka vidinate vastena ekraanil - QPixmap on klassi QPaintDevice alamklass, nii et sellega on võimalik kasutada ka QPainterit. Moodsad graafikakaardid üldiselt kiirendavad elementaarseid joonistusoperatsioone. Seepärast on üpris tavaline kasutada pikselrastreid topeltpuhverduseks. See tähendab, et vidina vahetu joonistamise asemel joonistad ajutise pikselrasterobjekti ja kasutad selle edastamiseks vidinale funktsiooni <ulink url="kdeapi:qt/QPaintDevice#bitBlt-1"
>bitBlt</ulink
>. Keerulisemate asjade puhul aitab see vältida vilkumist. </para>
<para
>Seevastu <ulink url="kdeapi:qt/QImage"
>QImage</ulink
> objektid asuvad kliendi poolel. Nende põhiülesanne on pakkuda vahetut juurdepääsu pildi pikslitele. Nii saab neid kasutada pilditöötluseks ning sellisteks asjadeks nagu laadimine või kettale salvestamine (QPixmapi meetod load() kasutab vaheastmena QImage'it). Teisalt on pildi joonistamine vidinale üsna mahukas operatsioon, sest sellega kaasneb edastamine X'i serverisse, mis võib võtta omajagu aega, eriti kui tegemist on suurte piltidega või kaugserveritega. Sõltuvalt värvisügavusest võib teisendus QImage -> QPixmap nõuda ka pseudotoonimist. </para>
</simplesect>
<simplesect id="qpainter-drawingtext">
<title
>Teksti joonistamine</title>
<para
>Teksti saab esitada meetodi QPainter::drawText() mõne variandiga. Need joonistavad QStringi kas määratud punktis või määratud ristkülikus, kasutades fonti, mille määrab QPainter::setFont(). Kasutada saab ka parameetrit, mis võtab mõne lipu ORed kombinatsiooni nimekirjadest <ulink url="kdeapi:qt/Qt#AlignmentFlags-enum"
>Qt::AlignmentFlags</ulink
> ja <ulink url="kdeapi:qt/Qt#TextFlags-enum"
>Qt::TextFlags</ulink
> </para>
<para
>Alates versioonist 3.0 tegeleb Qt täielikult teksti esitamisega ka paremalt vasakule kirjutatavate keelte puhul. </para>
<para
>Täiustatum viis teksti esitamiseks on klass <ulink url="kdeapi:qt/QSimpleRichText"
>QSimpleRichText</ulink
>. Selle klassi objekte võib konstrueerida tekstiosaga HTML-siltide kogumit kasutades, mis pakub üpris palju võimalusi, isegi tabeleid. Tekstistiili saab kohandada <ulink url="kdeapi/qt/QStyleSheet"
>QStyleSheet</ulink
> abil (sealt leiab ka siltide dokumentatsiooni). Kui rikkaliku teksti vormingu objekt on konstrueeritud, saab seda renderdada vidinale või muule joonistamisseadmele meetodiga QSimpleRichText::draw(). </para>
</simplesect>
</sect1>
<sect1 id="graphics-qcanvas">
<title
>Struktureeritud graafika klassi QCanvas abil</title>
<para
>QPainter pakub võimsa pildiloomemudeli vidinatele ja pikselrastritele joonistamiseks. Kuid vahel võib seda olla üsna tülikas kasutada. Alati, kui vidin saab joonistamissündmuse, tuleb tal ette võtta QPaintEvent::region() või QPaintEvent::rect() analüüsimine, mis tuleb ümber joonistada. Siis tuleb seadistada QPainter ja joonistada kõik objektid, mis kattuvad antud piirkonnaga. Näiteks olgu vektorgraafikarakendus, mis võimaldab lohistada polügoone, ringjooni ja nende gruppe. Iga kord, kui selliseid objekte kas või veidi liigutatakse, käivitab vidina hiiresündmuse käitleja joonistamissündmuse nii kogu sellele alale, kus need objektid varem asusid, kui ka alale, kuhu need liigutati. Vajalike ümberjoonistuste leidmine ning nende efektiivne sooritamine võib olla päris keeruline, samuti võib see sattuda konflikti rakenduse lähtekoodi objektorienteeritud struktuuriga. </para>
<para
>Alternatiivina sisaldab Qt klassi <ulink url="kdeapi:qt/QCanvas"
>QCanvas</ulink
>, kuhu saab panna graafilised objektid, näiteks polügoonid, teksti, pikselrastrid. Pakkuda saab ka lisaelemente alamklassiga <ulink url="kdeapi:qt/QCanvasItem"
>QCanvasItem</ulink
> või mõne veel spetsialiseerituma alamklassiga. Lõuendit võib ekraanil näidata üks või enam vidinat klassist <ulink url="kdeapi:qt/QCanvas"
>QCanvasView</ulink
>, mis tuleb kasutaja tegevuse käitlemiseks alamklassiks muuta. Qt hoolitseb kõigi vaate objektide ümberjoonistamise ees, olgu selle põhjuseks vidina nähtavaleilmumine, uute objektide loomine või muutmine või mingi muu põhjus. Topeltpuhverduse kasutamine lubab seda teha tõhusal ja vilkumist vältival viisil. </para>
<para
>Lõuendi elemendid võivad üksteisega kattuda. Sellisel juhul sõltub see, milline on näha, z-astmest, mille määrab QCanvasItem::setZ(). Elemente saab muuta nähtavaks või nähtamatuks. Samuti võib lasta tausta joonistada kõigi teiste elementide "taga". Hiiresündmuste seostamiseks objektidega lõuendil on meetod QCanvas::collisions(), mis tagastab antud punktis kattuvate elementide nimekirja. Toome siin ära ühe lõuendivaate: </para>
<mediaobject>
<imageobject
><imagedata fileref="canvas.png"/></imageobject>
</mediaobject>
<para
>Taustal joonistatakse võrku. Lisaks on siin element QCanvasText ning lilla QCanvasPolygon. Liblikas on QCanvasPixmap. Sellel on läbipaistvad alad, mis lubavad näha selle all olevaid elemente. </para>
<para
>QCanvas kasutamise juhendi näiteks vaimustavate mängude loomiseks leiab internetist <ulink url="http://zez.org/article/articleview/2/1/"
>sellel aadressil</ulink
>. </para>
</sect1>
<sect1 id="graphics-qglwidget">
<title
>3D graafika OpenGL abil</title>
<simplesect id="qglwidget-lowlevel">
<title
>Süvataseme liides</title>
<para
>Tänapäeval on 3D graafika renderdamise de facto standard <ulink url="http://www.opengl.org"
>OpenGL</ulink
>. 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 <emphasis
>GL konteksti</emphasis
> vahendusel ega suhtle mingil määral keskkonna tööriistakomplektiga. </para>
<para
>Qt pakub vidinat <ulink url="kdeapi:qt/QGLWidget"
>QGLWidget</ulink
>, mis kapseldab akna sellega seotud GL kontekstiga. Põhimõtteliselt tähendab see selle muutmist alamklassiks ja mõningate meetodite taasteostamist. </para>
<itemizedlist>
<listitem
><para
>Selle asemel, et taasteostada paintEvent() ja kasutada QPainter'it vidina sisu joonistamiseks, tühistatakse paintGL() ja kasutatakse stseeni renderdamiseks GL käske. QGLWidget hoolitseb GL konteksti muutmise eest aktiivseks enne seda, kui paintGL() välja kutsutakse, ning hiljem tühjendab selle. </para
></listitem>
<listitem
><para
>Enne seda, kui kutsutakse esimest korda välja resizeGL() või paintGL(), kutsutakse korraks välja virtuaalmeetod initializeGL(). Seda saab kasutada objektide esitamise nimekirjade konstrueerimiseks ja mis tahes vajaolevaks initsialiseerimiseks. </para
></listitem>
<listitem
><para
>Selle asemel, et resizeEvent() taasteostada, tühistatakse resizeGL(). Seda saab kasutada vaateava sobivaks määramiseks. </para
></listitem>
<listitem
><para
>Selle asemel, et kutsuda välja update(), kui stseeni olek on muutunud - kui näiteks animeerid selle taimeriga - , tuleks välja kutsuda updateGL(). See käivitab ümberjoonistamise. </para
></listitem>
</itemizedlist>
<para
>Ü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. </para>
<mediaobject>
<imageobject
><imagedata fileref="opengl.png"/></imageobject>
</mediaobject>
<para
>Qt sisaldab mõningaid näiteid QGLWidgeti kasutamise kohta oma <literal
>demo</literal
>s. Õppevahendid leiab <ulink url="http://www.libsdl.org/opengl/intro.html"
>siit</ulink
>, rohkem infot ja OpenGL selgitusi aga <ulink url="http://www.opengl.org"
>OpenGL koduleheküljelt</ulink
>. </para>
</simplesect>
<simplesect id="qglwidget-highlevel">
<title
>Kõrgtaseme liidesed</title>
<para
>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 <ulink url="http://www.coin3d.org"
>Coin</ulink
>, mida on täiendatud seda Qt-ga siduva tööriistakomplektiga SoQt. </para>
<para
>Open Inventori aluseks on niinimetatud <emphasis
>stseen</emphasis
>. Stseeni võib hoida kõvakettal salvestatuna spetsiaalsesse vormingusse, mis on lähedane <ulink url="http://www.vrml.org"
>VRML</ulink
>-vorminguga. Stseen koosneb objektidest, mida nimetatakse <emphasis
>sõlmedeks</emphasis
>. 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. </para>
<para
>Open Inventori sissejuhatuse leiab <ulink url="http://www.motifzone.com/tmd/articles/OpenInventor/OpenInventor.html"
>siit</ulink
> (üldiselt võib seda artiklit lugedes mõttes SoXt asemele panna SoQt). </para>
</simplesect>
</sect1>
</chapter>
<chapter id="userinterface">
<title
>Kasutajaliides</title>
<sect1 id="userinterface-actionpattern">
<title
>Toimingumuster</title>
<para
></para>
</sect1>
<sect1 id="userinterface-xmlgui">
<title
>Menüüde ja tööriistaribade defineerimine XML-is</title>
<simplesect id="xmlgui-intro">
<title
>Sissejuhatus</title>
<para
><link linkend="userinterface-actionpattern"
>Toimingumuster</link
> 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. </para>
<para
>Selle probleemi lahendab klasside kogum nimetusega <literal
>XMLGUI</literal
>. 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 <menuchoice
><guimenu
>Fail</guimenu
><guimenuitem
>Ava</guimenuitem
></menuchoice
> või <menuchoice
><guimenu
>Abi</guimenu
><guimenuitem
>Info</guimenuitem
></menuchoice
>) 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. </para>
>. 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 <literal
>ui.rc</literal
> versiooninumbrit, kontrollib KDE, et faili kohandatud versioonid eemaldataks ja kasutataks just uut faili. </para>
<para
>Järgmine rida <literal
><MenuBar></literal
> sisaldab menüüriba deklaratsiooni. Lisada võib ka suvalise arvu <literal
><ToolBar></literal
> 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 <application
>KView</application
> alammenüü "Image" (eestindatult "Pilt"), mis tuleb deklareerida nii: </para>
> faili, mida siis tõlkijad saavad tarvitada rakenduse emakeelde panekul. Pane tähele, et kiirklahvi tähis "&" tuleb kirjutada XML-i reeglitele vastavalt "&amp;". </para>
<para
>Vaatame uuesti meie näidet. <application
>KView</application
> menüüs <guimenu
>Vaade</guimenu
> on mitu kohandamistoimingut: <literal
>zoom50</literal
>, <literal
>zoom100</literal
>, <literal
>zoom200</literal
>, <literal
>zoomMaxpect</literal
> ja <literal
>fullscreen</literal
>, mis on deklareeritud elemendiga <literal
><Action></literal
>. Pildil nähtavale eraldusjoonele vastab element <literal
><Separator></literal
>. </para>
<para
>Pane tähele, et mõnel elemendil ei ole XML-failis vastet. Need on niinimetatud <emphasis
>. 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 tdelibs lähtekoodi failis <filename
>Märkame kohe, et siin on märksa rohkem atribuute kui menüüribal, sealhulgas: </para>
<itemizedlist>
<listitem
><para
><literal
>fullWidth</literal
>: ütleb XMLGUI-le, et tööriistariba laius on võrdne tipptaseme akna laiusega. Kui see on määratud "vääraks" (false), võtab tööriistariba ainult nii palju ruumi, kui talle parajasti vaja läheb ning samasse ritta võivad mahtuda ka muud tööriistaribad. </para
></listitem>
<listitem
><para
><literal
>newline</literal
>: on seotud eelmise valikuga. Kui see on "tõene" (true), alustab tööriistariba uut rida, vastasel juhul võib see asetseda samas reas eelmise tööriistaribaga. </para
></listitem>
<listitem
><para
><literal
>noEdit</literal
>: tavaliselt võib kasutaja tööriistaribasid oma käe järgi kohandada, näiteks <application
>Konqueror</application
>i puhul menüükäsuga <menuchoice
><guimenu
>Seadistused</guimenu
><guimenuitem
>Tööriistaribade seadistamine</guimenuitem
></menuchoice
>. Kui see on nüüd "tõene" (true), siis ei saa tööriistariba muuta. See on oluline sellistele tööriistaribadele, mis täidetakse käivitamise ajal, näiteks <application
>Konqueror</application
>i järjehoidjariba. </para
></listitem>
<listitem
><para
><literal
>iconText</literal
>: käsib XMLGUI-l näidata toimingu teksti ikooni kõrval. Tavaliselt näidatakse teksti ainult kohtspikrina, kui jätta hiirekursor mõneks hetkeks ikooni kohale seisma. Võimalikud väärtused on "icononly" (näidatakse ainult ikooni), "textonly" (näidatakse ainult teksti), "icontextright" (teksti näidatakse ikoonist paremal pool) ja "icontextbottom" (teksti näidatakse ikooni all). </para
></listitem>
<listitem
><para
><literal
>hidden</literal
>: kui see on "tõene" (true), ei ole tööriistariba algselt nähtaval ja selle aktiveerimiseks tuleb kasutada mingit menüüelementi. </para
></listitem>
<listitem
><para
><literal
>position</literal
>: selle atribuudi vaikeväärtus on "top", mis tähendab,. et tööriistariba asub menüüriba all. Paljude tööriistadega rakenduste korral, näiteks graafikarakendused, võib olla mõttekas määrata selle asemel asukohaks "left" (vasakul), "right" (paremal) või "bottom" (all). </para
></listitem>
</itemizedlist>
</simplesect>
<simplesect id="xmlgui-dynamical">
<title
>Dünaamilised menüüd</title>
<para
>On ilmne, et XML saab sisaldada ainult kasutajaliidese staatilist kirjeldust. Sageli esineb aga menüüsid, mis käivitamisel muutuvad. Näiteks <application
>Konqueror</application
>i menüü <guimenu
>Asukoht</guimenu
> sisaldab rea elemente <guimenuitem
>Ava kasutades XXX</guimenuitem
>, 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 <emphasis
>toimingunimekirjadega</emphasis
>. XML-failis deklareeritakse toimingunimekiri ühe elemendina, kuid see sisaldab mitu toimingut, mis lisatakse menüüsse käivitamisel. Meie toodud näide teostatakse <application
>Konqueror</application
>i XML-failis järgmise deklaratsiooniga: </para>
<programlisting
><Menu name="file">
<text>&amp;Location</text>
...
<ActionList name="openwith">
...
</Menu>
</programlisting>
<para
>Näidatavate toimingute lisamiseks kasutatakse siin funktsiooni <function
>KXMLGUIClient::plugActionList()</function
>, eemaldamiseks aga funktsiooni <function
>KXMLGuiClient::unplugActionList()</function
>. Uuendamisrutiin näeb välja selline: </para>
<programlisting
>void MainWindow::updateOpenWithActions()
{
unplugActionList("openwith");
openWithActions.clear();
for ( /* iterate over the relevant services */ ) {
>Pane tähele, et erinevalt staatilistest toimingutest <emphasis
>ei ole</emphasis
> need loodud eellasest toimingukogu baasil ja sestab tuleb sul endal nende kustutamise eest hoolt kanda. Lihtsaim viis selleks on kasutada - nagu ülaltoodud näites - <literal
>openWithActions.setAutoDelete(true)</literal
>. </para>
</simplesect>
<simplesect id="xmlgui-contextmenus">
<title
>Kontekstimenüüd</title>
<para
>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 <function
>createGUI()</function
> 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): </para>
> püüab leida XML-failis antud nimega konteinerit. Seega võib definitsioon välja näha näiteks nii: </para>
<programlisting
>...
<Menu name="context_popup">
<Action name="file_add"/>
<Action name="file_remove"/>
</Menu>
...
</programlisting>
</simplesect>
</sect1>
<sect1 id="help">
<title
>Abivõimaluste pakkumine</title>
<para
>Rakenduse muutmine hõlpsasti kasutatavaks ja arusaadavaks tähendab ka mitmesuguste kasutajat abistavate võimaluste pakkumist. Sellel on mitu, omavahel osaliselt vastuolulist eesmärki: ühelt poolt peab see andma vastuse kasutaja küsimusele "Kuidas ma seda teha saan?", teiselt poolt aga aitama kasutajal rakendust tundma õppida ja avastada võimalusi, mille olemasolugi ta varem ei teadnud. Seepärast on oluline tähele panna, et mõlema sihi saavutamiseks on äärmiselt mõttekas pakkuda abi korraga mitmel tasandil: </para>
<itemizedlist>
<listitem
><para
>Kohtspikrid on pisikesed aknakesed, mis ilmuvad kasutajaliidese elementide juurde, kui jätta hiirekursor mõneks hetkeks elemendil peatuma. Need on eriti tähtsad tööriistaribade puhul, kus ainuüksi ikoon ei pruugi alati piisavalt selgelt vihjata, milleks on mingi nupp mõeldud. </para
></listitem>
<listitem
><para
>Võimalus "Mis see on?" sisaldab tavaliselt pikemat ja põhjalikumat seletust vidina või menüükirje kohta. Samas on selle kasutamine veidi keerulisem. Näiteks dialoogides saab seda esile kutsuda kahel viisil: vajutades <keycombo
><keycap
>Shift</keycap
><keycap
>F1</keycap
></keycombo
> või klõpsates küsimärgile tiitliribal (kas küsimärk seal ka asub, sõltub küll tugevasti kasutatavast aknahaldurist). Hiirekursor muutub siis küsimärgiga nooleks ning mingile elemendile klõpsates ilmub väike abiaken. Menüüelementide korral saab võimaluse "Mis see on?" tavaliselt aktiveerida klõpsuga tööriistaribal asuvale noole ja küsimärgiga nupule. </para
></listitem>
<listitem
><para
>Selle võimaluse miinuseks on aga asjaolu, et kasutajal pole võimalik ette teada, kas teda huvitava vidina kohta on selline abi olemas või mitte. Kui nüüd küsimärginupule klõpsata ja elemendi kohta ikkagi mingit abi ei ole, võib see tasapisi tekitada tugevat rahulolematust. </para>
<para
>Tänu Qt ja KDE võimalustele saab aga "Mis see on?`" abiaken sisaldada <ulink url="kdeapi:qt/QStyleSheet"
>vormindatud teksti</ulink
>, see tähendab, võib pakkuda erinevaid fonte, rasvast ja kaldkirja või isegi pilte ja tabeleid. </para>
>Lõpuks peaks igal rakendusel olema ka oma käsiraamat. Tavaliselt näitab seda <application
>KDE abikeskus</application
>, mille saab avada menüüst <guimenu
>Abi</guimenu
>. See tähendab, et avatakse täiesti omaette rakendus, mis viib kasutaja fookuse rakenduselt eemale. Seetõttu tuleks arvestada, et käsiraamatu järele tekib vajadus ennekõike siis, kui kohtspikrid või "Mis see on?" ei suuda kasutajat abistada. Muidugi on käsiraamatu eelis selles, et see ei piirdu kasutajaliidese üksiku ja isoleeritud aspekti seletamisega, vaid tutvustab rakendust tervikuna. KDE käsiraamatud pannakse kirja <ulink url="http://i18n.kde.org"
>DocBook</ulink
> märkekeeles. </para
></listitem>
</itemizedlist>
<para
>Programmeerija vaatevinklist pakub Qt abi pakkumiseks välja hõlpsasti kasutatava API. Kohtspikri lisamiseks vidinale tarvita klassi <ulink url="kdeapi:qt/QToolTip"
>QToolTip</ulink
>. </para>
<programlisting
>QToolTip::add(w, i18n("This widget does something."))
</programlisting>
<para
>Kui menüü- ja tööriistaribad luua <ulink url="actionpattern.html"
>See avab esimese, sisukorraga lehekülje. Kui soovid lasta näidata ainult kindlat käsiraamatu osa, tuleb funktsioonile <function
>invokeHelp()</function
> anda täiendav argument, mis määrab ankru, kuhu hüpata. </para>
</sect1>
</chapter>
<chapter id="components">
<title
>Komponendid ja teenused</title>
<sect1 id="components-services">
<title
>KDE teenused</title>
<simplesect id="services-whatarekdeservices">
<title
>Mis on KDE teenused?</title>
<para
>KDE moodularhitektuuris on mõistel <emphasis
>teenus</emphasis
> keskne koht. See mõiste ei ole jäigalt seotud mingi konkreetse tehnilise teostusega - teenus võib olla plugin jagatud teegi näol või siis programm, mida juhitakse <ulink url="dcop.html"
>DCOP</ulink
> vahendusel. Oma <emphasis
>teenusetüübiga</emphasis
> lubab teenus teostada teatud konkreetse API või võimaluse. C++ tähenduses võib teenusetüüpi pidada abstraktseks klassiks ja teenust ennast selle liidese teostuseks. </para>
<para
>Sellise eraldamise eelised on ilmsed: teenusetüüpi kasutaval rakendusel pole vajadust teada, kuidas see teostatakse, ta kasutab lihtsalt antud teenusetüübiga seotud API-t. Sel moel võib kasutatavat teenust muuta ilma rakendust kuidagi mõjutamata. Samuti on kasutajal võimalik ise määrata, milliseid teenuseid ta teatud võimaluste jaoks eelistab. </para>
<para
>Mõned näited: </para>
<itemizedlist>
<listitem
><para
><application
>Konqueror</application
>is kasutatav HTML-i renderdusmootor on põimitav komponent, mis teostab teenusetüübid <literal
>KParts/ReadOnlyPart</literal
> ja <literal
>Browser/View</literal
>. </para
></listitem>
<listitem
><para
><application
>KDevelop</application
>is on enamik võimalusi esitatud pluginatena teenusetüübiga <literal
>KDevelop/Part</literal
>. Käivitamisel laetakse kõik selle tüübiga teenused, mis võimaldab IDE-d väga paindlikult laiendada. </para
></listitem>
<listitem
><para
>Ikoonivaates näitab <application
>Konqueror</application
> (kui see on lubatud) piltide, HTML-lehekülgede, PDF- ja tekstifailide pisipilte. Ka seda võimalust on võimalik laiendada. Kui soovid lasta näidata oma teatud MIME tüübiga andmefailide eelvaatluse pilte, tuleb teostada teenus tüübiga <classname
>ThumbCreator</classname
>. </para
></listitem>
</itemizedlist>
<para
>On ilmne, et teenust ei iseloomusta ainult teenusetüüp, mida ta teostab, vaid ka mõningad <emphasis
>omadused</emphasis
>. Näiteks ThumbCreator ei teosta mitte ainult C++ klassi tüübiga <classname
>ThumbCreator</classname
>, vaid sisaldab ka MIME tüüpide nimekirja, mille puhul eelvaatlust pakkuda. KDevelopi komponentidel on omaduseks programmeerimiskeel, mida nad toetavad. Kui rakendus soovib kasutada teatud teenusetüüpi, võib ta ühtlasi anda teenuse omaduste piirangute nimekirja. Toodud näite korral küsib KDevelop Java projekti tarbeks pluginaid laadides ainult selliseid pluginaid, mille omaduseks on Java programmeerimiskeel. Sellisteks puhkudeks pakub KDE võimsat ja võimalusterohke päringukeelega CORBA-sarnast börsi (<emphasis
>trader</emphasis
>). </para>
</simplesect>
<simplesect id="services-definingservicetypes">
<title
>Teenusetüüpide defineerimine</title>
<para
>Uusi teenusetüüpe lisatakse nende kirjeldust kataloogi <filename
>Lisaks tavapärastele kirjetele on toodud näites näha, kuidas deklareerida teenuse omadusi. Igale omaduse definitsioonile vastab konfiguratsioonifailis grupp <literal
>[PropertyDef::name]</literal
>. Selles grupis deklareerib kirje <literal
>Type</literal
> omaduse tüübi. Võimalikud tüübid on kirjas klassis <ulink url="kdeapi:qt/QVariant"
cout << "Service does not implement the right factory" << endl;
}
</programlisting>
</simplesect>
<simplesect id="services-definingdcopservices">
<title
>DCOP-teenuste defineerimine</title>
<para
>DCOP-teenus on tavaliselt teostatud programmina, mis käivitub vajaduse korral. Sellisel juhul loob ta silmuse ja jälgib DCOP-ühendusi. Programm võib olla interaktiivne, kuid see võib ka täielikult või osaliselt tegutseda taustal deemonina, ilma et kasutaja seda otseselt märkaks. Sellise deemoni näide on <literal
>, mis teostab kasutaja suhtlust, näiteks TDEIO teegi edenemisdialoogi. Antud kontekstis on tsentraliseeritud deemoni eeliseks näiteks see, et mitme erineva faili tõmbamise edenemist saab näidata ühes aknas isegi juhul, kui tõmbamine käivitati erinevatest rakendustest. </para>
>DCOP-teenus defineeritakse teisiti kui jagatud teegi teenus. Loomulikult ei määra see teeki, vaid käivitatava faili. Samuti ei määra DCOP-teenused rida ServiceType, sest tavaliselt käivitatakse nad nimepidi. Lisaomadustena on selles kaks rida: </para>
<para
><literal
>X-DCOP-ServiceType</literal
> määrab viisi, kuidas teenus käivitatakse. Väärtus <literal
> sedastab, et teenust saab käivitada vaid ühekordsena. See tähendab, et kui proovid teenust käivitada (nt. <ulink url="kdeapi:tdecore/TDEApplication.html#startServiceByName"
> vahendusel), uurib KDE, kas see on juba registreeritud DCOP-iga ja kasutab töötavat teenust. Kui see ei ole veel registreeritud, käivitab KDE selle ja ootab registreerimist. Nii saab teenusele kohe saata DCOP-väljakutseid. Sellisel juhul peab teenus olema teostatud kui <ulink url="kdeapi:tdecore/KUniqueApplication.html"
> korral, et korraga võib töötada mitu teenuse eksemplari, nii et iga katse teenust käivitada loob uue protsessi. Viimaks võib kasutada ka väärtust <literal
>None</literal
>. Sellisel juhul ei oodata teenuse käivitamisel registreerimist DCOP-iga. </para>
> peaks üldjuhul olema määratud vääraks (false). Kui see nii ei ole, näitab tegumiriba programmi käivitumisel käivitusteadet või, kui kasutaja on nii määranud, muutub kursori kuju. </para>
>Pane tähele, et siin toodud DCOP-väljakutse näide kasutab vahetult argumente. Enamasti on mõttekas tarvitada selle asemel dcopidl2cpp genereeritud väljundit, mis on märksa lihtsam ja veakindlam. </para>
<para
>Toodud näiteks käivitatakse teenus "nimepidi", s.t. esimene <function
>Kõik väljakutsed kasutavad teise argumendina URL-ide nimekirja, mis antakse teenusele käsureal. Kolmas argument on viit klassile <classname
>QString</classname
>. Kui teenuse käivitamine ebaõnnestub, annab see argument tulemuseks tõlgitud veateate. </para>
</simplesect>
</sect1>
<sect1 id="components-mime">
<title
>MIME tüübid</title>
<simplesect id="mime-whataremimetypes">
<title
>Mis on MIME tüübid?</title>
<para
>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: </para>
<itemizedlist>
<listitem
><para
><application
>Konqueror</application
>i ikoonivaates näitavad faile ikoonid. Iga MIME tüübiga on seotud teatud ikoon, mida siin näidataksegi. </para
></listitem>
<listitem
><para
>Klõpsates <application
>Konqueror</application
>is faili ikoonile või nimele näidatakse faili põimitud näitajas või avatakse antud failitüübiga seotud rakendus. </para
></listitem>
<listitem
><para
>Mingeid andmeid ühest rakendusest teise (või ka ühe rakenduse sees) lohistades võib sihtkoht aktsepteerida ainult teatud andmetüüpe. Samuti käsitletakse pildiandmeid tekstiandmetest erinevalt. </para
></listitem>
<listitem
><para
>Lõikepuhvri andmetel on samuti MIME tüüp. Tavapäraselt suudavad X'i programmid käsitleda ainult pilte või teksti, kuid Qt abil ei ole andmetüübid piiratud. </para
></listitem>
</itemizedlist>
<para
>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. </para>
<para
>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 <filename
>foo.jpg</filename
> 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 <filename
>. 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 <literal
>.pl</literal
>, mis osutab tüübile <literal
>"text/x-perl"</literal
>. Samas on serveri edastatud fail hoopis selle skripti väljund, milleks on enamasti HTML. Sellisel juhul tagastab <function
>KMimeType::findByURL()</function
> MIME tüübi <literal
>"application/octet-stream"</literal
> (kasutatav <function
>KMimeType::defaultMimeType()</function
> vahendusel), mis osutab võimetusele tüüpi tuvastada. </para>
<programlisting
>KMimeType::Ptr type = KMimeType::findByURL("/home/bernd/foobar.jpg");
if (type->name() == KMimeType::defaultMimeType())
cout << "Could not find out type" << endl;
>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 <ulink url="kdeapi:tdeio/KMimeMagic.html"
>See käivitab TDEIO 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 <function
>MIME tüübi seostamine rakenduse või teenusega</title>
<para
>Rakenduse paigaldamisel paigaldab see oma <literal
>.desktop</literal
>-faili, mis sisaldab loetelu MIME tüüpidest, mida rakendus suudab avada. Ka komponendid, näiteks KParts, teatavad samasugust infot oma <literal
>.desktop</literal
>-failide vahendusel. Nii on enamasti olemas mitu programmi ja komponenti, mis suudavad antud MIME tüüpi käsitleda. Nende nimekirja võib leida klassist <classname
>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: </para>
>URL-i käivitamine. See uurib URL-i tüüpi ja käivitab kasutaja antud tüübi korral eelistatud programmi. </para>
<programlisting
>KURL url("http://dot.kde.org");
new KRun(url);
</programlisting>
</simplesect>
</sect1>
<sect1 id="nettransparency">
<title
>Võrguläbipaistvus</title>
<simplesect id="nettransparency-intro">
<title
>Sissejuhatus</title>
<para
>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 <emphasis
>võrguläbipaistvuseks</emphasis
>. </para>
<para
>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 <emphasis
>asünkroonsus</emphasis
>: 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. </para>
>. 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. </para>
<para
>Töötamiseks taustal on mõeldud konkreetseid ülesandeid täitvad <emphasis
>IO moodulid</emphasis
>. 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. </para>
<para
>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 </para>
>Enamasti luuakse tööd TDEIO 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 <literal
>Leiab teatud info faili kohta, näiteks suurus, muutmise aeg ja õigused. Info teeb pärast töö lõpetamist teatavaks TDEIO::StatJob::statResult(). </para
>Nii töö TDEIO::stat() kui ka töö TDEIO::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). </para>
>UDS_ACCESS (täisarv) - faili kasutamise õigused, nagu need on salvestanud näiteks libc funktsioon stat() väljal st_mode. </para
></listitem>
<listitem
><para
>UDS_FILE_TYPE (täisarv) - faili tüüp, nagu selle on salvestanud näiteks stat() väljal st_mode. Seepärast saab selle väärtuse testimiseks kasutada tavalisi libc makrosid, näiteks S-ISDIR. Arvesta, et IO moodulite pakutud andmed vastavad sellele, mida sisaldab stat(), mitte aga lstat(), nii et näiteks nimeviida korral on failitüüp selle faili tüüp, millele viit osutab, mitte aga viit ise. </para
></listitem>
<listitem
><para
>UDS_LINK_DEST (string) - nimeviida puhul viidatud faili nimi. </para
></listitem>
<listitem
><para
>UDS_MODIFICATION_TIME (täisarv) - aeg (nagu tüübis time_t), millal faili viimati muudeti, nagu selle on salvestanud näiteks stat() väljal st_mtime. </para
></listitem>
<listitem
><para
>UDS_ACCESS_TIME (täisarv) - aeg, millal faili viimati kasutati, nagu selle on salvestanud näiteks stat() väljal st_atime. </para
></listitem>
<listitem
><para
>UDS_CREATION_TIME (täisarv) - faili loomise aeg, nagu selle on salvestanud näiteks stat() väljal st_ctime. </para
></listitem>
<listitem
><para
>UDS_URL (string) - faili URL, kui see ei ole lihtsalt kataloogi URL-i ja failinime ühend. </para
></listitem>
<listitem
><para
>UDS_MIME_TYPE (string) - faili MIME tüüp </para
></listitem>
<listitem
><para
>UDS_GUESSED_MIME_TYPE (string) - faili MIME tüüp, nagu seda arvab moodul. Erinevus eelmise tüübiga seisneb selles, et siinpakutut ei tohiks võtta usaldusväärsena (sest selle määramine usaldusväärsel meetodil on liiga kulukas). Näiteks klass KRun kontrollib vahetult MIME tüüpi, kui tal ei ole usaldusväärset infot. </para
></listitem>
</itemizedlist>
<para
>Kuigi failiinfo salvestamise viis klassis <classname
>UDSEntry</classname
> 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 <literal
>m_uds</literal
> on ikka <literal
>UDS_MIME_TYPE</literal
>. Õnneks on olemas API, mida on palju lihtsam kasutada: klass <classname
>Sageli on TDEIO 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 TDEIO::NetAccess-is. Näiteks faili kopeerimiseks kasuta: </para>
>See funktsioon tagastab pärast terve kopeerimisprotsessi lõpetamist. Siiski pakub see meetod edenemisdialoogi ja kontrollib, et rakendus töötleb ümberjoonistamissündmusi. </para>
<para
>Eriti huvitav funktsioonide kombinatsioon o <function
>download()</function
> koos funktsiooniga <function
>removeTempFile()</function
>. Esimene tõmbab määratud URL-iga faili ja salvestab selle unikaalse nimega ajutise failina. Nimi salvestatakse teise argumendina. <emphasis
>Kui</emphasis
> tegemist on kohaliku URL-iga, faili alla ei laeta ja teiseks argumendiks määratakse kohaliku faili nimi. Funktsioon <function
>removeTempFile()</function
> 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: </para>
>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: </para>
>TDEIO 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. </para>
>Tagaplaanil on aga kõik palju keerukam. Tööd luues seatakse see järjekorda. Kui rakendus läheb tagasi sündmusesilmusesse, eraldab TDEIO 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. </para>
>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 TDEIO 20 mooduliprotsessi. Sellist moodulite omistamist töödele nimetatakse <emphasis
> 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. </para>
<para
>Seepärast on olemas ka teine võimalus: töid saab <emphasis
>ajastada</emphasis
>. 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: </para>
>. 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 TDEIO::Scheduler: </para>
>Moodul on mõtet lahti ühendada alles pärast seda, kui kõik sellele omistatud tööd on kindlasti lõpetatud. </para>
</simplesect>
<simplesect id="nettransparency-definingslaves">
<title
>IO mooduli defineerimine</title>
<para
>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: </para>
>, 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. </para>
<para
>Praegu ei ole kasutusel read "input" ja "output". </para>
>-faili read määravad ära mooduli omadused. Üldiselt on võimalused, mida moodul peab teostama, palju lihtsamad kui võimalused, mida TDEIO 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. TDEIO ajastaja tagab, et korraga ei oleks aktiivsed liiga palju töid. Ka võib TDEIO näiteks faili kopeerimiseks protokolli korral, mis ei toeta vahetult kopeerimist (näiteks <literal
>), lugeda lähtefaili ja seejärel kirjutada andmed sihtfaili. Selleks peab <literal
>.protocol</literal
>-fail tegema teatavaks, milliseid toiminguid antud moodul toetab. </para>
<para
>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 <function
>kdemain()</function
>. See sooritab teatud initsialiseerimine ning läheb seejärel sündmusesilmusesse ja ootab rakenduse soove. Välja näeb see nii: </para>
<programlisting
>extern "C" { int kdemain(int argc, char **argv); }
> teatud virtuaalsetele funktsioonidele, mida mooduli teostus peab taasteostama. Toome siin ära võimalike toimingute ja neile vastavate virtuaalsete funktsioonide loendi: </para>
<variablelist>
<varlistentry
><term
>reading - loeb andmed URL-ilt</term>
<listitem
><para
>void get(const KURL &url)</para
></listitem
></varlistentry>
<varlistentry
><term
>writing - kirjutab andmed URL-ile ja loob faili, kui seda veel ei ole.</term>
<listitem
><para
>void put(const KURL &url, int õigused, bool overwrite, bool resume)</para
> inimestele mõistetava veateate loomisel. </para>
<para
>Võrguprotokollidele vastavate moodulite puhul võib huvi pakkuda meetodi <function
>SlaveBase::setHost()</function
> taasteostamine. See kutsutakse välja teatamaks mooduliprotsessile masinat ja porti ning sisselogimiseks vajalikku kasutajanime ja parooli. Üldiselt saab rakenduse saadetud metaandmete päringuks kasutada <function
>SlaveBase::metaData()</function
>. Teatud võtme metaandmete olemasolu kontrollimiseks on mõeldud <function
>SlaveBase::hasMetaData()</function
>. </para>
</simplesect>
<simplesect id="nettransparency-communication">
<title
>Tagasiside rakendusele</title>
<para
>Mooduli teostatud toimingute tulemusel saadud andmed tuleb mingil moel tagastada mooduliprotsessi kasutavale rakendusele: </para>
<itemizedlist>
<listitem
><para
><function
>get()</function
> saadab andmebloki. Seda teeb <function
>data()</function
>, mis võtab argumendiks <classname
>QByteArray</classname
>. Mõistagi ei pea kõiki andmeid korraga saatma. Näiteks suurt faili saates kutsu <function
>data()</function
> välja väiksemate andmeblokkidega, et rakendus suudaks neid töödelda. Kui edastus on lõpetatud, kutsu välja <function
>finished()</function
>. </para
></listitem>
<listitem
><para
><function
>listDir()</function
> edastab kataloogikirjete info. Selleks kutsu <function
>, millest tuleb veel juttu. Selliste andmete saatmiseks rakendustele kasuta <function
>statEntry()</function
>. </para
></listitem>
<listitem
><para
><function
>mimetype()</function
> kutsub välja <function
>mimeType()</function
>, andes argumendiks stringi. </para
></listitem>
<listitem
><para
><function
>get()</function
> ja <function
>copy()</function
> pakuvad edenemisinfot. Seda saavutatakse meetoditega <function
>totalSize()</function
>, <function
>processedSize()</function
> ja <function
>speed()</function
>. Kogusuurus ja töödeldud suurus antakse teada baitides, kiirus baitides sekundi kohta. </para
></listitem>
<listitem
><para
>Funktsiooniga <function
>setMetaData()</function
> saab saata metaandmete võtme-väärtuse paare. </para
></listitem>
</itemizedlist>
</simplesect>
<simplesect id="nettransparency-interacting">
<title
>Suhtlemine kasutajaga</title>
<para
>Mõnikord on moodulil vaja suhelda kasutajaga: infosõnumid, autentimisdialoogid või kinnituse küsimine faili ülekirjutamisel. </para>
<itemizedlist>
<listitem
><para
><function
>infoMessage()</function
> - informatsiooniline tagasiside, näiteks HTTP mooduli sõnum "Andmete tõmbamine aadressilt <masin>", mida sageli näidatakse rakenduse olekuribal. Rakenduse poolelt vastab sellele meetodile signaal <function
