>&chalk; kan udvides i det uendelige med plugin. Værktøjer, filtre, store dele af brugergrænsefladen og alle farverum er plugin. I virkeligheden genkender &chalk; følgende seks typer plugin: </para>
>Selve &chalk; består af tre biblioteker i lag og en mappe med visse fælles støtteklasser: chalkcolor, chalkimage og chalkui. Inde i &chalk; kan objekter identificeres af en <classname
>, som er en kombinationen af en entydig uoversat streng (som for eksempel bruges når noget skal gemmes) og en øversat streng beregnet til den grafiske brugergrænseflade. </para
>Et ord om kompatibilitet: &chalk; er stadigvæk under udvikling. Fra &chalk; 1.5 til 1.6 forventes ikke mange ændringer af programmeringsgrænsefladen, men der kan være nogle. Fra &chalk; 1.6 til 2.0 skifter vi fra &Qt; 3 til &Qt; 4, fra &kde; 3 til &kde; 4 og fra <command
>: mange ændringer kan forventes. Hvis du udvikler et plugin for &chalk; og vælger at gøre det i &chalk;s subversion-arkiv, er der udmærkede muligheder for at vi hjælper dig med overførslen. Ændringerne kan også gøre at visse dele af dette dokument bliver forældede. Tjek altid den seneste dokumentation af programmeringsgrænsefladen eller deklarationsfilerne som er installerede på dit system. </para>
>Biblioteket libchalkimage indlæser filter- og maleoperationsplugin, og er ansvarligt for at arbejde med billeddata: ændre billedpunkter, sammensætte og male. Pensler, paletter, toninger og mønstre indlæses også af libchalkimage. Det er et udtalt mål at gøre libchalkimage uafhængig af &koffice;, men for øjeblikket deler vi koden til at indlæse toninger med &koffice;. </para
>Det er for øjeblikket ikke nemt at tilføje nye typer af ressourcer såsom pensler, paletter, toninger eller mønstre i &chalk;. (At tilføje nye pensler, paletter, toninger og mønstre er naturligvis enkelt.) &chalk; følger anvisningerne fra projektet Create (<ulink url="http://create.freedesktop.org/"
>) for disse. At tilføje understøttelse for Photoshops penselfilformat kræver kodning i libchalkimage. At tilføje flere penseldatafiler fra Gimp kræver ikke dette. </para
>. Et eksempel på et filter er Uskarp maske.</para
></listitem>
<listitem
><para
>Maleoperationer er det sæt af operationer som maleværktøjer såsom frihånd eller cirkel har adgang til. Eksempel på maleoperationer er pen, retuschsprøjte eller viskelæder. Maleoperationer skal udvide basisklassen <classname
>KisPaintop</classname
>. Eksempel på nye maleoperationer kunne være en kridtbørste, en pensel til oliemaling eller en kompleks programmerbar pensel.</para
>Biblioteket libchalkui indlæser værktøjet og visningsplugin. Dette bibliotek er et &koffice;-partprogram, men indeholder også et antal grafiske kontroller som er nyttige i grafikprogrammer. Måske skal dette bibliotek deles i chalkpart og chalkui for udgave 2.0. For øjeblikket gives forfattere af scripter ikke adgang til dette bibliotek og forfattere af plugin tillades kun at bruge dette bibliotek når værktøerj og visningsplugin skrives. <classname
> eller en af de specialiserede værktøjsbasisklasser såsom <classname
>KisToolPaint</classname
>, <classname
>KisToolNonPaint</classname
> eller <classname
>KisToolFreehand</classname
>. Et nyt værktøj kunne være et værktøj til markering af forgrunden. Maleværktøjer (og det omfatter værktøjer som maler på markeringen) kan bruge en hvilken som helst maleoperation til at bestemme hvordan billedpunkter ændres.</para
></listitem>
<listitem
><para
>Visningsplugin er sædvanlige KParts, som bruger <command
> til at indlejre sig i &chalk;s brugergrænseflade. Menupunkter, dialoger, værktøjslinjer — alle slags udvidelser af brugergrænsefladen kan være visningsplugin. I virkeligheden er vigtige funktioner, såsom &chalk;s understøttelse for scripter, skrevet som visningsplugin.</para
>. Filtre læser og skriver billeddata på et af de utroligt mange billedformater som eksisterer. Et eksempel på et nyt import- og eksportfiler for &chalk; kunne være et PDF-filter. Filtre indlæses af &koffice;-bibliotekerne. </para>
>Plugin skrives i C++ og kan bruge hele programmeringsgrænsefladen i &kde; og &Qt; samt &chalk;s udviklingsgrænseflade. Kun visningsplugin skal bruge &koffice;' programmeringsgrænseflade. Du skal ikke bekymre dig, &chalk;s programmeringsgrænseflade er meget ren og relativt udførligt dokumenteret (af frit programmel at være) og at kode dit første filter er meget nemt. </para
>Hvis du ikke vil bruge C++ kan du skrive scripter i Python eller Ruby: det er dog en helt anden sag, og du kan for øjeblikket ikke skrive værktøjer, farverum, maleoperationer eller import- og eksportfilter som scripter. </para
>Plugin i &chalk; bruger &kde;'s mekanisme for partprogrammer til indlæsning, så dokumentationen om partprogrammer på <ulink url="http://developer.kde.org"
>Relevante deklarationsfiler skal enten være installeret med selve &chalk; af din distribution, eller også er deklarationsfilerne måske enten lagt i pakken &koffice;-dev eller i &chalk;-dev. Du finder dokumentationen af &chalk;s eksterne programmeringsgrænseflade på <ulink url="http://koffice.org/developer/apidocs/chalk/html/"
>-fil. Den nemmeste måde at komme i gang er at tjekke projektet chalk-plugins ud fra &koffice; Subversion-arkiv og bruge det som basis for dit eget projekt. Vi har til hensigt at oprette en pakke med en &chalk; pluginskabeloner for Kdevelop, men har ikke fået tid til at gøre det endnu. </para>
> Dette er byggefilen for et filter-plugin. Erstat <replaceable
>BIBLIOTEKSNAVN</replaceable
> med navnet på dit arbejde, så er du klar. </para
><para
>Hvis dit plugin er et visningsplugin, installerer du formodentlig også en <literal role="extension"
>.rc</literal
>-fil med indgange for menulinjer og værktøjslinjer. På lignende måde skal du måske også installere markører og ikoner. Alt dette gøres via de magiske besværgelser i &kde;'s sædvanlige <filename
>Import- og eksportfiltre for filer bruger det generelle filterskelet i &koffice; og må beskrives separat. </para>
</sect4>
<sect4 id="d-p-c-a-boilerplate">
<title
>Standardkode</title>
<para
>Du behøver også en del standardkode som kaldes af &kde;'s skelet for partprogrammer for at instantiere pluginnet — en deklarationsfil og en implementeringsfil. </para
KisToolRegistry * r = dynamic_cast<KisToolRegistry*>( parent );
r -> add(new KisToolStarFactory());
}
}
ToolStar::~ToolStar()
{
}
#include "tool_star.moc"
</programlisting>
</para>
</sect4>
<sect4 id="d-p-c-a-registries">
<title
>Registre</title>
<para
>Værktøjer indlæses af værktøjsregistret og registrerer sig selv med værktøjsregistret. Plugin såsom værktøjer, filtre og maleoperationer indlæses kun en gang. Visningsplugin indlæses for hver visning som skabes. Bemærk at vi registrerer fabriker generelt sagt. For værktøjer skabes eksempelvis en ny instans af et værktøj for hver peger (mus, pen, viskelæder), og en ny maleoperation skabes så snart et værktøj får begivenheden museklik. </para>
>Husk at dette betyder at et visningsplugin skabes for hver visning som brugeren laver: at opdele en visning betyder at alle visningsplugin indlæses igen. </para>
>-filen. &chalk; 1.6 kommer formodentlig ikke til at være binært kompatibel med 1.5 plugin og vil behøve versionsnumret 3. &chalk; 2.0 plugin kommer til at behøve versionsnumret 3. Ja, det er ikke helt logisk. </para>
>Det er ganske enkelt at implementere et farverum. Det generelle princip er at farverum arbejder med et enkelt felt af byte. Tolkningen af disse bestemmes af farverummet selv. For eksempel består et billedpunkt i 16-bit GrayA af fire byte: to for gråskalaværdien og to for alfaværdien. Du er fri til at bruge en struct til at arbejde med hukommelseslayouten af et billedpunkt i din implementering af farverum, men den repræsentationen eksporteres ikke. Den eneste måde som resten af &chalk; kan vide hvilke kanaler og typer af kanaler din farverums billedpunkter består af er via klassen <classname
>Denne klasse definerer kanalerne som udgør et enkelt billedpunkt i et bestemt farverum. En kanal har følgende vigtige egenskaber: </para>
<itemizedlist>
<listitem
><para
>et navn på en skærm i brugergrænsefladen</para
></listitem>
<listitem
><para
>en position: den byte hvor alle de byte som repræsenterer kanalen begynder i billedpunktet.</para
></listitem>
<listitem
><para
>en type: farve, alfa, substans eller substrat. Farve er sædvanlig farve, alfa er gennemsigtighed, substans er en repræsentation af mængden af pigment eller lignende ting, substrat er en repræsentation af kanvassen. (Bemærk at dette kan ændres meget hurtigt hvis det ønskes.)</para
></listitem>
<listitem
><para
>en værditype: byte, short, integer, float — eller noget andet.</para
>Et farverumsplugin kan understøtte en hvilken som helst delmængde af de mulige sammensætningsoperationer, men sættet skal altid omfatte "OVER" (samme som "NORMAL") og "COPY". De øvrige er mere eller mindre valgfrie, selvom flere naturligvis er bedre. </para>
>), og helst også til og fra 16-bit L*a*b*. Desuden er der en metode til at konvertere til et hvilket som helst andet farverum fra det nuværende farverum. </para
><para
>Farverum beskrives af vektoren <classname
>KisChannelInfo</classname
>, antal kanaler, antal byte i et enkelt billedpunkt, om det understøtter billeder med stort dynamisk område, med mere. </para
><para
>Behandling er for eksempel at kombinere to billedpunkter til et nyt billedpunkt: bitBlt, at gøre billedpunkter mørkere eller foldning af billedpunkter. </para
><para
>Kig i dokumentationen af programmeringsgrænsefladen for en fuldstændig beskrivelse af alle metoder du skal implementere i en farverum. </para
><para
><classname
>KisAbstractColorSpace</classname
> implementerer mange af de virtuelle metoder i <classname
>KisColorSpace</classname
> ved brug af funktioner fra biblioteket <command
>lcms</command
>. Ovenpå <classname
>KisAbstractColorSpace</classname
> er der basisklasser for farverum med 8- og 16-bit heltal samt 16- og 32-bit float som definerer fælles operationer for at flytte mellem bitdybder. </para>
>Filtre er plugin som undersøger billedpunkter i et lag og derefter udfører ændringer af dem. Selvom &chalk; bruger en effektiv hukommelsesgrænseflade baseret på tiles til at opbevare billedpunkter, skalforfattere af filtre ikke bekymre sig om det. Når et filterplugin skrives for billedbehandlingsgrænsefladen i &Java;, Photoshop eller Gimp skal man sørge for at tile-kanter og <quote
>Bemærk at det teoretisk er nemt at erstatte den nuværende grænseflade for dataopbevaring baseret på tiles med en andet grænseflade, men at denne grænseflade af ydelsesgrunde for øjeblikket ikke er rigtige plugin.</para
>&chalk; bruger interatorer til at læse og skrive billedpunktværdier. Alternativt kan du indlæse en blok med billedpunkter i en hukommelsesbuffer, arbejde med den og derefter skrive den tilbage som en blok. Dette er dog ikke nødvendigvis effektivere, men kan til og med være langsommere end at bruge iteration: det er måske blot bekvemmere. Se dokumentationen af programmeringsgrænsefladen. </para
>Billeder i &chalk; består af lag, hvoraf der for øjeblikket findes fire slags: malelag, gruppelag, justeringslag (som indeholder et filter som dynamisk bruges for lag under justeringslaget) og part-lag. Filtre arbejder altid med malelag. Malelag indeholder maleenheder af klassen <classname
>. En maleenhed giver på sin side mulighed for at få adgang til selve billedpunkterne. </para
><para
>En <classname
>PaintDevice</classname
> sendes generelt rundt indlejret i en delt peger. En delt peger holder styr på hvor mange steder som maleenheden for øjeblikket bruges, og fjerner maleenheden når den ikke længere bruges nogen steder. Du genkender versionen af en maleenhed med en delt peger på dens suffix <literal
>SP</literal
>. Husk blot at du aldrig eksplicit behøver at fjerne en <classname
>KisPaintDeviceSP</classname
>. </para
><para
>Lad os undersøge et meget enkelt filter, et som inverterer alle billedpunkter. Koden for filtret findes i mappen <filename class="directory"
> Funktionen modtager to maleenheder, et indstillingsobjekt (som ikke bruges i dette enkle filter) og en <varname
>rect</varname
>. Denne <varname
>rect</varname
> beskriver maleenhedens område som filtret skal håndtere. Området beskrives med heltal, hvilket betyder at der ikke findes nogen nøjagtighed på delbilledpunktsniveau. </para
><para
>Maleenheden <varname
>src</varname
> er til for at læse fra, og maleenheden <varname
>dst</varname
> er til for at skrive til. Disse parametre kan pege på samme egentlige maleenhed, eller være to forskellige maleenheder. (Bemærk: dette vil måske blive ændret til en enkelt maleenhed i fremtiden.) </para
><para
>Lad os nu betragte koden linje for linje: </para>
>Dette laver en iterator til at læse eksisterende billedpunkter. Chalk har tre typer af iteration: vandret, lodret og rektangulær. Iterationen rect går den effektiveste vej gennem billeddata, men garanterer ikke noget om stedet for næste billedpunkt den returnerer. Det betyder at du ikke kan være sikker på at billedpunkter du henter næste gang ligger ved siden af de billedpunkter du netop modtot. De vandrette og lodrette iterationer garanterer virkelig stedet for de billedpunkter de returnerer. </para
>Vi laver destinationsiteratoren med værdien <literal
>true</literal
> for indstillingen <literal
>write</literal
>. Det betyder at hvis destinationens malesenhed er mindre end rektanglen vi skriver, forstørres den automatisk til at omfatte alle billedpunkter i iterationen. Bemærk at vi har et potentiel fejl her: hvis <varname
>dst</varname
> og <varname
>src</varname
> ikke er samme enhed er det meget muligt at billedpunkterne som iteratorerne returnerer ikke svarer til hinanden. For hver position i iteratoren kan <varname
>src</varname
> for eksempel være 165, 200, mens <varname
>dst</varname
> ville kunne være 20, 8 — og derfor vil kopien vi laver nedenfor kunne forvrænge billedet ... </para
></callout>
<callout arearefs="invert3"
><para
>Vil du vide om et billedpunkt er markeret? Det er nemt: brug metoden <methodname
>isSelected</methodname
>. Men at være markeret er ikke en binær egenskab for et billedpunkt. Et billedpunkt kan være halvmarkeret, næsten umarkeret, eller næsten helt markeret. Markeringer er i virkeligheden en maskemaleenhed med området 0 til 255, hvor 0 er helt umarkeret og 255 helt markeret. Iteratoren har to metoder: <methodname
>isSelected()</methodname
> og <methodname
>selectedNess()</methodname
>. Den første returnerer sand hvis et billedpunkt overhovedet er markeret (dvs. maskeværdien er større end 1), den anden returnerer maskeværdien. </para
></callout>
<callout arearefs="invert4"
><para
>Som nævnt ovenfor, er denne <literal
>memcpy</literal
> et stor grim fejl ... <methodname
>rawData()</methodname
> returnerer bytefeltet som er billedpunktets nuværende tilstand og <methodname
>oldRawData()</methodname
> returnerer bytefeltet som det var inden vi oprettete iteratoren. Vi kan imidlertid kopiere et forkert billedpunkt her. I praksis sker dette ikke alt for ofte, hvis ikke <varname
>dst</varname
> allerede findes og ikke er justeret i forhold til <varname
>src</varname
>. </para
></callout>
<callout arearefs="invert5"
><para
>Men dette er rigtigt: I stedet for at regne ud hvilken byte som repræsenterer hvilken kanal, bruger vi en funktion som der sørges for af alle farverum til at invertere det nuværende billedpunkt. Farverum har en mængde billedpunktsoperationer som du kan udnytte. </para
></callout>
</calloutlist>
<para
>Dette er ikke alt som behøves for at oprette et filter. Filtre har to andre vigtige komponenter: et indstillingsobjekt og en grafisk indstillingskontrol. De to fungerer tæt sammen. Den grafiske indstillingskomponenten laver et indstillingsobjekt, men kan også udfyldes fra et indstillingsobjekt som allerede eksisterer. Indstillingsobjekter kan repræsenteres som XML, og kan skabes fra XML. Det er det som gør justeringslag mulige. </para>
<sect3 id="developers-plugins-filters-iterators">
<title
>Iteratorer</title>
<para
>Der er tre typer af iteratorer: </para>
<itemizedlist>
<listitem
><para
>Vandrette linjer</para
></listitem>
<listitem
><para
>Lodrette linjer</para
></listitem>
<listitem
><para
>Rektangulære iteratorer</para
></listitem>
</itemizedlist>
<para
>De vandrette og lodrette linjeiteratorer har en metode til at flytte iteratoren til næste linje eller søjle: <methodname
>nextRow()</methodname
> og <methodname
>nextCol()</methodname
>. At bruge dem er meget hurtigere end at oprette en ny iterator for hver linje eller søjle. </para
>Iteratorer er trådsikre i &chalk;, så det er muligt at opdele arbejdet i flere tråde. Dog kommer fremtidige versioner af &chalk; til at bruge metoden <methodname
> til at afgøre om filtret kan bruges på stumper af billedet (dvs. alle billedpunkter ændrede uafhængig af hinanden, i stedet for ændrede af en værdi som bestemmes af at undersøge alle billedpunkter i billedet) og automatisk bruge tråde til at køre dit filter. </para>
> er en struktur som bruges til at gemme filterindstillinger på disken, for eksempel for justeringslag. Scriptpluginnet bruger egenskabsafbildningen som findes længst tilbage i <classname
> for at gøre det muligt at lave scripter med filtre. Filtre kan sørge for en egen grafisk kontrol som &chalk; viser i filtergalleriet, forhåndsvisningen af filtre og fanebladet med værktøjstilvalg for værktøjet Mal med filtre. </para>
>Bemærk at kun venstresiden af dialogen er dit ansvar: &chalk; sørger for resten. Der er tre måder at opføre sig på for at oprette en tilvalgskontrol: </para>
>Brug &Qt; Designer til at oprette basen for den grafiske kontrol, og opret en delklasse for dit filter</para
></listitem>
<listitem
><para
>Brug en af de simple grafiske kontroller som viser et antal skydere for lister af heltal, decimaltal med dobbelt præcision eller Booleske værdier. Se dokumentationen af programmeringsgrænsefladen for <classname
>Håndkod en grafisk kontrol. Dette anbefales ikke, og hvis du gør det og ønsker at filtret skal være en del af &chalk;s officielle udgave, vil jeg bede dig om at erstatte din håndkodede kontrol med en &Qt; Designer-kontrol.</para
>Der kræves naturligvis mere for at kode interessante filtre, men med denne forklaring, dokumentationen af programmeringsgrænsefladen og adgang til vor kildekode, bør du kunne komme i gang. Tøv ikke med at kontakte udviklerne af &chalk; på IRC eller via e-mail-listen. </para>
>Værktøjer vises i &chalk;s værktøjskasse. Det betyder at der er begrænset plads til nye værktøjer: tænk nøje over om en maleoperation ikke er tilstrækkeligt til dit formål. Værktøjer kan bruge musen eller styrepladen og tastaturet på komplekse måder, hvilket maleoperationer ikke kan. Dette er grunden til at Duplikere er et værktøj, mens retuschsprøjte er en maleoperation. </para
>Vær forsigtig med statisk data i værktøjet: en ny instans af værktøjet oprettes for hver inddataenhed: mus, pen, viskelæder, retuschsprøjte med mere. Værktøjer er opdelt i logiske grupper: </para>
>Et værktøj har en grafisk indstillingskontrol, præcis som filtre. For øjeblikket vises de grafiske indstillingskontroller i et faneblad i et dokket vindue. Det kan komme til at blive ændret til en linje under hovedmenuen (som så erstatter værktøjslinjen) for &chalk; 2.0, men for øjeblikket skal indstillingskontroller konstrueres for at få plads i et faneblad. Som altid er det bedst at bruge &Qt; Designer til konstruktion af indstillingskontrollen. </para
>Konstruktoren laver det interne navn, som ikke oversættes, og kaldet til superklassen angiver det synlige navn. Vi indlæser også markørbilledet og tildeler værdier til et antal variabler. </para>
>) kaldes af &chalk; når indtastningsenheden (mus, pen, viskelæder, osv.) trykkes ned, flyttes eller slippes. Bemærk at forflytningsbegivenheder også afgives hvis museknappen ikke er trykket ned. Begivenhederne er ikke de sædvanlige &Qt;-begivenheder, men syntetiske begivenheder i &chalk;, eftersom vi drager nytte af trick på lavt niveau for at få tilstrækkeligt med begivenheder til at tegne en glat linje. Normalt smider værktøjskasser såsom &Qt; (og GTK) begivenheder væk hvis de er for travle til at håndtere dem, og vi vil have dem alle. </para>
> er fundamental: Her laver vi handlingen som vil blive puttet ind i værktøjskassen så brugere virkelig kan vælge værktøjet. Vi tildeler også en genvejstast. Bemærk at en del programkneb bruges her. Husk at vi oprettede en instans af værktøjet for hver indtastningsenhed. Det betyder også at vi kalder <methodname
>setup()</methodname
> for hver indtastningsenhed og at en handling med samme navn lægges til flere gange i handlingssamlingen. Men alt synes at virke, så hvorfor bekymre sig? </para>
> kaldes for at oprette den grafiske indstillingskontrol som &chalk; viser fanebladet. Eftersom der er et værktøj per indtastningsenhed og per visning, kan tilstanden af et værktøj opbevares i værktøjet. Denne metode kaldes kun en gang: den grafiske indstillingskontrol opbevares og hentes næste gang værktøjet aktiveres. </para>
>Maleoperationer er en af de mest opfindsomme typer af plugin i Chalk (sammen med farverum som kan bruges som plugin). En maleoperation definerer hvordan værktøj ændrer de billedpunkter de berører. Retuschsprøjte, pen uden antialias eller billedpunktpensel med antialias er alle maleoperationer. Men du skulle kunne, med en stor mængde arbejde, oprette en maleoperation som læser Corel Paint XML-penseldefinitioner og bruger dem til at bestemme hvordan man skal male </para
>Maleoperationer instantieres når et maleværktøj modtager begivenheden <literal
>mouseDown</literal
> og fjernes når begivenheden mouseUp modtages af et maleværktøj. I mellemtiden kan maleoperationen holde styr på tidligere positioner og anden information, såsom trykniveauer hvis brugeren bruger en styreplade. </para
><para
>Den grundlæggende handling for en maleoperation er at ændre billedpunkter ved et maleværktøjs markørposition. Det kan kun gøres en gang, eller også kan maleoperationen bede om at blive udført med regelmæssige intervaller, ved brug af en tidsmåler. Det første tilfælde er nyttigt for en penlignende maleoperation, og det andet naturligvis for en maleoperation som ligner en retuschsprøjte. </para
>Maleoperationer kan have en lille grafisk indstillingskontrol som placeres i en værktøjslinje. Altså skal grafiske indstillingskontroller for maleoperationer have en vandret layout som ikke er højere end en knap i en værktøjslinje, ellers ville &chalk; se meget mærkeligt ud. </para
>Lad os kigge på et enkelt plugin for en maleoperation,, et som viser en vis mængde programbaseret intelligens. For det første er der en fabrik defineret i deklarationsfilen. Denne fabrik laver en maleoperation når det aktive værktøj behøver en: </para>
> med det offentlige og private navn på maleoperationen, og kan valgfrtt returnere en punktafbildning. &chalk; kan derefter vise punktafbildningen sammen med navnet som en visuel identifikation af maleoperationen. For eksempel vil maleoperationen malerkniv have et billede af et sådant værktøj. Sørg for at maleoperationens private navn ikke kommer i konflikt med en anden maleoperation. </para
> er stedet hvor alt sker for maleoperationer. Denne metode har to parametre, den nuværende position (som angives i floats, ikke i hele billedpunkter) og objektet <classname
>KisPaintInformation</classname
>, som indeholder tryk, x, y, hældning og forflytningsvektor, og som kan udvides med yderligere information i fremtiden. </para>
<programlisting
>if (!m_painter->device()) return;
KisBrush *brush = m_painter->brush();
</programlisting>
<para
>En <classname
>KisBrush</classname
> er repræsentationen af en Gimp penselfil: det vil sige en maske, enten en enkelt maske eller en serie masker. I virkeligheden bruger vi ikke penslen her, men til at bestemme <quote
>Vi ændrer ikke billedpunkterne på en maleenheden direkte: i stedet laver vi en lille maleenhed, en dab, og sammensætter den med den nuværende maleenhed. </para>
<programlisting
>m_painter->setPressure(info.pressure);
</programlisting>
<para
>I overensstemmelse med kommentarerne, udfører følgende kodestump lidt programarbejde for at oprette selve dabben. I dette tilfælde tegner vi et antal linjer. Når maleoperationen er færdig, kommer linjernes længde, position og tykhed til at afhænge af tryk og farvemængde, og vi har oprettet en stiv, smidig oljefarvepensel. Men jeg har ikke haft tid at afslutte dette endnu. </para>
<programlisting
>// Compute the position of the tufts. The tufts are arranged in a line
// perpendicular to the motion of the brush, i.e, the straight line between
// the current position and the previous position.
for (int i = 0; i < (NUMBER_OF_TUFTS / 2); ++i) {
// Compute the positions on the new vector.
vl = currentPointVector + i * brushVector;
KisPoint pl = vl.toKisPoint();
dab->setPixel(pl.roundX(), pl.roundY(), kc);
vr = currentPointVector - i * brushVector;
KisPoint pr = vr.toKisPoint();
dab->setPixel(pr.roundX(), pr.roundY(), kc);
}
vr = vr - vl;
vr.normalize();
</programlisting>
<para
>Tilsidst overfører vi dabben med en blokoverførsel på den oprindelige maleenhed og fortæller maleren at vi har påvirket et lille rektangel på maleenheden. </para>
<programlisting
>if (m_source->hasSelection()) {
m_painter->bltSelection(x - 32, y - 32, m_painter->compositeOp(), dab.data(),
m_source->selection(), m_painter->opacity(), x - 32, y -32, 64, 64);
}
else {
m_painter->bitBlt(x - 32, y - 32, m_painter->compositeOp(), dab.data(), m_painter->opacity(), x - 32, y -32, 64, 64);
}
m_painter->addDirtyRect(QRect(x -32, y -32, 64, 64));
>Det er alt: maleoperationer er nemme og sjove! </para>
</sect2>
<sect2 id="developers-plugins-viewplugins">
<title
>Visningsplugin</title>
<para
>Visningsplugin er de mærkeligste i hele gænget: Et visningsplugin er en sædvanlig KPart som kan sørge for en vss mængde brugergrænseflade og en del funktioner. Histogramfanebladet er for eksempel et visningsplugin, ligesom rotationsdialogen. </para>
>&chalk; arbejder med den sædvanlige filterarkitektur for filer i &koffice;. Der findes en vejledning, noget gammel, men stadigvæk nyttig, på: <ulink url="http://koffice.org/developer/filters/oldfaq.php"
>. Det er sandsynligvis bedst at samarbejde med &chalk;-gruppen ved udvikling af filfiltere og at gøre udviklingen i &koffice; filtertræ. Bemærk at du kan teste filtre uden at køre &chalk; ved at bruge værktøjet <command
>Bemærk: Vi burde virkelig finde en måde at gøre det muligt for &chalk; at holde en fil åben kun læse data efterhånden som det behøves, i stedet for at kopiere hele indholdet til den interne repræsentationen i maleenheden. Men det ville betyde en grænseflade for datahåndtering som kender til TIFF-filer og så videre, og dette er for øjeblikket ikke implementeret. Det ville være ideelt hvis visse filfiltre kunne implementere en klasse, preliminært kaldet <classname
>, oprette et objekt af den instans med den nuværende fil og sende den til KisDoc. Men &chalk; håndterer opbevaring per lag, ikke per dokument, så det ville være en svær omskrivning.</para
>, eftersom &chalk;-dokumenter kræver særlig behandling. Det ville i virkeligheden ikke være en dum idé at kontrollere at resultatet af typekonverteringen ikke er 0, eftersom hvis den er det vil importen mislykkes.</para
>Hvis vi kalder filtret fra den grafiske grænseflade, forsøger vi at få visningen. Hvis der er en visning, kan konverteringskoden forsøge at opdatere fremgangslinjen.</para
></callout>
<callout arearefs="import4"
><para
>Filtret har filnavnet på inddatafilen for os.</para
></callout>
<callout arearefs="import5"
><para
><classname
>KisDoc</classname
> skal forberedes for import. Visse indstillinger initieres og fortryd deaktiveres. Ellers ville du kunne fortryde tilføjelse af lag som udføres af importfiltret, og det er en mærkelig opførsel.</para
></callout>
<callout arearefs="import6"
><para
>Jeg har valgt at implementere selve importkoden i en separat klasse som jeg instantierer her. Du kan også lægge al din kode direkte i denne metode, men det ville være lidt rodet.</para
></callout>
<callout arearefs="import7"
><para
>Min importkode returnerer en statuskode, som jeg siden kan bruge til at angive status for importfiltret. &koffice; sørger for at vise fejlmeddelelser.</para
></callout>
<callout arearefs="import8"
><para
>Hvis det er lykkedes at oprette <classname
>KisImage</classname
> sætter vi dokumentets nuværende billede til vort nyoprettede billede. Derefter er vi færdige: <literal
