path: root/tde-i18n-da/docs/tdemultimedia/artsbuilder/helping.docbook

<!-- <?xml version="1.0" ?>
<!DOCTYPE chapter PUBLIC "-//KDE//DTD DocBook XML V4.2-Based Variant V1.1//EN" "dtd/kdex.dtd">
To validate or process this file as a standalone document, uncomment
this prolog. Be sure to comment it out again when you are done -->

<chapter id="contributing">
<title
>Hjælp til med &arts;</title>

<sect1 id="how-to-help">
<title
>Hvordan du kan hjælpe til</title>

<para
>&arts;-projektet behøver hjælp fra udviklere for at at tilføje understøttelse for &arts; i eksisterende multimedieprogrammer, skrive nye multimedieprogrammer og forbedre &arts;' muligheder. Du behøver dog ikke være en udvikler for at bidrage. Vi behøver også hjælp fra testere til at indsende fejlrapporter, oversættere til at oversætte programteksten og dokumentationen til andre sprog, grafikere til at oprette ikoner (især for <application
>artsbuilder</application
> moduler), musikere til at lave &arts;-moduleksempler, og forfattere til at skrive eller gennemse dokumentation. </para>
</sect1>

<sect1 id="mailing-lists">
<title
>E-mail-lister</title>

<para
>De fleste udviklingsdiskussioner om &arts; finder sted via to e-mail-lister. Dette er stedet at diskutere nye funktioner og implementeringsidéer og at spørge efter hjælp med problemer. </para>

<para
>&kde;'s multimedie e-mail-liste er til for generelle &kde; multimediespørgsmål inklusive &arts; samt multimedieprogrammer såsom &noatun; og &aktion;. Du kan abonnere fra netsiden på <ulink url="http://www.kde.org/mailinglists.html"
> http://www.kde.org/mailinglists.html</ulink
> eller sende e-mail med emnet <userinput
>subscribe <replaceable
>din-e-mail-adresse</replaceable
></userinput
> til <email
>[email protected]</email
>. Listen findes også arkiveret på <ulink url="http://lists.kde.org"
> http://lists.kde.org</ulink
>. </para>

<para
>E-mail-listen for &arts; er til for spørgsmål som kun berører &arts;, inklusive brug af &arts; udenfor &kde;. For at abonnere, send e-mail til <email
>[email protected]</email
> med meddelelsesteksten <userinput
>subscribe <replaceable
>din-epostadresse</replaceable
></userinput
>. Listen arkiveres på <ulink url="http://space.twc.de/~stefan/arts-archive"
> http://space.twc.de/~stefan/arts-archive</ulink
>. </para>

</sect1>

<sect1 id="coding-standards">
<title
>Kodningsstandarder</title>

<para
>For at opnå en konsekvent læsning af al kildekode, er det vigtigt at holde kodningsstilen ens i hele &arts;' kildekode. Vær derfor rar og forsøg at skrive/formatere din kildekode i overensstemmelse med dette, også selvom du kun skriver et modul, eftersom det gør det enklere for forskellige personer at vedligeholde kildekodetræet, og lettere at kopiere dele af kildekoden fra en fil til en anden. </para>

<variablelist>
<varlistentry>
<term
>Navngivning af medlemsfunktioner</term>
<listitem>
<para
>&Qt;/&Java;-stil. Dette betyder at store bogstaver bruges til at markere nye ord, og at det første bogstav altid er lille. Ingen understregninger. </para>
<para
>Dette betyder for eksempel:</para>

<programlisting
>createStructureDesc()
   updateWidget();
   start(); </programlisting>

</listitem>
</varlistentry>

<varlistentry>
<term
>Klassemedlemmer</term>
<listitem>
<para
>Klassemedlemmer har ikke store bogstaver, som for eksempel menubar eller button. </para>

<para
>Når der er funktioner som bruges til adgang, skal standarden som bruges være ifølge &MCOP;-måden, dvs. hvis der er et "long" medlem <function
>foo</function
>, som ikke skal være synlig, så laves: </para>

<programlisting
>foo(long new_value);
   long foo(); </programlisting>

<para
>funktioner for at hente eller sætte en værdi. I dette tilfælde, skal den rigtige værdi for <function
>foo</function
> opbevares i <returnvalue
>&lowbar;foo</returnvalue
>. </para>
</listitem>
</varlistentry>

<varlistentry>
<term
>Klassenavne</term>
<listitem>
<para
>Alle klasser skal have store bogstaver for hvert ord, hvilket betyder <classname
>ModuleView</classname
>, <classname
>SynthModule</classname
>. Alle klasser som hører til biblioteker skal bruge &arts;-navnerummet, såsom <classname
>Arts::Soundserver</classname
>. </para>
<para
>Implementeringer af &MCOP;-klasser skal døbes <classname
>Class&lowbar;impl</classname
>, som for eksempel <classname
>SoundServer&lowbar;impl</classname
>. </para>
</listitem>
</varlistentry>

<varlistentry>
<term
>Parametre</term>
<listitem>
<para
>Parametre har altid små bogstaver. </para>
</listitem>
</varlistentry>

<varlistentry>
<term
>Lokale variabler</term>
<listitem>
<para
>Lokale variabler har altid små bogstaver, og kan have navne såsom <varname
>i</varname
>, <varname
>p</varname
>, <varname
>x</varname
> osv. hvis det passer. </para>
</listitem>
</varlistentry>

<varlistentry>
<term
>Tabulatorbredde (skiftbredde)</term>
<listitem>
<para
>Et tabulatortegn er lige så meget som fire blanke tegn. </para>
</listitem>
</varlistentry>

<varlistentry>
<term
>Mellemrum i udtryk</term>
<listitem>
<para
>Normalt behøver du ikke bruge mellemrum i udtryk. Du kan i alle tilfælde bruge dem mellem operatorer og deres operander. Hvis du skriver et mellemrum før en operator (f.eks. +), skal du også skrive et mellemrum efter operatoren. Den eneste undtagelse fra dette er udtryk som ligner lister (med ,), hvor du kun skal bruge et mellemrum efter ",", men ikke før. Det er også i orden at udelade mellemrum her. </para>
<para
>Følgende eksempel demonstrerer god brug af mellemrum: </para>
<programlisting
>{
    int a,b;
    int c, d, e;
    int f = 4;

    a=b=c=d+e+f;
    a = b = c = d + e + f;

    if(a == 4) {
        a = b = c = (d+e)/2;
    }

    while(b&lt;3)
        c--;

    arts_debug("%d\n", c);
}
</programlisting>
<para
>Følgende eksempel demonstrerer hvordan man <emphasis
>ikke</emphasis
> skal bruge mellemrum. For funktionskald, efter if, while, for, switch og så videre, skrives intet mellemrum. </para>
<programlisting
>{
    // DÅRLIGT: Hvis du skriver en liste, skriv kun mellemrum efter ","
    int a , b , c , d , e , f;

    // DÅRLIGT: ikke symmetrisk brug af mellemrum for = operatoren
    a= 5;

    // DÅRLIGT: Hvis det anses at være en funktion, og ikke følges af et mellemrum
    if (a == 5) {   
    }

    // DÅRLIGT: skriv ikke et mellemrum efter while
    while (a--)
        b++; 

    // DÅRLIGT: Funktionsnavne følges ikke af et mellemrum
    arts_debug ("%d\n", c);

    // DÅRLIGT: heller ikke medlemsnavne
    Arts::Object o = Arts::Object::null ();
}
</programlisting>
</listitem>
</varlistentry>


<varlistentry>
<term
>Navngivning af kildekodefiler</term>
<listitem>
<para
>Kildekodefiler skal ikke have store bogstaver i navnet. De skal have samme navne som klassen hvis de implementerer en enkelt klasse. Deres filendelse skal være <literal role="extension"
>.cc</literal
> hvis de indeholder &Qt;- og grafikuafhængig kode, og <literal role="extension"
>.cpp</literal
> hvis de indeholder &Qt;- og grafikafhængig kode. Implementeringsfiler for grænseflader skal benævnes <filename
><replaceable
>foo</replaceable
>_impl</filename
>, hvis Foo er grænsefladens navn. </para>

<para
>&IDL;-filer skal benævnes på en beskrivende måde med tanke på den samling grænseflader de indeholder, også helt med små bogstaver. I særdeleshed er det ikke godt at benævne en &IDL;-fil som klassen selv, eftersom .mcopclass-handleren og typeinfoposterne så vil kollidere. </para>
</listitem>
</varlistentry>
</variablelist>
</sect1>

</chapter>