summaryrefslogtreecommitdiffstats
path: root/tde-i18n-it/docs/tdemultimedia/artsbuilder/helping.docbook
diff options
context:
space:
mode:
authorTimothy Pearson <kb9vqf@pearsoncomputing.net>2011-12-03 11:05:10 -0600
committerTimothy Pearson <kb9vqf@pearsoncomputing.net>2011-12-03 11:05:10 -0600
commitf7e7a923aca8be643f9ae6f7252f9fb27b3d2c3b (patch)
tree1f78ef53b206c6b4e4efc88c4849aa9f686a094d /tde-i18n-it/docs/tdemultimedia/artsbuilder/helping.docbook
parent85ca18776aa487b06b9d5ab7459b8f837ba637f3 (diff)
downloadtde-i18n-f7e7a923aca8be643f9ae6f7252f9fb27b3d2c3b.tar.gz
tde-i18n-f7e7a923aca8be643f9ae6f7252f9fb27b3d2c3b.zip
Second part of prior commit
Diffstat (limited to 'tde-i18n-it/docs/tdemultimedia/artsbuilder/helping.docbook')
-rw-r--r--tde-i18n-it/docs/tdemultimedia/artsbuilder/helping.docbook237
1 files changed, 237 insertions, 0 deletions
diff --git a/tde-i18n-it/docs/tdemultimedia/artsbuilder/helping.docbook b/tde-i18n-it/docs/tdemultimedia/artsbuilder/helping.docbook
new file mode 100644
index 00000000000..9c7940a9a79
--- /dev/null
+++ b/tde-i18n-it/docs/tdemultimedia/artsbuilder/helping.docbook
@@ -0,0 +1,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
+>Contribuire a &arts;</title>
+
+<sect1 id="how-to-help">
+<title
+>Come puoi aiutare</title>
+
+<para
+>Il progetto &arts; può utilizzare aiuti da parte di programmatori per rendere le applicazioni multimediali esistenti compatibili con &arts;, per scrivere nuove applicazioni multimediali e per aumentare le capacità di &arts;. Comunque, non devi essere per forza uno sviluppatore per contribuire. Possiamo anche utilizzare l'aiuto da parte di collaudatori per segnalare bug, da parte di traduttori per tradurre il testo dell'applicazione e la documentazione in altre lingue, da parte di artisti per il disegno di bitmap (specialmente per i moduli di <application
+>artsbuilder</application
+>), da parte di musicisti per creare moduli &arts; di esempio, e da parte di scrittori per la scrittura e la rilettura della documentazione. </para>
+</sect1>
+
+<sect1 id="mailing-lists">
+<title
+>Mailing List</title>
+
+<para
+>La maggior parte delle discussioni sullo sviluppo di &arts; avvengono su due mailing list. Queste sono il posto per discutere nuove caratteristiche e idee di implementazione o per chiedere aiuto sui problemi. </para>
+
+<para
+>La mailing list &kde; Multimedia è per la discussione generale su &kde; Multimedia, compresi &arts; e le applicazioni multimediali come &noatun; e &aktion;. Puoi iscriverti dalla pagina web a <ulink url="http://www.kde.org/mailinglists.html"
+>http://www.kde.org/mailinglists.html</ulink
+>, o inviare una e-mail con oggetto <userinput
+>subscribe <replaceable
+>tuo indirizzo e-mail</replaceable
+></userinput
+> a <email
+>kde-multimedia-request@kde.org</email
+>. La lista viene inoltre archiviata a <ulink url="http://lists.kde.org"
+>http://lists.kde.org</ulink
+>. </para>
+
+<para
+>La mailing list &arts; riguarda gli argomenti specifici di &arts;, tra cui l'uso di &arts; fuori da &kde;. Per iscriverti, invia una e-mail contenente come corpo del messaggio <userinput
+>subscribe <replaceable
+>tuo indirizzo e-mail</replaceable
+></userinput
+> a <email
+>arts-request@space.twc.de</email
+>. La lista viene archiviata a <ulink url="http://space.twc.de/~stefan/arts-archive"
+>http://space.twc.de/~stefan/arts-archive</ulink
+>. </para>
+
+</sect1>
+
+<sect1 id="coding-standards">
+<title
+>Standard per il codice</title>
+
+<para
+>Per una lettura consistente tra tutti i sorgenti, è importante mantenere un unico stile di scrittura del codice per tutti i sorgenti di &arts;. Per favore, anche se scrivi solo un modulo, cerca di scrivere/formattare allo stesso modo il tuo codice, dato che questo renderà più semplice la manutenzione dell'albero dei sorgenti a persone diverse, e la copia di pezzi di un sorgente in un altro. </para>
+
+<variablelist>
+<varlistentry>
+<term
+>Nomi per le funzioni membro</term>
+<listitem>
+<para
+>Stile &Qt;/&Java;. Questo significa l'uso delle maiuscole come separazione delle parole e la prima lettera sempre minuscola; nessun underscore (_). </para>
+<para
+>Questo significa, per esempio:</para>
+
+<programlisting
+>createStructureDesc()
+ updateWidget();
+ start(); </programlisting>
+
+</listitem>
+</varlistentry>
+
+<varlistentry>
+<term
+>Classi membro</term>
+<listitem>
+<para
+>Le classi membro non hanno mai la maiuscola, come menubar o button. </para>
+
+<para
+>Quando ci sono funzioni di accesso, lo standard dovrebbe essere come &MCOP;, cioè, quando hai un membro lungo <function
+>foo</function
+>, che non dovrebbe essere visibile direttamente, crea: </para>
+
+<programlisting
+>foo(long new_value);
+ long foo(); </programlisting>
+
+<para
+>Funzioni che prelevano e impostano i valori. In questo caso, il valore reale di <function
+>foo</function
+> dovrebbe essere memorizzato in <returnvalue
+>&lowbar;foo</returnvalue
+>. </para>
+</listitem>
+</varlistentry>
+
+<varlistentry>
+<term
+>Nomi delle classi</term>
+<listitem>
+<para
+>Tutte le classi dovrebbero avere la maiuscola ad ogni inizio di parola, il che significa <classname
+>ModuleView</classname
+>, <classname
+>SynthModule</classname
+>. Tutte le classi che appartengono alle librerie dovrebbero utilizzare il namespace &arts;, come <classname
+>Arts::Soundserver</classname
+>. </para>
+<para
+>Le implementazioni delle classi &MCOP; dovrebbero essere chiamate <classname
+>Class&lowbar;impl</classname
+>, come <classname
+>SoundServer&lowbar;impl</classname
+>. </para>
+</listitem>
+</varlistentry>
+
+<varlistentry>
+<term
+>Parametri</term>
+<listitem>
+<para
+>I parametri non hanno mai la maiuscola. </para>
+</listitem>
+</varlistentry>
+
+<varlistentry>
+<term
+>Variabili locali</term>
+<listitem>
+<para
+>Le variabili locali non hanno mai la maiuscola, e possono avere nomi come <varname
+>i</varname
+>, <varname
+>p</varname
+>, <varname
+>x</varname
+>, &etc; dove appropriato. </para>
+</listitem>
+</varlistentry>
+
+<varlistentry>
+<term
+>Larghezza delle tabulazioni</term>
+<listitem>
+<para
+>Una tabulazione è lunga come 4 spazi. </para>
+</listitem>
+</varlistentry>
+
+<varlistentry>
+<term
+>Gli spazi nelle espressioni</term>
+<listitem>
+<para
+>Normalmente non hai bisogno di usare spazi nelle espressioni. Comunque puoi usarli tra gli operatori ed i lori operando. Comunque, se metti uno spazio prima di un operatore (ad esempio, +), devi metterne uno anche dopo di esso. L'unica eccezione a questo sono le espressioni simili a liste (con la ,), nelle quali dovresti mettere solo uno spazio dopo la ",", ma non prima. Va bene anche se ometti questi spazi comunque. </para>
+<para
+>I seguenti esempi mostrano l'utilizzo corretto degli spazi: </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
+>I seguenti esempi mostrano come gli spazi <emphasis
+>non</emphasis
+> vanno utilizzati. Per le chiamate di funzione, dopo if, while, for, switch, e così via, non ci vuole nessuno spazio. </para>
+<programlisting
+>{
+ // SBAGLIATO: se scrivi una lista, usa gli spazi solo dopo la ","
+ int a , b , c , d , e , f;
+
+ // SBAGLIATO: uso asimmetrico degli spazi per l'operatore =
+ a= 5;
+
+ // SBAGLIATO: if è considerato una funzione, e non viene seguito da uno spazio
+ if (a == 5) {
+ }
+
+ // SBAGLIATO: non usare uno spazio dopo while
+ while (a--)
+ b++;
+
+ // SBAGLIATO: i nomi delle funzioni non vengono seguiti da uno spazio
+ arts_debug ("%d\n", c);
+
+ // SBAGLIATO: nemmeno i nomi dei membri
+ Arts::Object o = Arts::Object::null ();
+}
+</programlisting>
+</listitem>
+</varlistentry>
+
+
+<varlistentry>
+<term
+>Nomi dei file sorgente</term>
+<listitem>
+<para
+>I file sorgente non dovrebbero avere nessuna maiuscola nel nome. Dovrebbero avere il nome della classe quando implementano una singola classe. La loro estensione è <literal role="extension"
+>.cc</literal
+> se si riferiscono a codice indipendente da &Qt;/&GUI;, e <literal role="extension"
+>.cpp</literal
+> se si riferiscono a codice dipendente da &Qt;/&GUI;. I file di implementazione per le interfacce dovrebbero essere chiamati <filename
+><replaceable
+>foo</replaceable
+></filename
+>, se Foo è il nome dell'interfaccia. </para>
+
+<para
+>I file &IDL; dovrebbero essere chiamati in un modo che descriva la raccolta di interfacce che contengono, sempre tutto in minuscolo. Specialmente non è una buona idea chiamare un file &IDL; come la classe, dato che il trader .mcopclass e le voci di informazione sui tipi colliderebbero, in questo caso. </para>
+</listitem>
+</varlistentry>
+</variablelist>
+</sect1>
+
+</chapter>