diff options
author | Timothy Pearson <[email protected]> | 2011-12-03 11:05:10 -0600 |
---|---|---|
committer | Timothy Pearson <[email protected]> | 2011-12-03 11:05:10 -0600 |
commit | f7e7a923aca8be643f9ae6f7252f9fb27b3d2c3b (patch) | |
tree | 1f78ef53b206c6b4e4efc88c4849aa9f686a094d /tde-i18n-it/docs/kdemultimedia/artsbuilder/helping.docbook | |
parent | 85ca18776aa487b06b9d5ab7459b8f837ba637f3 (diff) | |
download | tde-i18n-f7e7a923aca8be643f9ae6f7252f9fb27b3d2c3b.tar.gz tde-i18n-f7e7a923aca8be643f9ae6f7252f9fb27b3d2c3b.zip |
Second part of prior commit
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, 0 insertions, 237 deletions
diff --git a/tde-i18n-it/docs/kdemultimedia/artsbuilder/helping.docbook b/tde-i18n-it/docs/kdemultimedia/artsbuilder/helping.docbook deleted file mode 100644 index 9c7940a9a79..00000000000 --- a/tde-i18n-it/docs/kdemultimedia/artsbuilder/helping.docbook +++ /dev/null @@ -1,237 +0,0 @@ -<!-- <?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 ->[email protected]</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 ->[email protected]</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> |