diff options
Diffstat (limited to 'tde-i18n-it/docs/kdemultimedia/artsbuilder/helping.docbook')
| -rw-r--r-- | tde-i18n-it/docs/kdemultimedia/artsbuilder/helping.docbook | 237 |
1 files changed, 237 insertions, 0 deletions
diff --git a/tde-i18n-it/docs/kdemultimedia/artsbuilder/helping.docbook b/tde-i18n-it/docs/kdemultimedia/artsbuilder/helping.docbook new file mode 100644 index 00000000000..9c7940a9a79 --- /dev/null +++ b/tde-i18n-it/docs/kdemultimedia/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 +>_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_impl</classname +>, come <classname +>SoundServer_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<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> |