path: root/tde-i18n-fr/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
>Contribuer à &arts;</title>

<sect1 id="how-to-help">
<title
>Comment nous aider</title>

<para
>Le projet &arts; peut profiter de l'aide de développeurs pour rendre les applications multimédia existantes compatibles avec &arts;, pour écrire de nouvelles applications multimédia, et pour améliorer les fonctionnalités de &arts;. Cependant, vous pouvez contribuer sans être développeur. Nous avons besoin de l'aide de testeurs qui nous soumettent des rapports de bogue, de traducteurs pour l'application et la documentation dans d'autres langues, d'artistes pour réaliser les graphismes (particulièrement pour les modules de <application
>artsbuilder</application
>), de musiciens pour créer de nouveaux modules pour &arts;, et de rédacteurs pour écrire ou améliorer la documentation. </para>
</sect1>

<sect1 id="mailing-lists">
<title
>Listes de discussion</title>

<para
>Les discussions relatives au développement de &arts; ont lieu sur deux listes de discussions. Nous y parlons des nouvelles idées de caractéristiques et d'implantations, et nous y résolvons un certain nombre de problèmes. </para>

<para
>La liste de discussion &kde; Multimedia concerne les problèmes multimédia de &kde; en général, y compris &arts; et les applications multimédia comme &noatun; et &aktion;. Vous pouvez vous y inscrire depuis la page web à  <ulink url="http://www.kde.org/mailinglists.html"
>http://www.kde.org/mailinglists.html</ulink
> ou envoyer un message électronique dont le sujet est <userinput
>subscribe<replaceable
>votre adresse électronique</replaceable
></userinput
> à <email
>kde-multimedia-request@kde.org</email
>. Cette liste est aussi archivée à <ulink url="http://lists.kde.org"
>http://lists.kde.org</ulink
>. </para>

<para
>La liste de discussion de &arts; est spécifique à &arts;, y compris les utilisations de &arts; indépendamment de &kde;. Pour vous inscrire, envoyez un message électronique avec le message <userinput
>subscribe <replaceable
>votre adresse électronique</replaceable
></userinput
> à <email
>arts-request@space.twc.de</email
> La liste est archivée à <ulink url="http://space.twc.de/~stefan/arts-archive"
>http://space.twc.de/~stefan/arts-archive</ulink
>. </para>

</sect1>

<sect1 id="coding-standards">
<title
>Style de programmation</title>

<para
>Pour obtenir un code source homogène, il est important de garder un style de programmation dans tous les sources de &arts;. Même si vous écrivez simplement un module, essayez d'écrire et formater votre source en conséquence, de façon à faciliter le travail de différentes personnes dans la gestion des sources, et faciliter la copie de morceaux de codes d'un source vers un autre. </para>

<variablelist>
<varlistentry>
<term
>Nom des fonctions membres</term>
<listitem>
<para
>Style &Qt;/&Java;, ce qui signifie une majuscule au début de chaque mot, et la première lettre toujours en minuscule ; aucun caractère de soulignement. </para>
<para
>Ceci signifie par exemple :</para>

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

</listitem>
</varlistentry>

<varlistentry>
<term
>Membres de classes</term>
<listitem>
<para
>Les membres de classes s'écrivent en minuscule, comme par exemple menubar ou button. </para>

<para
>Lorsqu'il y a des fonctions d'accès, le standard devrait être celui de &MCOP;, c'est-à-dire lorsque vous avez un membre <function
>foo</function
> de type long, qui ne doit pas être visible directement, vous créez les fonctions : </para>

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

<para
>pour récupérer et envoyer les valeurs. Dans ce cas, la valeur réelle de <function
>foo</function
> devrait être stockée dans <returnvalue
>&lowbar;foo</returnvalue
>. </para>
</listitem>
</varlistentry>

<varlistentry>
<term
>Nom des classes</term>
<listitem>
<para
>Toutes les classes doivent s'écrire avec une majuscule au début de chaque mot, par exemple <classname
>ModuleView</classname
>, <classname
>SynthModule</classname
>. Les classes qui appartiennent aux librairies doivent utiliser les espaces de noms de &arts;, comme <classname
>Arts::Soundserver</classname
>. </para>
<para
>Les implantations des classes &MCOP; doivent être appelées <classname
>Class&lowbar;impl</classname
>, comme par exemple <classname
>SoundServer&lowbar;impl</classname
>. </para>
</listitem>
</varlistentry>

<varlistentry>
<term
>Paramètres</term>
<listitem>
<para
>Les paramètres sont toujours en minuscule. </para>
</listitem>
</varlistentry>

<varlistentry>
<term
>Variables locales</term>
<listitem>
<para
>Les variables locales sont toujours en minuscule, et ont des noms comme <varname
>i</varname
>, <varname
>p</varname
>, <varname
>x</varname
>, &etc; </para>
</listitem>
</varlistentry>

<varlistentry>
<term
>Largeur de tabulation (largeur du décalage)</term>
<listitem>
<para
>Une tabulation correspond à 4 espaces. </para>
</listitem>
</varlistentry>

<varlistentry>
<term
>Espaces dans les expressions</term>
<listitem>
<para
>Vous n'avez normalement pas à utiliser d'espaces dans les expressions. Vous pouvez cependant les utiliser entre les opérateurs et leurs opérandes. Si vous placez un espace avant un opérateur (&pex; +), vous devez alors en placer un après l'opérateur. La seule exception correspond aux expressions de type liste (avec une virgule), où ou ne devez placer un espace qu'après la virgule, mais pas avant. Vous pouvez également ommettre la virgule ici. </para>
<para
>Les exemples suivants montrent une bonne utilisation des espaces :  </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
>Les exemples suivants montrent comment <emphasis
>ne</emphasis
> <emphasis
>pas</emphasis
> utiliser les espaces. Pour les appels de fonction, après if, while, for, switch &etc;, on ne met pas d'espace. </para>
<programlisting
>{
    // MAUVAIS : si vous écrivez une liste, écrivez les espces uniquement après la virgule
    int a , b , c , d , e , f;

    // MAUVAIS : utilisation non symétrique des lesapces pour l'opérateur =
    a= 5;

    // MAUVAIS : si considéré comme fonction, et n'est pas suivi par un espace
    if (a == 5) {   
    }

    // MAUVAIS : n'écrivez pas d'espace après un while
    while (a--)
        b++; 

    // MAUVAIS : les noms de fonctions ne sont pas suivis par un espace
    arts_debug ("%d\n", c);

    // MAUVAIS : ni les noms de membres
    Arts::Object o = Arts::Object::null ();
}
</programlisting>
</listitem>
</varlistentry>


<varlistentry>
<term
>Noms des fichiers sources</term>
<listitem>
<para
>Les fichiers sources sont en minuscule. Ils doivent porter le nom de la classe lorsqu'ils implantent une classe unique. Leur extension est <literal role="extension"
>.cc</literal
> s'ils contiennent du code indépendant de &Qt;/&GUI;, et <literal role="extension"
>..cpp</literal
> s'ils contiennent du code dépendant de &Qt;/&GUI;. Les fichiers d'implantation pour les interfaces doivent être appelés <filename
><replaceable
>foo</replaceable
>_impl</filename
>, si Foo est le nom de l'interface. </para>

<para
>Les fichiers &IDL; doivent être appelés de manière descriptive pour l'ensemble des interfaces qu'ils contiennent, aussi tout en minuscule. En particulier, il est déconseillé de donner à un fichier &IDL; le nom de la classe elle-même, car le sélecteur de fichiers .mcopclass (.mcopclass trader) et les informations de type entreront en conflit. </para>
</listitem>
</varlistentry>
</variablelist>
</sect1>

</chapter>