summaryrefslogtreecommitdiffstats
path: root/tde-i18n-sv/docs/tdemultimedia/artsbuilder/helping.docbook
blob: a02e0e26794cc721c42256a7f13107d9a6983506 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
<!-- <?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
>Att bidra till &arts;</title>

<sect1 id="how-to-help">
<title
>Hur du kan hjälpa till</title>

<para
>&arts;-projektet behöver hjälp från utvecklare att att lägga till stöd för &arts; i befintliga multimediaprogram, skriva nya multimediaprogram och förbättra &arts; möjligheter. Du behöver dock inte vara en utvecklare för att bidra. Vi behöver också hjälp från testare för att skicka in felrapporter, översättare för att översätta programtexten och dokumentationen till andra språk, grafiker för att skapa ikoner (särskilt för <application
>artsbuilder</application
> moduler), musiker för att skapa &arts;-modulexempel, och författare för att skriva eller granska dokumentation. </para>
</sect1>

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

<para
>De flesta utvecklingsdiskussioner om &arts; äger rum via två e-postlistor. Det här är stället att diskutera nya funktioner och implementeringsidéer och att fråga efter hjälp med problem. </para>

<para
>&kde;:s multimedia e-postlista är till för generella &kde; multimediafrågor inklusive &arts; samt multimediaprogram som &noatun; och &aktion;. Du kan prenumerera från webbsidan på <ulink url="http://www.kde.org/mailinglists.html"
> http://www.kde.org/mailinglists.html</ulink
> eller skicka e-post med rubriken <userinput
>subscribe <replaceable
>din-e-postadress</replaceable
></userinput
> till <email
>[email protected]</email
>. Listan finns också arkiverad på <ulink url="http://lists.kde.org"
> http://lists.kde.org</ulink
>. </para>

<para
>E-postlistan för &arts; är till för frågor som enbart rör &arts;, inklusive användning av &arts; utanför &kde;. För att prenumerera, skicka e-post till <email
>[email protected]</email
> med meddelandetexten <userinput
>subscribe <replaceable
>din-epostadress</replaceable
></userinput
>. Listan arkiveras 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
>För att åstadkomma en konsekvent läsning av all källkod, är det viktigt att hålla kodningsstilen likadan i hela &arts; källkod. Var snäll och försök skriva/formattera din källkod i enlighet med detta, även om du bara skriver en modul, eftersom det gör det enklare för olika personer att underhålla källkodsträdet, och lättare att kopiera delar av källkoden från en fil till en annan. </para>

<variablelist>
<varlistentry>
<term
>Namngivning av medlemsfunktioner</term>
<listitem>
<para
>&Qt;/&Java;-stil. Det här betyder att stora bokstäver används för att markera nya ord, och att första bokstaven alltid är liten. Inga understreck. </para>
<para
>Det här betyder till exempel:</para>

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

</listitem>
</varlistentry>

<varlistentry>
<term
>Klassmedlemmar</term>
<listitem>
<para
>Klassmedlemmar har inte stora bokstäver, som till exempel menubar eller button. </para>

<para
>När det finns funktioner som används för åtkomst, ska standarden som används vara enligt &MCOP;-sättet, dvs. om det finns en "long" medlem <function
>foo</function
>, som inte ska vara synlig, så skapas: </para>

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

<para
>funktioner för att hämta eller sätta ett värde. I detta fall, ska det riktiga värdet för <function
>foo</function
> lagras i <returnvalue
>&lowbar;foo</returnvalue
>. </para>
</listitem>
</varlistentry>

<varlistentry>
<term
>Klassnamn</term>
<listitem>
<para
>Alla klasser ska ha stora bokstäver för varje ord, vilket betyder <classname
>ModuleView</classname
>, <classname
>SynthModule</classname
>. Alla klasser som hör till biblioteken ska använda &arts;-namnrymden, som <classname
>Arts::Soundserver</classname
>. </para>
<para
>Implementeringar av &MCOP;-klasser ska döpas <classname
>Class&lowbar;impl</classname
>, som till exempel <classname
>SoundServer&lowbar;impl</classname
>. </para>
</listitem>
</varlistentry>

<varlistentry>
<term
>Parametrar</term>
<listitem>
<para
>Parametrar har alltid små bokstäver. </para>
</listitem>
</varlistentry>

<varlistentry>
<term
>Lokala variabler</term>
<listitem>
<para
>Lokala variabler har alltid små bokstäver, och kan ha namn som <varname
>i</varname
>, <varname
>p</varname
>, <varname
>x</varname
> etc. om det passar. </para>
</listitem>
</varlistentry>

<varlistentry>
<term
>Tabulatorbredd (skiftbredd)</term>
<listitem>
<para
>Ett tabulatortecken är lika mycket som fyra blanktecken. </para>
</listitem>
</varlistentry>

<varlistentry>
<term
>Mellanslag i uttryck</term>
<listitem>
<para
>Normalt behöver du inte använda mellanslag i uttryck. Du kan i alla fall använda dem mellan operatorer och deras operander. Om du skriver ett mellanslag före en operator (t.ex. +), måste du också skriva ett mellanslag efter operatorn. Det enda undantaget från detta är uttryck som liknar listor (med ,), där du bara ska använda ett mellanslag efter ",", men inte före. Det är också ok att utelämna mellanslag här. </para>
<para
>Följande exempel demonstrerar bra användning av mellanslag: </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öljande exempel demonstrerar hur man <emphasis
>inte</emphasis
> ska använda mellanslag. För funktionsanrop, efter if, while, for, switch och så vidare, skrivs inget mellanslag. </para>
<programlisting
>{
    // DÅLIGT: Om du skriver en lista, skriv bara mellanslag efter ","
    int a , b , c , d , e , f;

    // DÅLIGT: inte symmetrisk användning av mellanslag för = operatorn
    a= 5;

    // DÅLIGT: Om det anses vara en funktion, och inte följs av ett mellanslag
    if (a == 5) {   
    }

    // DÅLIGT: skriv inte ett mellanslag efter while
    while (a--)
        b++; 

    // DÅLIGT: Funktionsnamn följs inte av ett mellanslag
    arts_debug ("%d\n", c);

    // DÅLIGT: inte heller medlemsnamn
    Arts::Object o = Arts::Object::null ();
}
</programlisting>
</listitem>
</varlistentry>


<varlistentry>
<term
>Namngivning av källkodsfiler</term>
<listitem>
<para
>Källkodsfiler ska inte ha några stora bokstäver i namnet. De ska ha samma namn som klassen om de implementerar en enda klass. Deras filändelse ska vara <literal role="extension"
>.cc</literal
> om de innehåller &Qt;- och grafikoberoende kod, och <literal role="extension"
>.cpp</literal
> om de innehåller &Qt;- och grafikberoende kod. Implementeringsfiler för gränssnitt ska benämnas <filename
><replaceable
>foo</replaceable
>_impl</filename
>, om Foo är gränssnittets namn. </para>

<para
>&IDL;-filer ska benämnas på ett beskrivande sätt med tanke på den samling gränssnitt de innehåller, också helt med små bokstäver. I synnerhet är det inte bra att benämna en &IDL;-fil som klassen själv, eftersom .mcopclass-handlaren och typinfoposterna då kommer att kollidera. </para>
</listitem>
</varlistentry>
</variablelist>
</sect1>

</chapter>