<para>Mens Unix-systemer bliver mere og mere populære selv for nybegyndere som arbejder med computere, på grund af deres fordele i form af stabilitet og funktionalitet, bliver de fleste på en måde skuffede, fordi disse programmer ikke har konsistent udseende og hvert af dem opfører sig anderledes. Med KDE har udviklere en næsten perfekt måde at lave førsteklasses programmer for Unix-desktopsystemer, for at få en bredere brugergruppe kun på grund af kvaliteten som programmerne tilbyder. Derfor bliver KDE mere og mere populært som en basis for programkonstruktion, og udviklere vil drage fordel af mulighederne som systemet tilbyder. </para>
<para>For at bruge denne programmeringshåndbog på bedste måde, antager vi at du allerede kender til programmeringssproget C++. Hvis du ikke gør det, bør du gøre dig bekendt med det først. Information om C++ er tilgængelig via forskellige kilder, enten på skriftlig form i den lokale boghandel eller med vejledninger på internettet. Kendskab til konstruktion af grafiske brugergrænseflader kræves ikke, eftersom håndbogen forsøger at dække konstruktion af KDE-programmer, som også omfatter en introduktion til QT-værktøjskassen samt KDE-bibliotekerne og konstruktion af brugergrænseflader. Desuden bør du have gjort dig bekendt med &tdevelop;, ved at læse brugermanualen til &tdevelop;, som indeholder en beskrivende gennemgang af funktionerne som det integrerede udviklingsmiljø sørger for. </para>
<para>Denne håndbog er skrevet for at give udviklere en introduktion til udvikling af KDE-programmer ved at bruge det integrerede udviklingsmiljø KDevelop. </para>
<para>Følgende kapitler giver derfor en introduktion til hvordan projekter laves, forklarer kildekoden som allerede er lavet, og viser hvordan den givne kildekode kan udvides med forskellige funktioner som værktøjslinjer, menulinjer og visningsområder. </para>
<para>Derefter beskrives dialogeditoren i detalje, det forklares hvordan grafiske komponenter laves og hvordan indstillinger af komponentegenskaber udføres i detalje for alle komponenter som er til stede. </para>
<para>Endelig vil du lære om flere emner som udvider din kundskab om projektkonstruktion og hjælper dig med at løse yderligere problemer udover kodning, som at tilføje dokumentation om programgrænsefladen og udvide håndbøger. </para>
<para>Vi vil kigge på QT- og KDE-bibliotekerne, vise grundlæggende begreber og hvorfor tingene ser ud som de gør. Desuden beskriver vi hvordan eksempelprogrammerne som kommer med med QT-værktøjskassen laves ved at bruge KDevelop, så nybegyndere allerede kan se de første resultater efter nogle få skridt, og derved lærer sig hvordan nogen af de bedste funktioner i &tdevelop; bruges. </para>
<para>Desuden bør du søge hjælp ved at abonnere på de forskellige e-mail-lister, hvis adresser er tilgængelige på ovennævnte netsider, og på diskussionsgrupper i Usenet beregnet til brug for KDE og Unix-systemer samt programmeringssprogene C og C++. </para>
<para>For at få hjælp til det integrerede udviklingsmiljøet KDevelop, kan du sende spørgsmål til vores e-mail-liste på <email>kdevelop@kdevelop.org</email>. Husk at KDevelop-gruppen er interesseret i at tilbyde dig muligheder for at lave programmer, og derfor ikke er beregnet til at være en teknisk støttegruppe ifald de programmer du udvikler ikke virker på grund af implementeringsfejl eller forkert indstilling af operativsystemet. Med dette beder vi alle brugere at drage fordel af e-mail-listen i de tilfælde hvor problemer med brug af selve det integrerede udviklingsmiljø opstår, samt for fejlrapporter og forbedringsforslag af funktionerne i udviklingsmiljøet. </para>
<para>Det norske foretagende TrollTech (<ulink url="http://www.trolltech.com">http://www.trolltech.com</ulink>) sørger for en såkaldt GUI-værktøjskasse, som kaldes QT. GUI betyder "grafisk brugergrænseflade", og derfor vises QT-baserede program med knapper, vinduer osv., hvilket muliggør brugerinput ved at synliggøre funktionerne som et program sørger for. En sådan værktøjskasse behøves for at udvikle grafiske programmer som bruger grænsefladen X-windows på Unix-systemer, eftersom X ikke selv indeholder et fordefineret brugergrænseflade. Selv om andre værktøjspakker også er tilgængelige til at oprette en brugergrænseflade, tilbyder QT nogle tekniske fordele som gør programkonstruktion meget enkel. Desuden er QT-værktøjskassen også tilgængelig på Microsoft Windows-systemer, hvilket gør det muligt for udviklerne at lave deres programmer på begge platformene. </para>
<para>KDE-gruppen (<ulink url="http://www.kde.org">http://www.kde.org</ulink>) dannedes med det formål at gøre det mere brugervenligt at bruge Unix-systemer, og bestemte at QT-værktøjskassen skulle bruges til udvikling af en vinduehåndtering for X-windows, samt en mængde værktøjer som indgår i KDE-pakken. K-desktopmiljøet indeholder derfor hovedkomponenterne vinduehåndteringen kwm, filhåndteringen kfm og startpanelet kpanel samt en mængde førsteklasses værktøjer og programmer. Efter KDE blev udgivet, kiggede mange udviklere på det nye miljø og hvad det havde at tilbyde. KDE-bibliotekerne sørger for væsentlige metoder og klasser som gør at alle programmer som konstrueres med dem ligner hinanden og opfører sig ens, så brugeren har den store fordel kun at behøve at vænne sig til brugen af et bestemt program, ikke til håndtering af dialoger og knapper. Desuden integreres KDE-programmer med desktoppen, kan virke sammen med filhåndteringen via træk og slip, tilbyder sessionshåndtering, og meget mere hvis alle funktioner som tilbydes af KDE-bibliotekerne bruges. Både QT-værktøjskassen og KDE-bibliotekerne er implementerede med programsproget C++. Derfor er de fleste programmer som benytter sig af bibliotekerne også skrevet i C++. I de følgende kapitel tager vi en kort tur gennem bibliotekerne for at se hvad der allerede sørges for, og hvordan QT- og KDE-programmer i almindelighed laves. </para>
<para>Både QT-værktøjskassen og KDE-bibliotekerne er implementerede med programsproget C++. Derfor skrives også programmerne som bruger disse biblioteker oftest i C++. I de følgende kapitel tager vi en hurtig tur gennem bibliotekerne for at se hvad der allerede sørges for, og hvordan QT- og KDE-program laves i almindelighed. </para>
<title>QT-værktøjskassen for grafiske brugergrænseflader</title>
<para>Som sagt, er QT-biblioteket en værktøjskasse som tilbyder grafiske elementer som bruges til at lave programmer med grafiske grænseflader og behøves for programmering for X-windows. Desuden tilbyder værktøjskassen: <itemizedlist>
<listitem><para>Et komplet sæt af klasser og metoder klare til at bruge til og med for programmering som ikke berører grafik</para></listitem>
<listitem><para>En god løsning på brugerkommunikationen med virtuelle metoder og mekanismen med signaler og slot</para></listitem>
<listitem><para>Et sæt fordefinerede grafiske grænsefladeselementer, som kaldes "grafiske kontroller" som kan bruges til at oprette synlige elementer</para></listitem>
<listitem><para>Desuden fuldstændige fordefinerede dialoger som ofte bruges i programmer såsom fremgang- og fildialoger</para></listitem>
<para>Derfor er det meget væsentligt at kende til QT-klasserne, også selvom du kun vil programmere KDE-programmer. For at få et indblik i grundbegreberne for at oprette og kompilere et program med grafisk grænseflade, tager vi først et kig på et eksempelprogram som kun bruger QT. Derefter udvider vi det til et KDE-program. </para>
<para>Som sædvanligt skal programmer i C++ indeholde funktionen <function>main()</function>, som er programkørslens startpunkt. Eftersom vi ønsker at programmet skal være synligt som grafik i vinduer og tilbyde kommunikation med brugeren, skal vi først vide hvordan de kan vises for brugeren. Som et eksempel, tager vi et kig på det første eksempel som indgår i QT's referencedokumentation, og forklarer de grundlæggende skridt i kørslen, inklusive hvorfor og hvordan programmets vindue vises: <programlisting>#include <qapplication.h>
<para>Dette program tegner blot et vindue som indeholder en knap med "Hello world" som tekst. Som for alle Qt-baserede programmer, skal du først oprette en udgave af klassen <classname>QApplication</classname>, som repræsenteres af variablen a. </para>
<para>Derefter laver programmet en udgave af klassen <classname>QPushButton</classname> som hedder hello. Dette bliver til knappen. Konstruktøren i hello tager en streng som parameter, som er indholdet af den synlige kontrol, her knappens tekst. </para>
<para>Derefter kaldes metoden <methodname>resize()</methodname> for knappen hello. Den ændrer komponenternes normalstørrelse (som i dette tilfælde er <classname>QPushButton</classname>) som den havde da den oprettedes, til længden 100 billedpunkter og højden 80 billedpunkter. Tilsidst kaldes metoden setMainWidget() og metoden show() for hello. Endelig køres vores QApplication med <methodname>a.exec()</methodname>, går ind i hovedbegivenhedsløkken og venter til den skal returnere en heltalsværdi til det omgivende operativsystem for at signalere at programmet er afsluttet. </para>
<para>Lad os nu tage et hurtigt kig på referencedokumentationen for QT-biblioteket. For at gøre dette, start &tdevelop; og vælg "Qt" i dokumentationsfanebladets træ. Dokumentationssøgeren åbnes og viser startsiden i QT-referencedokumentationen. Dette er det første sted hvor du kan hente information om QT, dens klasser og tilgængelige funktioner som de sørger for. Desuden er ovenstående program det første som er med i vejledningsafsnittet. For at komme til klasserne vil vi kigge på, <classname>QApplication</classname> og <classname>QPushButton</classname>, vælg "Alphabetical Class List" og led efter tilsvarende navne. Følg en af dem for at tage en kig på klassedokumentationen. </para>
<para>Alternativt kan du bruge net-dokumentationen fra TrollTechs <ulink url="doc.trolltech.com">QT-dokumentation</ulink>. </para>
<para>Du vil se konstruktoren og alle andre metoder som klassen <classname>QApplication</classname> sørger for. Hvis du følger et link, får du mere information om brugen og betydningen af metoderne, hvilket er meget nyttigt hvis du sommetider ikke kan indse den rigtige brug eller vil have et eksempel. Dette gælder også dokumentationen af KDE-bibliotekerne, som bruger en lignende slags dokumentation, derfor er dette næsten alt du behøver at vide om at bruge klassereferencer med dokumentationssøgeren. </para>
<para>Tolkningen af hvorfor vi bruger disse metoder er meget enkel: <orderedlist>
<listitem><para>Opret en instans af klassen <classname>QApplication</classname> med konstruktoren, så vi kan bruge elementer for den grafiske grænsefladen som QT sørger for</para></listitem>
<listitem><para>Opret en grafisk komponent som bliver indholdet i vort programvindue</para></listitem>
<listitem><para>Sæt kontrollen som hovedkontrol for en</para></listitem>
<listitem><para>Kør en instans af <classname>QApplication</classname></para></listitem>
<para>Det andet objekt i vort program er trykknappen, en instans af klassen <classname>QPushButton</classname>. Af de to konstruktorer der er til at oprette klassen, bruger vi den anden. Den tager en tekst, som er tekstindholdet i knappen. Her er det strengen "Hello world!". Derefter kalder vi metoden <methodname>resize()</methodname> for at ændre størrelse på knappen ifølge dens indhold. Knappen skal være større for at gøre strengen fuldstændigt synlig. </para>
<para>Men hvad gælder for metoden <methodname>show()</methodname>? Nu mærker du, at som de fleste andre grafiske komponenter, er <classname>QPushButton</classname> baseret på enkelt arv. Dokumentationen siger, Arver <classname>QButton</classname>. Følg linket til klassen <classname>QButton</classname>. Det viser mange andre kontroller som arves af <classname>QPushButton</classname>, som vi senere bruger til at forklare signal/slot-mekanismen. Under alle omstændigheder er metoden <methodname>show()</methodname> ikke på listen, og derfor skal den være en metode som også sørges for via arv. Klassen som <classname>QButton</classname> arver er <classname>TQWidget</classname>. Følg kun linket igen, så ser du en hel mængde metoder som klassen TQWidget sørger for, inklusive metoden <methodname>show()</methodname>. Nu forstår vi hvad der blev gjort i eksemplet med knappen: <orderedlist>
<listitem><para>Fortæl den grafiske kontrol at den skal vises på skærmen ved at kalde <methodname>show()</methodname>, en metode som blev arvet fra <classname>TQWidget</classname></para></listitem>
<para>Efter at have kaldet metoden <methodname>exec()</methodname>, er programmet synligt for brugeren, og viser et vindue med knappen "Hello world!". Bemærk at programmer med grafiske grænseflader opfører sig noget anderledes sammenlignet med procedurebaserede program. Det vigtigste er at programmet går ind i en såkaldt "hovedbegivenhedsløkke". Det betyder at programmet skal vente på brugerens handlinger og derefter reagere på dem. Det betyder også, for et QT-program, at programmet skal være i hovedbegivenhedsløkken for at starte begivenhedshåndteringen. Næste afsnit beskriver kortfattet hvad det betyder for programmøren og hvad QT tilbyder for at håndtere begivenheder. </para>
<note><para>For brugere som allerede er avancerede: Knappen har ingen overliggende kontrol deklareret i konstruktoren. Derfor er den en topniveaukontrol og kører med en lokal begivenhedsløkke som ikke behøver at vente på hovedbegivenhedsløkken. Se dokumentationen for klassen TQWidget og KDE's biblioteksreferenceguide.</para>
<para>Nu fortsætter vi med at give programmet "liv" ved at behandle brugerbegivenheder. I almindelighed har brugeren to måder at kommunikere med et program: musen og tastaturet. En grafisk brugergrænseflade skal sørge for metoder for begge måder, som detekterer handlinger og gør noget som reaktion på handlingerne. </para>
<para>Vinduesystemet sender derfor alle kommunikationsbegivenheder til det tilsvarende program. <classname>QApplication</classname> sender dem derefter til det aktive vindue som en <classname>QEvent</classname>, og kontrollerne selv skal bestemme hvad som skal udføres med dem. En kontrol tager imod begivenheden og behandler <methodname>TQWidget::event(QEvent*)</methodname>, som afgør hvilken begivenhed der er sket og hvordan reaktionen skal være. Metoden <methodname>event()</methodname> udfører derfor håndteringen af hovedbegivenheden. Derefter sender metoden <methodname>event()</methodname> begivenheden til et såkaldt begivenhedfilter som afgør hvad der sker og hvad der skal udføres med begivenheden. Hvis intet filter signalerer at det er ansvarligt for begivenheden, kaldes speciel begivenhedshåndtering. På den måde kan vi skelne mellem: <itemizedlist>
<para>Bemærk at alle begivenhedsfunktioner er virtuelle og protected. Derfor kan du implementere begivenhederne som du behøver i egne kontroller og angive hvordan din kontrol skal reagere. <classname>TQWidget</classname> indeholder også nogle andre virtuelle metoder som kan være nyttige i dine programmer. Under alle omstændigheder er det nødvendigt at kende <classname>TQWidget</classname> godt. </para>
<title>Interaktion mellem objekt med signaler og slots</title>
<para>Nu kommer vi til den mest åbenbare fordel ved QT-værktøjskassen: signal/slot-mekanismen. Den tilbyder en meget bekvem og nyttig løsning for kommunikation mellem objekter, som sædvanligvis løses med tilbagekaldsfunktioner i X-windows værktøjskasser. Eftersom kommunikationen kræver strikt programmering og ind imellem gør det meget svært at oprette brugergrænseflader (som beskrevet i QT-dokumentationen og forklaret i Programming with Qt af K. Dalheimer), opfandt TrollTech et nyt system hvor objekter kan sende signaler som kan forbindes til metoder som deklareres som slots. Som programmør af C++, behøver man kun at vide nogen ting om denne mekanisme: <itemizedlist>
<listitem><para>klassedeklarationen af en klasse som bruger signaler og slots skal indeholde makroen TQ_OBJECT i begyndelsen (uden et semikolon), og skal afledes fra klassen <classname>TQObject</classname> </para></listitem>
<listitem><para>et signal kan sendes med nøgleordet emit, f.eks. emit signal(parametre);, inde i en hvilken som helst medlemsfunktion i en klasse som tillader brug af signaler og slots </para></listitem>
<listitem><para>alle signaler som bruges af klasser som ikke arves skal tilføjes i klassedeklarationen i en signalsektion </para></listitem>
<listitem><para>alle metoder som kan forbindes med et signal deklareres i sektioner med det yderligere nøgleord slot, f.eks. public slots: inde i klassedeklarationen </para></listitem>
<listitem><para>metaobjektoversætteren moc skal køres over deklarationsfilen for at ekspandere makroer og oprette implementeringen (som man ikke behøver kende til). Uddatafilerne fra moc kompileres også af C++ oversætteren. </para></listitem>
<para>En anden måde at bruge signaler uden at aflede fra <classname>TQObject</classname> er at bruge klassen <classname>QSignal</classname>. Se referencedokumentationen for mere information og eksempel på brug. Vi antager at du afleder fra <classname>TQObject</classname> i det følgende. </para>
<para>På denne måde kan din klasse sende signaler hvor som helst og sørge for slots som signaler kan forbindes til. Ved at bruge et signal, behøver du ikke bryde dig om hvem der modtager det. Du behøver kun at sende signalet, og hvilken slot du end forbinder den til kan reagere når den sendes. Desuden kan en slot bruges som en almindelig metode i implementeringen. </para>
<para>For nu at forbinde et signal til en slot, skal du bruge metoderne <methodname>connect()</methodname> som varetages af <classname>TQObject</classname> eller, hvis tilgængelige, specielle metoder som objekter sørger for for at angive forbindelsen for et vist signal. </para>
<para>For at forklare hvordan objektinteraktion håndteres, tager vi vort første eksempel igen og udvider det med en enkel forbindelse: <programlisting>#include <qapplication.h>
<para>Du mærker at alt du skal tilføje for at give knappen mere kommunikation er metoden <methodname>connect()</methodname>: <methodname>connect (&hello, TQ_SIGNAL( clicked() ), &a, TQ_SLOT( quit() ))</methodname>;. Hvad er betydningen nu? Klassedeklarationen af TQObject siger følgende om metoden <methodname>connect()</methodname>: </para>
<para>Dette betyder at du skal angive en <classname>TQObject</classname>-instanspeger som er signalets afsender, hvilket betyder at den kan sende signalet, som første parameter. Derefter skal du angive signalet som du vil forbinde til. De to sidste parametre er modtagerobjektet som sørger for en slot, fulgt af medlemsfunktionen som er en virkelig slot som vil køres når signalet sendes. </para>
<para>Ved at bruge signaler og slots, kan programmets objekter nemt kommunikere med hinanden uden udtrykkeligt at afhænge af typen af modtagarobjektet. Du vil lære mere om hvordan denne mekanisme bruges produktivt senere i håndbogen. Mere information om signal/slot-mekanismen findes også i <ulink url="developer.kde.org/documentation/library/libraryref.html">KDE's biblioteksreferenceguide</ulink> og <ulink url="doc.trolltech.com">QT's reference på nettet</ulink>. </para>
<para>Du ser i det følgende, at det ikke er meget sværere at skrive et KDE-program end et QT-program. Du skal kun bruge nogle andre klasser for at komme til KDE's funktioner, så er du næsten klar. Vi diskuterer en ændret version af QT-koden ovenfor, som et eksempel: <programlisting>#include <tdeapplication.h>
<para>Du ser at vi først har ændret fra <classname>QApplication</classname> til <classname>TDEApplication</classname>. Desuden var vi tvunget til at ændre den tidligere brugte metode <methodname>setMainWidget()</methodname> til <methodname>setTopWidget</methodname> som <classname>TDEApplication</classname> bruger til for at angive hovedkontrollen. Det er alt! Dit første KDE-program er klart. Du behøver kun at fortælle oversætteren hvilken deklarationssøgesti KDE har, og linkeren at den skal linke med tdecore-biblioteket med -ltdecore. </para>
<para>Eftersom du nu i det mindste ved hvad funktionen <function>main()</function> i almindelighed sørger for, og hvordan et program bliver synligt og tillader kommunikation mellem brugere og objekt, fortsætter vi med næste kapitel, hvor vort første program med &tdevelop; laves. Der kan du også prøve alt som tidligere blev nævnt, og se effekterne. </para>
<para>Hvad du yderligere bør have kigget på hidtil er QT-referencedokumentationen, især klasserne <classname>QApplication</classname>, <classname>TQWidget</classname> og <classname>TQObject</classname> og tdecore-biblioteksdokumentationen for klassen <classname>TDEApplication</classname>. <ulink url="developer.kde.org/documentation/library/libraryref.html">KDE's biblioteksreferenceguide</ulink> har også en fuldstændig beskrivelse af hvordan konstruktorerne i <classname>QApplication</classname> og <classname>TDEApplication</classname> kaldes, inklusive behandling af kommandolinjeflag. </para>
<para>Programguiden i &tdevelop; er beregnet til at lade dig begynde at arbejde med et nyt projekt i &tdevelop;. Derfor laves alle projekter først af guiden, og derefter kan du begynde at bygge dem og udvide det som allerede varetages af kildekodeskelettet. Du kan vælge blandt flere projekttyper ifølge målet med dit projekt: <itemizedlist>
<listitem><para>KDE Application Framework: Indeholder kildekode for en fuldstændig rammestruktur til et almindeligt KDE-program </para></listitem>
<listitem><para>QMake project: Laver et programskelet baseret på TrollTechs qmake konfigurationssystem </para></listitem>
<listitem><para>Simple Hello world program: Opretter et C++ terminalbaseret program uden støtte for grafisk grænseflade </para></listitem>
<listitem><para>En mængde andre programskeletter </para></listitem>
<para>I dette kapitel ser vi hvordan Programguiden kan startes, og hvad der skal udføres for at oprette et KDE-programmeringsprojekt. Dette er også det første skridt i opfølgningen hvor vi laver den oprindelige version af vort eksempelprojekt. Skridtene er oftest ens for alle andre projekttyper, men der er måske ikke så mange tilgængelige alternativer. </para>
<title>Start af programguiden og første side</title>
<para>Åbn &tdevelop; for at begynde med dit KDE-program. Vælg Nyt projekt i projektmenuen. Programguiden starter, og du ser udvalgstræet på første side som indeholder tilgængelige projekttyper som kan laves. Vælg deltræet C++, derefter KDE, og Application framework. </para>
<para>Vi vil lave programmet KScribble som eksempelprojekt. Indtast det som programmets navn, og ændr eventuelt anden information som behøves længst nede på skærmen. Vælg derefter Næste. <screenshot><mediaobject><imageobject>
<para>På denne skærm har du mulighed for at bestemme om projektet skal bruge et versionskontrollsystem som CVS. For vort eksempelprojekt bruger vi ikke versionskontrol, så sørg for at feltet siger Intet, og vælg Næste. </para>
<title>Deklarations- og kildekodeskabeloner</title>
<para>Følgende to sider viser eksempler på sidehoveder som havner øverst i deklarations- og kildekodefilerne som du laver med &tdevelop;. Lad dem blot være som de er for øjeblikket, og vælg Næste og derefter Afslut. Hvis knappen Afslut ikke er aktiveret, har du ikke indstillet alle valgmuligheder rigtigt. Brug knappen Tilbage for at gå tilbage til tidligere sider og ret eventuelle fejl. </para>
<para>Når den er færdig, skal Programguiden lukkes og meddelelsesvinduet skulle dukke op og vise information om aktiviteterne som &tdevelop; for øjeblikket udfører. I slutningen af alle aktiviteter skal du se **** Succes ****. Det betyder at det er lykkedes at lave programmets rammeomgivelser. </para>
<para>Efter at projektet har oprettet, tager vi først en tur gennem kildekoden for at få en almen forståelse for hvordan programmets rammeomgivelser ser ud. Det hjælper os ikke kun med at komme i gang, men vi ved også hvor ændringer skal udføres i senere skridt. </para>
<para>I dette kapitel gøres antagelsen at du forstår den grundlæggende håndtering af &tdevelop;. Kig i KDevelops håndbog for at finde information hvis du behøver det. </para>
<para>Håndtering af automake viser projektfilerne som følger: <screenshot><mediaobject><imageobject>
<para>Inden vi dukker ned i kildekoden, skal vi lade &tdevelop; bygge og køre vort nye program. For at gøre det, vælges Byg projekt i menuen Byg, eller der trykkes på F8. Udskriftsvinduet åbnes og viser udskrevne meddelelser under kompileringsfasen. <programlisting>1 cd /home/caleb/kscribble && WANT_AUTOCONF_2_5=1 WANT_AUTOMAKE_1_6=1 gmake k
<para>Som du kan se, har vi puttet linjenumre foran hver linje som ikke vises i udskriften, men som gør det nemmere at beskrive hvad der sker under bygningen. For det første virker byggeprogrammet rekursivt. Det betyder at det begynder i mappen hvor det startes, først går ned i undermapper, en af gangen, og derefter går tilbage til mappen hvor det startedes, behandler den, og derefter afslutter. </para>
<para>Den første interessante linje er 24. Bemærk at g++, som er vores C++ oversætter, kaldes af make på denne linje for at kompilere den første kildekodefilen i vores projekt - i dette tilfælde main.cpp. Mange yderligere kommandolinjeflag bruges også med g++ oversætteren. Visse er standard, mens andre kan indstilles via &tdevelop;. </para>
<para>Inden næste fil (kscribble.cpp, linje 29) kompileres, køres først moc (metaobjektoversætteren) for kscribble.h (linje 25). Det sker fordi KScribble-klasser bruger signaler og slots, så makroen TQ_OBJECT skal ekspanderes, og moc gør det for os. Resultatfilen, kscribble.moc, bruges af kscribble.cpp via udsagnet #include i filen. </para>
<para>For at gøre det klart hvordan et KDE-program virker, skal vi først undersøge kildekodeskelettet, som allerede varetages af programguiden, meget nøjagtigt. Som vi allerede har set, har vi et sæt kildekode- og deklarationsfiler som opbygger den oprindelige programkode og gør den klar til at køre. Derfor er den nemmeste måde at forklare koden at følge implementeringen linje for linje som den behandles under kørsel af programmet til det går ind i hovedbegivenhedsløkken og er klart til at acceptere brugerindput. Derefter kigger vi på funktionerne som muliggør kommunikation med brugeren, og hvordan visse ting fungerer. Dette er formodentlig den bedste måde at forklare rammeomgivelserne, og eftersom det er ens for næsten alle KDE-programmer, gør det at du kan læse kildekode også fra andre projekter. Desuden lærer du dig hvor forskellige dele af koden skal ændres for at få dit program til at opføre sig som det er beregnet til at gøre. </para>
<para>Eftersom programmet begynder at køre ved at gå ind i funktionen <function>main()</function>, er det der vi begynder at kigge på koden. Funktionen <function>main()</function> i KScribble er implementeret i filen main.cpp, og kan også findes ved at bruge klassesøgeren og vælge mappen "Globale funktioner". <programlisting>1 int main(int argc, char **argv)
<para>Det der først sker nu, er at objektet <classname>TDEApplication</classname> laves som almindeligt, men vi har tilføjet nogle KDE-metoder som angiver information om programmet og forfatteren af programmet. </para>
<para>Bemærk at <classname>KScribble</classname> arver klassen <classname>TDEMainWindow</classname>, en ofte brugt basisklasse for KDE-programmer. Vi initierer en klasse som hedder <classname>KScribbleView</classname> som central grafikkomponent, laver en <classname>KStatusBar</classname> via metoden <methodname>statusBar()</methodname> (på linje 16), og forbinder nogle signaler og slots. </para>
<para>Når et program med en grafisk grænseflade udvikles, sker hoveddelen af arbejdet ved at sørge for en såkaldt "visning" for programmet. En visning er i almindelighed en grafisk kontrol som viser data i et dokument og sørger for metoder til at manipulere dokumentets indhold. Dette kan udføres af brugeren via de begivenheder som laves via tastaturet og musen. Kompleksere handlinger behandles ofte af værktøjslinjer og menulinjer som kommunikerer med visningen og dokumentet. Statuslinjen sørger så for information om dokumentet, visningen eller programmets status. Som eksempel, kigger vi på hvordan en editor er konstrueret, og hvor hver del kan findes. </para>
<para>En editor antages i almindelighed at sørge for en grænseflade til at vise og/eller ændre indhold i et tekstdokument for brugeren. Hvis du starter Kate, ser du følgende i den visuelle grænseflade: <itemizedlist>
<listitem><para>Menulinjen: sørger for komplekse handlinger samt at åbne, gemme og lukke filer eller afslutte programmet. </para></listitem>
<listitem><para>Værktøjslinjen: tilbyder ikoner som giver hurtigere adgang til de oftest brugte funktioner, </para></listitem>
<listitem><para>Statuslinjen viser status for markørpositionen med nuværende linje og søjle, </para></listitem>
<listitem><para>Visningen i vinduets midte, som viser et dokument og tilbyder en markør forbundet til tastaturet og musen for at håndtere data. </para></listitem>
<para>Nu er det enkelt at forstå at en visning er programmets mest enestående del, og at konstruktionen af visningen bestemmer hvor nyttigt og let at acceptere programmet er. Det betyder at et af de første skridt i udviklingen er at afgøre formålet med programmet og hvilken slags konstruktion af visningen som passer bedst til at lade en hvilken som helst bruger arbejde med programmet, med en minimal anstrengelse for at lære sig hvordan brugergrænsefladen skal håndteres. </para>
<para>Visninger varetages af QT- og KDE-bibliotekerne for visse formål, såsom tekstredigering og visning af HTML-filer. Vi beskriver visse aspekter af disse her højniveaukontroller i næste afsnit. Men for de fleste programmer skal nye komponenter konstrueres og implementeres. Det er dette som gør at programmøren også bliver en formgiver, og hvor kreativiteten sættes på prøve. Trods dette bør du først forsøge at opnå noget intuitivt. Husk at mange brugere accepterer ikke et program som ikke: <itemizedlist>
<listitem><para>har et godt grafisk udseende </para></listitem>
<listitem><para>tilbyder mange funktioner </para></listitem>
<listitem><para>er nemt at håndtere </para></listitem>
<listitem><para>er hurtigt at lære at bruge </para></listitem>
<para>Det behøves ikke at siges at stabilitet er et af hovedmålene med konstruktionen. Ingen kan forhindre fejl, men et minimum kan i det mindste opnås med smarte konstruktionsmål og udbredt brug af objektorienterede konstruktioner. C++ gør det til en fornøjelse at programmere hvis du ved hvordan man udnytter dens muligheder - arv, at skjule information og genbrug af eksisterende kode. </para>
<para>Når et KDE- eller QT-projekt laves, skal du altid have en visning som arver en TQWidget, enten med direkte arv eller fordi en bibliotekskontrol som du vil bruge arver TQWidget. Derfor har Programguiden allerede oprettet en visning som er en instans af klassen programnavnView, som allerede arver TQWidget. </para>
<para>Dette kapitel beskriver derfor hvordan bibliotekskontroller bruges til at oprette visninger for KDE- og QT-programmer som laves med &tdevelop;. Derefter kigger vi på bibliotekerne og hvilke slags visninger de allerede tilbyder. </para>
<para>Når programmets konstruktion er sat op, bør du først lede efter eksisterende kode som kan gøre livet meget enklere. En del af dette er at lede efter en grafisk komponent som kan bruges til visningen, eller i det mindste for en del af den, enten direkte eller med arv. KDE- og QT-bibliotekerne indeholder allerede et sæt grafiske komponenter som kan bruges til endemålet. Der er to muligheder at bruge dem: <orderedlist>
<listitem><para>Fjern den nye visningsklasse og opret en instans af en bibliotekskontrol, og sæt den så som visningen, </para></listitem>
<listitem><para>Ændr arv for den visningsklasse der sørges for, til klassen for bibliotekskontrollen som skal bruges. </para></listitem>
<para>Under alle omstændigheder er det vigtigt at vide at hvis programskelet ikke linkes med biblioteket som indeholder den grafiske kontrol for øjeblikket, kommer linkningen til at mislykkes. Efter du har bestemt dig for at bruge en vis grafisk kontrol, så kig efter biblioteket som skal linkes ind. Åbn derefter "Projekt"->"Projektindstillinger" i menulinjen for &tdevelop;. Gå til siden "Link-indstillinger" og led efter afkrydsningsfelterne som angiver de biblioteker som bruges for øjeblikket. Hvis biblioteket for din kontrol allerede er markeret, kan du lade projektindstillingerne være uforandrede og begynde at gøre de nødvendige ændringer baseret på dit valg. Hvis ikke, og linkindstillingerne tilbyder at tilføje biblioteket med et afkrydsningsfelt, så markér den og tryk på "O.k." for at lukke dialogen igen. I alle andre tilfælde, tilføj biblioteket i redigeringslinjen nedenunder med flaget -l. For biblioteker som dit program skal søge efter inden byggefiler laves af configure-scriptet, tilføjes tilsvarende søgemakro i filen configure.in som findes i projektets rodmappe, og makroen tilføjes på redigeringslinjen. Tænk på at du skal køre "Byg"->"Autoconf og automake" og "Byg"->"Configure" inden byggefilerne indeholder den rigtige ekspansion af biblioteksmakroen. </para>
<para>Desuden, hvis deklarationsfilerne for biblioteket som skal tilføjes ikke er med i den nuværende deklarationssøgesti (som ses i flaget -I for "make" i udskriftsvinduet), skal du tilføje søgestien i dialogen Projektindstillinger på siden "Oversætterindstillinger" med flaget -I eller i den tilsvarende automake-makro på redigeringslinjen for "Yderligere indstillinger". </para>
<para>Når du kigger på den første side af QT's net-dokumentation, finder du et link til "Widget Screenshots", hvor du kan kigge på hvordan de grafiske kontroller som QT indeholder ser ud. De er parate til at bruge, og kan kombineres til at give komplekse kontroller som kan oprette programvisninger eller dialoger. I det følgende beskriver vi nogle af disse, som er meget nyttigt til at oprette programvisninger, men husk at KDE-bibliotekerne sommetider indeholder andre kontroller med samme formål. Disse diskuteres i næste afsnit. </para>
<para>Her er nogle vink om hvilken Qt-komponent der kan bruges til hvilket slutmål: <orderedlist>
<listitem><para>Hvis visningsområdet ikke er stort nok til at vise alle data, skal brugeren kunne panorere i dokumentet med lister til venstre og længst nede i visningen. QT sørger for klassen <classname>QScrollView</classname> for dette, som tilbyder et underliggende område med panoreringsmulighed. Som tidligere forklaret, kan du lade dine egne grafiske kontroller arve <classname>QScrollView</classname>, eller bruge en instans for at håndtere dit dokuments visningskomponent. </para></listitem>
<listitem><para>For at oprette en egen ScrollView, lad komponenten View arve fra <classname>TQWidget</classname> og tilføj lodrette og vandrette rullebjælker med <classname>QScrollBars</classname>. (Dette udføres af KDE's kontrol TDEHTMLView.) </para></listitem>
<listitem><para>Til tekstbehandling, bruges <classname>QTextEdit</classname>. Denne klasse sørger for en fuldstændig grafisk teksteditorkontrol, som allerede kan klippe, kopiere og indsætte tekst og håndteres af en visning med rullebjælker. </para></listitem>
<listitem><para>Brug <classname>QTable</classname> til at vise data som er arrangeret i en tabel. Eftersom <classname>QTable</classname> også håndteres af rullebjælker, tilbyder den en god løsning for programmer med tabelberegninger. </para></listitem>
<listitem><para>For at vise to forskellige grafiske kontroller eller to instanser af samme kontrol samtidigt, bruges <classname>QSplitter</classname>. Den tillader at visninger lægges side ved side med vandrette eller lodrette opdelere. Kmail er et godt eksempel på hvordan det ser ud. Hovedvinduet er opdelt lodret af en opdeler, og det højre vindue er igen opdelt vandret. </para></listitem>
<listitem><para><classname>QListView</classname> viser information i en liste og et træ. Det er nyttigt til at oprette filtræer eller en hvilken som helst anden hierarkisk information som du vil håndtere. </para></listitem>
<para>Du mærker at kun QT tilbyder et helt sæt grafiske kontroller som er klare til brug, så du ikke behøver opfinde nye løsninger hvis de passer til dine behov. Sideeffekten når standardkontroller bruges er at brugere allerede ved hvordan de håndteres, og kun behøver koncentrere sig om de data som vises. </para>
<para>KDE-bibliotekerne blev opfundet for at gøre det nemmere at designe programmer for K-desktopmiljøet og gøre det muligt for dem at have flere funktioner end kun hvad QT tilbyder. Biblioteket tdeui tilbyder: <orderedlist>
<listitem><para>TDEListView: en mere kraftfuld version af <classname>QListView</classname> </para></listitem>
<listitem><para>TDEIconView: en grafisk viser af ikonfiler </para></listitem>
<para>Biblioteket tdehtml sørger på den anden side en fuldstændig HTML-tolkningskomponent, som er klar til brug. Den har allerede rullebjælker, så du behøver ikke engang at håndtere det. En mulig brug kan være at integrere den som en forhåndsvisningskontrol for en HTML-editor. Den bruges af programmer såsom Konqueror til at vise HTML-filer. </para>
<para>Menulinjer og værktøjslinjer er nogen af de vigtigste dele af et program til at sørge for metoder at arbejde med en dokumentstruktur. Du bør gøre alle funktioner tilgængelige via menulinjen, som en almen regel. Disse metoder som ikke er tilgængelige på et vist tidspunkt i brugen af programmet bør være deaktiverede. </para>
<para>Desuden kan et program kun indeholde en menulinje, men flere værktøjslinjer. Værktøjslinjer, på den anden side, bør kun indeholde de oftest brugte kommandoer med ikoner eller sørge for metoder til hurtig adgang som kombinationsfelter til at vælge værdier. </para>
<para>Vort program arver klassen <classname>TDEMainWindow</classname> som automatisk håndterer at oprette en menulinje og værktøjslinjer for os. I metoden <methodname>KScribble::setupActions()</methodname> er der et kald til <methodname>TDEMainWindow::createGUI()</methodname>. Denne metode indlæser en ressourcefil, i dette tilfælde kscribbleui.rc, for at initiere menuerne ved start. Bemærk at kscribbleui.rc er på listen som en af projektfilerne i Håndtering af automake. Åbnes filen ses dette: <programlisting>1 <!DOCTYPE kpartgui SYSTEM "kpartgui.dtd">
<para>En anden måde at ændre indholdet i menuen og værktøjslinjerne er at manipulere dem direkte via metoderne som der sørges for i deres klasser. Metoden <methodname>menuBar()</methodname> returnerer for eksempel kontrollen <classname>KMenuBar</classname> som er menulinjen i vort program. Kigger du i dokumentationen for <classname>KMenuBar</classname> og klassen den arver <classname>QMenuBar</classname>, finder du et stort antal metoder der hedder <methodname>insertItem()</methodname>, som lader dig tilføje punkter til menulinjen. </para>
<para><classname>TDEMainWindow</classname>s metoder <methodname>statusBar()</methodname> og <methodname> toolBar()</methodname> giver dig også passende grafiske kontroller. </para>
<para>Noget meget professionelt som du altid bør tilføje i programmet er genvejstaster. De bruges oftest af erfarne brugere som vil arbejde hurtigt med deres programmer og er villige til at lære sig genveje. KDE-bibliotekerne tilbyder klassen <classname>TDEAction</classname> til dette, som sørger for genvejstaster og adgang til globalt indstillede standardgenveje. </para>
<para>Normalt bruger kun rammeprogrammer oprettet af &tdevelop; almindelige genvejstaster såsom F1 for at komme til nethjælp, Ctrl+N for Ny fil, osv. </para>
<para>Hvis programmet indeholder mange genvejstaster bør du gøre dem indstillelige via en indstillingsmenu. Enten kan det kombineres med anden programindstilling i en TQWidget eller være alene. KDE-biblioteket sørger allerede for en <classname>KKeyChooser</classname> til at bruge i fanebladsdialoger, mens <classname>KKeyDialog</classname> sørger for en indstillingsdialog for genvejstaster som er parat til brug. </para>
<para>En meget vigtig del af udviklingsprocessen er at sørge for hjælpefunktioner for brugeren om muligt. De fleste udviklere tenderer at forsinke dette, men du bør huske at en normal bruger ikke nødvendigvis er en Unix-ekspert. Han kommer måske fra den mørke side af programmelbrug som tilbyder alle gode ting som en bruger kan behøve for at indarbejde sig i brugen af et program uden nogensinde at røre ved en håndbog. Derfor sørger KDE- og QT-bibliotekerne for alle muligheder som oftest anses at gøre et program professionelt i den almindelige brugers øjne, med hjælpefunktioner som er klare til brug. Inde i programmet er de:</para>
<para>Desuden bør programmet sørge for en mulighed for at komme til en HTML-baseret håndbog direkte med den almindelige hjælpetast F1. Dette sammenhængsafhængige hjælpesystem sørges der automatisk for via klassen <classname>TDEMainWindow</classname>, også selvom du som forfatter skal sørge for indholdet. </para>
<para>Eftersom &tdevelop; også tilbyder alle slags hjælp, ligesom KDE-rammeomgivelserne som laves af programguiden allerede indeholder støtte for dette, hjælper dette kapitel dig med at lære dig hvor og hvordan du kan tilføje hjælpefunktioner. </para>
<para>Under udviklingen af programmet bør du forsøge at være konsekvent i hvad du gør. Derfor bør du udføre nødvendige skridt direkte når du udvider koden. Det forhindrer at du behøver at dykke ned i koden igen for at finde ud af hvad programmet gør eller hvad du havde til hensigt med visse dele af koden. </para>
<para>En meget nem måde at sørge for hjælp er værktøjsvink. De er små hjælpemeddelelser som dukker op når brugeren flytter musen hen over en kontrol som sørger for et værktøjsvink, og forsvinder når musen flyttes. Den populæreste brug af værktøjsvink er i værktøjslinjer hvor værktøjsvinkene bør være så små som muligt, eftersom værktøjslinjer kan indstilles til at vise indholdet på forskellige måder: enten vises knappen, knappen med tekst til højre, knappen med tekst nedenfor, eller kun tekst. Denne indstilling bør kunne indstilles af brugeren, men det er ikke helt nødvendigt. Teksten vises alligevel som et værktøjstips, og en værktøjslinje består oftest af knapper og andre grafiske kontroller såsom redigeringsfelter og kombinationsfelter. For en fuldstændig beskrivelse, se klassereferencen for <classname>TDEToolBar</classname>, som findes i tdeui-biblioteket. </para>
<para>Som et eksempel kigger vi på knappen "Ny fil" i et generelt program: </para>
<para>Der sørger parten i18n("New File") for meddelelsen i værktøjsvinket. Det omgives af makroen i18n(), som som sørges for af kapp.h, for at oversætte værktøjsvinket til sproget som for øjeblikket er valgt. </para>
<para>Værktøjsvink kan også tilføjes i hvilken som helst egen grafisk kontrol ved at bruge <classname>QToolTip</classname> som QT sørger for. Et eksempel på det ville kunne være: </para>
<para>Eftersom programmer som arver <classname>TDEMainWindow</classname> også indeholder en statuslinje, tilbyder den også et sæt færdige statuslinjemeddelelser for alle menu- og værktøjslinjesobjekter. En hjælpemeddelelse i statuslinjen er en kort meddelelse som udvider betydningen af et værktøjsvink, eller kan ses som en erstatning for et værktøjsvink for et punkt i menulinjen, og vises (som navnet angiver) i statuslinjen når brugeren aktiverer en menu og markerer et menupunkt. </para>
<title>Knappen <guibutton>Hvad er dette?</guibutton></title>
<para>Knappen <guibutton>Hvad er dette...?</guibutton> sørger for hjælpevinduer med formålet at give brugeren hjælp med en vis kontrol i visningen som bruges eller et objekt i en værktøjslinje. Den er i værktøjslinjen og aktiveres når brugeren trykker på knappen. Markøren ændres til en pilemarkør med et spørgsmålstegn, præcis som knappen selv ser ud. Derefter kan brugeren klikke på en synlig kontrol og får så et hjælpevindue. Som en øvelse kan du prøve opførslen med knappen <guibutton>Hvad er dette...?</guibutton> inde i &tdevelop;. </para>
<para>For at tilføje "Hvad er dette...?" hjælp til en af dine grafiske kontroller, bruges den statiske metode <methodname>QWhatsThis::add(TQWidget *widget, const TQString &text)</methodname> </para>
<para>På grund af at projekter ofte mangler et fuldstændigt sæt brugerdokumentation, indeholder alle projekter i &tdevelop; en håndbog oprettet i forvejen. På den måde opfyldes et andet af KDE's mål: At sørge for tilstrækkeligt med nethjælp for at støtte brugere som ikke er bekendte med programmet. Dette kapitel introducerer derfor hvordan dokumentationsskabelone der sørges for kan udvides, og hvad du skal gøre for at brugeren skal få adgang til den. </para>
<para>Projektdokumentationen er i projektmappe/doc/en, eller måske en anden mappe hvis engelsk ikke er dit modersmål. Der er en fil, index.docbook, hvor dokumentationen opbevares. Formatet for at redigere filen forklares på <ulink url="http://i18n.kde.org/doc/markup/">KDE's netside for dokumentation</ulink>. </para>
<para>En anden vigtig del af dokumentationen er at inkludere en beskrivende hjælp for klassegrænsefladen. Det lader dig og andre programmører bruge dine klasser ved at læse klassedokumentationen i HTML, som kan laves med KDoc. &tdevelop; understøtter fuldstændigt brug af KDoc til at oprette KDE-biblioteksdokumentation en, rammeomgivelserne for dit program er også allerede dokumenteret. For at arbejde sig ind i koden som der sørges for, er det en god starte at læse netdokumentationen. Det følgende beskriver hvad som skal udføres for at få dokumentation af programmeringsgrænsefladen frem, hvordan &tdevelop; hjælper dig med at tilføje den, og hvilke særlige mærker som KDoc sørger for. </para>
<para>Internationalisering med i18n er et system som bruges for at tilbyde internationale versioner af et program eller projekt. Det svære ved at skrive programmer er at de kun understøtter sproget som de oprindelig blev lavet med. Dette synliggøres med tekster, menupunkter og lignende. Målet med internationaliseringen er at sørge for programmer og biblioteksfunktioner på brugerens sprog, og på den måde gøre det muligt for brugere som ikke har originalsproget som modersmål at bruge funktionerne som tilbydes og føle sig mere fornøjet og behagelig. </para>
