incubator-ooo-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From w...@apache.org
Subject svn commit: r1195287 [19/42] - in /incubator/ooo/ooo-site/trunk/content/fr: ./ CC/ Contribuer/ DicOOo/ DicOOo/hyph_fr/ DicOOo/spell_fr/ DicOOo/thes_fr/ Documentation/ Documentation/Exemples/ Documentation/Exercices/ Documentation/Gallery/ Documentation...
Date Mon, 31 Oct 2011 00:24:40 GMT
Added: incubator/ooo/ooo-site/trunk/content/fr/Laboratory/guide_hackers.html
URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/fr/Laboratory/guide_hackers.html?rev=1195287&view=auto
==============================================================================
--- incubator/ooo/ooo-site/trunk/content/fr/Laboratory/guide_hackers.html (added)
+++ incubator/ooo/ooo-site/trunk/content/fr/Laboratory/guide_hackers.html Mon Oct 31 00:18:42 2011
@@ -0,0 +1,929 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html>
+<head>
+  <title>Labo</title>
+  <meta http-equiv="content-type" content="text/html; charset=UTF-8">
+</head>
+<body>
+<table border="0" cellpadding="4" width="100%">
+  <tbody>
+    <tr>
+      <td align="left" valign="top" width="100%"><!-- Content -->
+      <h3><font face="Helvetica, Arial, sans-serif"><b><br>
+Guide du Hacker OpenOffice.org Non Officiel</b></font></h3>
+Compiler et hacker OpenOffice.org (OOo) vous fera gravir une pente
+assez longue. Heureusement, ce document rendra la courbe
+d'apprentissage un peu plus raide et abrupte et vous fournira un bâton
+de marche pour vous aider.<br>
+Ce document assume que vous utilisez un système Linux habituel pour une
+économie de temps. Les vrais hackers utilisent des <a
+ href="http://www.gnu.org/">logiciels Libres</a> et n'ont pas le temps
+de s'intéresser à du matériel non Libre.<br>
+Nous avons pour but de répondre au moins aux questions suivantes :<br>
+      <ul>
+        <li>Comment je compile OOo ?</li>
+        <li>Comment je viens à bout d'itération de développement</li>
+        <li>Comment je le débuggue</li>
+        <li>Comment j'envois un patch</li>
+      </ul>
+Si vous avez besoin d'aide pour la compilation de OOo et que vous avez
+l'intention de le hacker, merci rejoindre la liste <a
+ href="mailto:labo@fr.openoffice.org">ici</a> et d'y poser vos
+questions.<br>
+      <h3>O. Contenu</h3>
+      <ul>
+        <li><a href="#1._Obtenir_OOo">1. Obtenir OOo</a></li>
+        <li><a href="#2._Compiler_OOo">2. Compiler OOo</a></li>
+        <li><a href="#3._Installer_OOo">3. Installer OOo</a></li>
+        <li><a href="#4._Ex%C3%A9cuter_OOo">4. Exécuter OOo</a></li>
+        <li><a href="#5._Hacker_OOo">5. Hacker OOo</a></li>
+        <li><a href="#6._D%C3%A9bugguer_OOo">6. Débuguer OOo</a></li>
+        <li><a href="#7._Contribuer_des_patches">7. Contribuer des
+patches</a></li>
+        <li><a href="#8_Conseils_divers">8. Astuces générales</a></li>
+        <li><a href="#9._Liens_utiles">9. Liens utiles</a></li>
+        <li><a href="#10_FAQ_non_fr%C3%A9quentes">10. IFAQ</a></li>
+        <li>11. Travailler avec nous</li>
+      </ul>
+Ce processus est discuté en bien plus amples détails dans le <a
+ href="http://ooo.ximian.com/detailed-build-guide.html">guide détaillé
+de compilation</a>. Nous avons cependant travaillé dur pour rendre ce
+process réalisable pour les simples programmeurs mortels, et une simple
+description de ce qui suit.<br>
+      <h3><a name="1._Obtenir_OOo"></a>1. Obtenir OOo</h3>
+      <span style="font-family: helvetica,arial,sans-serif;"></span><span
+ style="font-weight: bold; font-family: helvetica,arial,sans-serif; color: rgb(255, 255, 255);"></span><!-- /Table Navigation Bar -->Il
+y a un tas de versions compétitives d'OOo et plusieurs choix de
+branches, ainsi que de multiples sets de patches. Je vous recommande de
+compiler à partir de snapshots CVS, qui sont connues pour compiler et
+dont les sets de patchs sont connus pour s'appliquer. Ainsi pour avoir
+les sources faites :<br>
+      <pre>export CVSROOT=':pserver:anonymous@anoncvs.gnome.org:/cvs/gnome'<br>    cvs login<br>    cvs -z3 checkout -P ooo-build</pre>
+Cela vous fournira un copie de la branche ooo-build. Si CVS vous fait
+peur, vous devriez obtenir une version récente packagée à partir <a
+ href="http://ooo.ximian.com/packages">d'ici</a>. <br>
+      <span style="font-weight: bold;">Note</span> : Vous allez devoir
+télécharger environ 200 Mo de sources compressées et avoir ~5Go
+d'espace pour la dépackager et la compiler.<br>
+      <h3><a name="2._Compiler_OOo"></a>2. Compiler OOo</h3>
+      <span style="font-weight: bold;">2.1 configure</span><br>
+Le processus de compilation est plutôt compliqué, vous avez maintenant
+le choix des commandes suivantes et même en les exécutant toutes les
+deux, cela ne
+posera pas de problèmes.<br>
+      <pre>./autogen.sh # the CVS version<br>      ./configure  # the packaged version</pre>
+      <br>
+Ceci va déterminer quelle branche de snapshot vous voulez compiler ; si
+vous avez une autre idée, utilisez l'option --with-tag, par exemple :<br>
+      <pre>--with-tag=OOO_1_1_0</pre>
+pour une branche en cours.<br>
+      <br>
+      <span style="font-weight: bold;">2.2 téléchargement</span><br>
+Avec un certain temps, vous avez mis à jour votre système à un point où
+il a
+tous les packages dont vous avez besoin pour commencer la compilation
+de OOo (mozilla, libart récent etc. etc.) vous en être rendu au point
+où vous pouvez télécharger les sources. Pour faire cela, après un
+configure réussit, tapez simplement :<br>
+      <pre>./download</pre>
+et attendez.<br>
+      <span style="font-weight: bold;">make </span><br>
+C'est le bit taxant - tapez<br>
+      <pre>make</pre>
+et n'oubliez pas de presser entré. Il est fort possible que vous
+souhaitiez une sortie des logs, alors pourquoi pas<br>
+      <pre>make 2&gt;&amp;1 | tee /tmp/log</pre>
+      <h3><a name="3._Installer_OOo"></a>3. Installer OOo</h3>
+Le résultat d'une compilation parfaite est un set d'installation zippé
+situé dans <br>
+      <pre>build/$TAG/instsetoo/unxlngi4.pro/01/normal/</pre>
+ou similiaire. Puis exécutez le programme setup à partir de là pour
+l'installation, exemple :<br>
+      <pre>/opt/OOInstall</pre>
+pour installer. Il est possible que pour faire cela, vous deviez
+d'abord effacer votre&nbsp; fichier<br>
+      <pre>~/.sversionrc</pre>
+L'ayant installée, vous avez envie de la hacker en liant votre tronc
+compilée directement à l'image installée, ainsi en recompilant un sous
+répertoire source, vous pouvez simplement réexécuter OOo. Cela peut
+rendre votre version/cycle de test&nbsp; indisponible pendant plusieurs
+dizaine de minutes. Pour faire cela faites :<br>
+      <pre>bin/linkoo /opt/OOInstall /opt/ooo-build/build/OOO_1_1_2</pre>
+NB : voir aussi les <a href="#linkoo">limitations linkoo</a><br>
+      <h3><a name="4._Exécuter_OOo"></a>4. Exécuter OOo</h3>
+Maintenant positionnez-vous dans :<br>
+      <pre>/opt/OOInstall/program</pre>
+et faites<br>
+      <pre>source ./env</pre>
+cela paramétrera votre shell (bash) pour exécuter OOo directement. Puis
+simplement<br>
+      <pre>soffice.bin</pre>
+C'est mieux que d'exécuter soffice, ou un script wrapper dans la mesure
+où il est très facile d'attacher le débuggueur.<br>
+      <pre>gdb soffice.bin</pre>
+      <span style="font-weight: bold;">Note</span> : n'utilisez pas <br>
+      <pre>./soffice.bin</pre>
+pour d'obscures raisons cela ne marche pas du tout<br>
+      <span style="font-weight: bold;">Note </span>: vous devez
+exécuter le ooo-wrapper basé sur OOo avant cela, pour
+que ~/.sversionrc soit paramètré correctement d'abord, autrement
+exécuter&nbsp; soffice.bin vous enverra dans l'outil de setup du GUI.
+Faites juste un <br>
+      <pre>oowriter</pre>
+avant de commencer<br>
+      <h3><a name="5._Hacker_OOo"></a>5. Hacker OOo</h3>
+      <span style="font-weight: bold;">5.0. Mon premier hack</span><br>
+Bon - nous avons compilé et exécuté OOo et nous voulons nous prouver
+qu'il est en fait possible de le hacker. Donc, dans un nouveau
+terminal, faites ceci :<br>
+      <pre>cd build/$TAG<br>      . ./LinuxIntelEnv.Set.sh<br>      cd vcl</pre>
+Maintenant pour faire un hack à vcl/source/window/toolbox2.cxx, je
+suggère d'ajouter (par exemple) un <br>
+      <pre>nPos = 0</pre>
+n'importe où avant le m_aItems.insert dans ToolBox::InsertItem( const
+ResId &amp;ResId...) puis sauvegardez<br>
+Vous êtes toujours dans vcl/ oui ? alors tapez 'build debu=true';
+attendez que le texte défilant s'arrête; (5 secondes ?) maintenant
+re-exécutez <br>
+      <pre>soffice -writer</pre>
+vous devriez voir ce qui arrive<br>
+      <span style="font-weight: bold;">Note</span> : ceci assume que
+vous avez soigneusement suivi les étapes précédentes, <span
+ style="font-style: italic;">notamment</span> le linkoo dans la <a
+ href="#3._Installer_OOo">section
+3</a><br>
+      <span style="font-weight: bold;">Note </span>: pour un hacking
+quotidien vous préférerez exécuter 'build' à
+l'intérieur du tronc source. N'exécutez pas 'make' au niveau
+supérieur<br>
+      <pre>ooo-build/</pre>
+du répertoire ou vous allez (très certainement) effacer toutes les
+modifications que vous avez faites et déprimer. Cela vaut le coup de
+faire une copie 'out of line' de <br>
+      <pre>build/OOO_1_1_2</pre>
+quelque part voir<a href="#10_FAQ_non_fr%C3%A9quentes"> ici</a> pour
+une aide de relocalisation de la version<br>
+      <br>
+      <span style="font-weight: bold;">5.1 Lire le manuel sympa</span><br>
+Avec le pouvoir de C++ , vous allez pouvoir vous prendre la tête très
+facilement (et implicitement) cf <em>Holub, Rules for C and C++
+programming, McGraw-Hill, 95</em><br>
+Le meilleur moyen de vous préparer à la bataille est de lire le guide
+du codage OpenOffice.org <a
+ href="http://tools.openoffice.org/CodingGuidelines.sxw">ici</a> et
+pour ceux qui se perdent facilement c'tor/d'tor est le raccourci de
+constructor / destructor.<br>
+      <br>
+      <span style="font-weight: bold;">5.2 Soumettre un patch</span><br>
+Il est rarement clair de savoir dans quel module réside un patch dans
+bugzilla. Un moyen rapide de s'y retrouver est de faire :<br>
+      <pre>cvs status &lt;somefile&gt; | head</pre>
+Cela devrait donner une ligne&nbsp; 'Repository Revision:' avec un
+chemin, le second fragment est le nom du projet.<br>
+      <br>
+      <span style="font-weight: bold;">5.3 Hacker l'installeur</span><br>
+Dans la mesure où l'image de l'installeur détruit l'image (exécutable)
+temporaire de setup dans <tt>/tmp/sv001.tmp</tt>, vous devez
+l'empêcher de le faire. Exécutez setup / install avec l'option
+-dontdeletetemp.<br>
+      <br>
+      <span style="font-weight: bold;">5.4 Hacker d'autres parties</span><br>
+Ayant une installation qui fonctionne, la meilleure façon de lui
+ajouter
+vos hacks est de mettre un lien symbolique de <tt>program/lib<em>foo</em>641li.so</tt>
+à la build que vous venez juste de construire le plus sûrement vers <tt><em>foo</em>/unxlngi4.pro/lib/</tt>
+, puis de redémarrer la suite et vos changements devraient être
+incorporés<br>
+      <br>
+Par exemple, disons que vous voulez : 'sal' le System Abstraction Layer
+et vous avez installé OOO_STABLE_1 dans /opt/OOInstall, vous
+devez&nbsp; faire :<br>
+      <pre>cd /opt/OOInstall/program<br>mkdir backup<br>mv libsal.so.3.0.1 backup<br>ln -s /opt/OpenOffice/OOO_STABLE_1/sal/unxlngi4.pro/lib/libsal.so.3.0.1 .</pre>
+      <br>
+      <span style="font-weight: bold;">5.5 Comprendre D'make (man)</span><br>
+Alors que le système de compilation est similaire à beaucoup d'autres
+systèmes, il est en même temps légèrement différent. La vue d'ensemble
+est que chaque module est <span style="font-style: italic;">compilé</span>,
+et qu'ensuite le résultat est <span style="font-style: italic;">délivré</span>
+dans le <a href="http://www.openoffice.org/dev_docs/source/solver.html">solver</a>.
+Chaque module est compilé en fonction de l'entête dans le solver.
+Ainsi, il y a quelques intrications :<br>
+      <ul>
+        <li><i>build</i> : ce script perl <i>solenv/bin/build.pl </i>est
+utilisé en conjonction avec <a href="#build.lst">prj/build.lst</a>
+pour s'assurer que chaque
+module qui est nécessaire est compilé en premier. La compilation
+détourne les dépendances interne des modules et compile chaque module
+avec une paire chdir, dmake.</li>
+        <li><i>deliver</i> : ce script perl <i>solenv/bin/deliver.pl</i>
+installe les entêtes, et les librairies (etc.) dans le solver comme
+l'en informe <a href="#d.lst">prj/d.lst</a>. De façon crucial, cela
+permet de s'assurer que
+la date de chacun des fichiers qui sont installés dans le solver est la
+même
+que celle dans le répertoire du module. Cela permet de s'assurer qu'il
+n'y a pas, (particulièrement pour les entêtes) de dépendances en
+cascade déclenchant des recompilations dans les autres modules.</li>
+      </ul>
+      <span style="font-weight: bold;">5.5.1 Répertoires standards</span><br>
+Il y a plusieurs répertoires standards et fichiers dans la plupart des
+modules qui constituent OO.o, en voici quelques-uns des plus utiles.<br>
+      <ul>
+        <li><span style="font-weight: bold;">prj </span><br>
+        </li>
+        <ul>
+          <li><i>build.lst</i> : cela liste les répertoires qui
+doivent être faites,&nbsp; les commentaires '^#'sont permis, l'ordre de
+cette liste est sans importance voir les <a href="#build.lst">détails</a>,
+il est dicté par les
+opérations de '<span style="font-style: italic;">builds</span>'<br>
+          </li>
+          <li><i>d.lst</i> : ce fichier décrit le processus <span
+ style="font-style: italic;">deliver</span>, voir les <a href="#d.lst">détails</a></li>
+        </ul>
+        <li><span style="font-weight: bold;">util</span> :
+typiquement, le répertoire util est chargé en agrégeant ensemble les
+sous-répertoires pour chaque sous-module dans une seule grande
+librairie, ajoutant des dépendances de librairies system, compilant les
+fichiers ressours pour le GUI, etc. Tout le travail est décrit dans <span
+ style="font-style: italic;">makefile.mk</span>, c'est en général le
+dernier répertoire construit dans un projet.</li>
+        <li><span style="font-weight: bold;">inc</span> :&nbsp; les
+entêtes
+publiques sont typiquement séparées dans un répertoire 'inc', cela les
+installera dans le solver par la phase 'deliver' (en utilisant <span
+ style="font-style: italic;">prj/d.lst</span>)</li>
+      </ul>
+Il y a également plusieurs types de fichiers qui sont (ou ne sont pas)
+intéressants :<br>
+      <ul>
+        <li><span style="font-weight: bold;">makefile.rc</span> : ils
+sont tous plus ou moins redondants et peuvent ignorés sans problème</li>
+        <li><span style="font-weight: bold;">makefile.mk</span> :
+ceux-la au contraire sont le fichiers 'dmake' qui sont utilisés pour
+compiler chaque répertoire source.</li>
+      </ul>
+      <span style="font-weight: bold;"><a name="build.lst"></a>5.5.2
+build.lst</span><br>
+Au premier coup d'oeil, build.lst à l'air inquiétant <br>
+      <pre>vc      vcl : nas freetype psprint rsc sot ucbhelper unotools sysui NULL<br>vc      vcl                      usr1   -       all     vc_mkout NULL<br>vc      vcl\source\unotypes      nmake  -       all     vc_unot NULL<br>vc      vcl\source\glyphs        nmake  -       all     vc_glyphs vc_unot NULL</pre>
+      <br>
+aussi nous devons essayer de décortiquer ce qui se passe ici, qui n'est
+en fait pas si bizarre qu'il n'y paraît au premier coup d'oeil. En
+premier, les listes sont terminées par le string 'NULL'. Chaque ligne
+est préfixée par un raccourci qui est significatif.<br>
+      <ul>
+        <li>La première ligne active contient un ':', cela décrit le
+fait que ce projet (vcl) dépend des autres modules 'nas', 'freetype',
+'psprint' etc. qui doivent être construits en premier. C'est pour les
+dépendances inter-projet.</li>
+        <li>Nous avons ensuite une ligne redondante 'usr1' [pour le fun
+?], en fait seulement les lignes contenant le string magique 'nmake'
+sont valides après cela.</li>
+        <li>Les lignes suivantes décrivent des dépendances internes des
+répertoires du projet et ressemblent à :<br>
+          <pre>[shortcut] [path to dir to build] nmake - [flags] [unique-name] [deps...] NULL<br>vc           vcl\source\glyphs    nmake -   all     vc_glyphs   vc_unot   NULL<br></pre>
+          <br>
+          <span style="font-style: italic;">shortcut</span> n'est pas
+utilisé ; <span style="font-style: italic;">flags </span>détermine
+sur quelle plateforme porte la compilation, en général un simple code
+de
+caractère de plateforme : 'dnpum' 'u' étant Unix. Le plus haut on est
+dans le système, le plus on trouvera de matériel avec le drapeau
+'all'.<br>
+          <i>unique-name</i> c'est un nom magique, utilisé par les
+autres lignes pour décrire une dépendance interne. <i>deps...</i>
+n'importe quel nombre de noms des autres répertoires dans ce fichier
+qui doit être compilé avant celui-là.</li>
+      </ul>
+Ainsi pour le cas de vcl, nous voyons que <i>vcl\source\unotypes</i>&nbsp;
+(vc_unot) doit être compilé avant<i> vcl\source\glyphs</i>&nbsp;
+(vc_glyphs) C'est <span style="font-weight: bold;">important</span> de
+comprendre que l'ordre de la liste est ~
+sans importance, et qu'à la place d'une simple liste ordonnée, nous
+avons un système de dépendances internes plus complexe : cela contraste
+avec la plupart des autres sytèmes make.<br>
+      <br>
+Il y a également de la documentation <a
+ href="http://tools.openoffice.org/tools/build.html">ici</a> à ce sujet.<br>
+      <br>
+      <a name="d.lst"></a>5.5.3 d.lst<br>
+La syntaxe de d.lst est plus facile à comprendre que celle de
+build.lst, il ommet des actions par défaut comme copier build.lst dans <i>inc/&lt;module&gt;/build.lst</i>.<br>
+Une ligne de la forme : <br>
+      <pre>[action]: [arguments]<br>mkdir:    %_DEST%\inc%_EXT%\external</pre>
+où si '[action]' est ommis, l'action 'copy' sera prise par défaut. Les
+actions typiques sont <i>copy</i>, <i>mkdir</i>, <i>touch</i>, <i>hedabu</i>,
+      <i>dos</i> and <i>linklib</i><br>
+L'action 'hedabu' est particulièrement intéressante, dans la mesure où
+il reformate cosmétiquement les entêtes pour les faire rétrécir pendant
+l'installation (sinon, elle ressemble beaucoup à l'action copy)<br>
+Pendant l'action, des variables de macros diverses sont étendues,
+quelques-unes sont :<br>
+      <ul>
+        <li>%__SRC% — nom du répertoire de la distribution ex. <i>unxlngi4.pro</i></li>
+        <li> %_DEST% — chemin absolue du solver ex. <i>/opt/OpenOffice/OOO_STABLE_1/solver/641/unxlngi4.pro</i>
+        </li>
+        <li> %_EXT% — chemin (inusuel) pour avoir un update mineur
+ex.
+641.1, typically used to version every base sub-directory.</li>
+      </ul>
+Typiquement cependant,&nbsp; si vraiment vous avez besoin d'ajouter une
+règle (cf copies implicites de répertoire), elle sera de la forme <br>
+      <pre>..\%__SRC%\inc\sal\*.h %_DEST%\inc%_EXT%\sal\*.h</pre>
+NB : les chemins relatifs sont relatifs au répertoire 'prj/'<br>
+      <br>
+      <span style="font-weight: bold;">5.6 Itérations rapides</span><br>
+Il existe plusieurs manières de venir à bout des itérations de
+développement, le meilleur moyen est d'utiliser <a
+ href="#3._Installer_OOo">linkoo</a> pour lier
+symboliquement la librairie de l'install set directement dans votre
+tronc compilé. Ainsi vous pouvez simplement recompiler un sous
+répertoire, ex .<br>
+      <pre>vcl</pre>
+en exécutant<br>
+      <pre>build</pre>
+et en réexécutant soffice.bin<br>
+      <br>
+      <span style="font-weight: bold;">5.7 Puis-je avoir un char *,
+s'il vous plaît ?</span><br>
+OOo contient à peine 6 strings de wrappers, aussi les implémentations C
+présentent peu d'intérêt<br>
+      <ul>
+        <li><code>rtl_String :</code> sal/inc/rtl/string.h<br>
+string 'Normal' plus une référence de comptage <code>rtlstring-&gt;buffer</code>&nbsp;
+est utile, comme l'est <code>rtlstring-&gt;length</code>&nbsp; . Ce
+string a déjà été converti dans un set de caractère particulier, voir
+sal/inc/rtl/textenc.h : les seuls cas intéressants sont <code>RTL_TEXTENCODING_UTF8</code>&nbsp;
+et peut-être <code>RTL_TEXTENCODING_ASCII_US</code> pour de vrai ( ?).
+N'hésitez pas à traiter&nbsp; <code>rtlstring-&gt;buffer</code> comme
+votre char * préféré.</li>
+        <li><code>OString</code> : sal/inc/rtl/string.hxx<br>
+Un simple rtl_String <code></code> sal/inc/rtl/string.hxx enveloppé
+dans une classe, vous pouvez utiliser <code>ostring.pData</code> pour
+avoir un rtl_String&nbsp; (c'est public) . <code>OString</code> a des
+méthodes raisonnablement utiles si vous en avez besoin.</li>
+        <li><code>rtl_uString</code> : sal/inc/rtl/ustring.h<br>
+string 'Normal' Unicode similaire à rtl_String&nbsp; et référence de
+comptage aussi bien. Cependant celui-ci vient toujours avec un encodage
+UCS-2, sans doute pour être compatible avec des choix Java douteux.</li>
+        <li><code>OUString</code> : sal/inc/rtl/ustring.hxx<br>
+un rtl_uString enveloppé dans une classe. C'est ce qu'utilise la
+plupart du code OOo pour passer les strings</li>
+        <li><code>String</code>&nbsp; : tools/inc/string.hxx<br>
+C'est une classe de string obsolète, aliasée à 'UniString'. Elle a un
+certain nombre de limitations comme An rtl_uString&nbsp; enveloppé à
+l'intérieur d'une classe. C'est ce qu'utilise la plupart du code OOo
+pour passer les strings</li>
+      </ul>
+Dans la mesure où un homme réel utilise des strings <code>char * </code>encodés
+en UTF-8, pour utiliser n'importe quel système d'API comme 'printf'
+vous devez extraire un <code>char * </code>de <code>OUString</code>,
+utilisez ceci :<br>
+      <pre>static char *<br>gimme_utf8_please (const rtl::OUString &amp;oustring)<br>{<br>  rtl::OString ostring;<br><br>  ostring = ::rtl::OUStringToOString (oustring, RTL_TEXTENCODING_UTF8);<br>        return strdup (ostring.pData-&gt;buffer);<br>}</pre>
+et l'inverse :<br>
+      <pre>static rtl::OUString<br>complicate_things_into_ucs2_please (const char *utf8_string)<br>{<br>  rtl::OString ostring;<br><br>        ostring = rtl::OString (utf8_string);<br>  return rtl::OStringToOUString (ostring, RTL_TEXTENCODING_UTF8);<br>}</pre>
+      <br>
+Si vous souhaitez juste imprimer un string pour des besoins de
+debuggage, vous voudrez sans doute lire <a href="#printout">ceci</a> .<br>
+      <br>
+      <span style="font-weight: bold;"><a name="5.7.2"></a>5.7.2
+Examiner les strings de GDB</span><br>
+Nous avons déjà vu que OOo n'utilise pas les strings <code>char *</code>
+modestes. Si vous pensez que c'est assez compliqué quand vous écrivez
+du
+code, attendez d'avoir à le débugguer. Voilà comment avoir vos strings
+de gdb/dbx qui n'utilisent pas nativement unicode.<br>
+      <ul>
+        <li>à partir de la branche cvs cws_srx645_ooo112fix1 vous
+pouvez utiliser<br>
+          <pre>(gdb) print dbg_dump(sWhatEver)</pre>
+pour imprimer le contenu de
+UniString/ByteStrin/rtl::OUString/rtl::Ostring quel que soit le type
+lorsque vous débugguez du code C++ vois <a
+ href="http://qa.openoffice.org/issues/show_bug.cgi?id=17295">l'issue
+17295</a> pour les détails.</li>
+      </ul>
+Alternativement, si ce support n'est pas encore dans votre version OOo
+alors...<br>
+      <ul>
+        <li>rtl_String : met le doigt dessus</li>
+        <li>String : note : la décl' de cela utilise la macro
+'UniString' pour embrouiller les lecteurs. Heureusement, par
+programmation, nous pouvons passer un String à un OUString de façon
+transparente.</li>
+        <li>OString : <span style="font-style: italic;">p str-&gt;pData</span></li>
+OUString, rtl_uString (un super truc de Kevin Hendricks) la
+façon la plus rapide et la plus simple de débarasser d'un string est de
+faire :<br>
+        <pre>p *theString; # grab the length (2nd field)<br>x/&lt;length&gt;s theString-&gt;buffer</pre>
+ex pour un string de 20 caractères, nous voulons <br>
+        <pre>x/20s theString-&gt;buffer</pre>
+      </ul>
+      <ul>
+cela devrait imprimer le string comme une collection
+restreinte avec la valeur ASCII des caractères gentiment disposée dans
+une colonne. Pour imprimer, de façon programmée un OUString (ou String)
+vous avez besoin<br>
+      </ul>
+      <pre id="printout">::rtl::OString tmpStr = OUStringToOString (<i>MyOUString</i>, RTL_TEXTENCODING_UTF8);<br>fprintf (stderr, "String is '%s'\n", tmpStr.getStr());<br><br></pre>
+      <span style="font-weight: bold;"><a name="linkoo"></a>5.8
+Limitations linkoo</span><br>
+Bien que trés puissant, linkoo a un certain nombre de limitations dues
+à la façon dont OOo est assemblé. Il y a deux sortes de problèmes :<br>
+      <ul>
+        <li>Un comportement bizarre des liens - ie si vous liez
+symboliquement une librairie, il suit le lien à l'exécution et finit
+dans
+la confusion</li>
+        <ul>
+          <li>soffice.bin - cela doit être copié depuis
+desktop/unxlngi4.pro/bin/soffice à chaque fois que vous entrez dans un
+cycle de développement, autrement le débuggage est confus,</li>
+          <li>libcgmgr2.so - cela doit être copié depuis
+configmgr/unxlgni4.pro/lib à chaque fois, sinon la configuration ne
+peut être chargée,</li>
+        </ul>
+        <li>contruction bizarre d'une librairie interne</li>
+        <ul>
+          <li>les fichiers de filtre ont une détection de code, ex
+sc/source/ui/app/sclib.cxx(ScDLL::DetectFilter) qui est compilé dans
+une librairie statique, installée puis lié dans libwrp dans
+desktop/source/offwrp. Pour recompiler dans 'sc' exécutez :<br>
+            <pre><a href="http://ooo.ximian.com/build">build</a> &amp;&amp; <a
+ href="http://ooo.ximian.com/deliver">deliver</a></pre>
+puis dans desktop/source/offwrp exécutez<br>
+            <pre>touch wrapper.cxx &amp;&amp; dmake</pre>
+            <br>
+          </li>
+        </ul>
+      </ul>
+      <h3><a name="6._Débugguer_OOo"></a>6. Débugguer OOo</h3>
+Cette section assume que vous utilisez gdb à partir d'une console<br>
+      <br>
+      <span style="font-weight: bold;">6.1 Compiler avec des symboles
+de débuggage</span><br>
+OOo inclus la possibilité d'ajouter du code de débuggage par module,
+vial la commande <tt>build debug=true </tt>dans chaque module.
+Malheureusement, ce n'est pas recommandé de l'exécuter pour l'ensemble
+du projet, en plus d'inclure des symboles de débuggage vitaux, il
+inclut également des tas d'assertions, des warnings et d'autres
+vérifications variées.<br>
+Ainsi si vous voulez des symboles de débuggage pour tout, vous devez
+hacker plusieurs makefiles pour ajouter les symboles de débuggage [NB
+cela rendra les binaires de OOo ~1Mo plus petits et la branche
+complète de build envrion 8 Go aussi faites y attention] appliquez ce
+patch :<br>
+      <pre>--- solenv/inc/unxlngi4.mk<br>+++ solenv/inc/unxlngi4.mk<br>@@ -92,18 +92,18 @@ cc=gcc<br> # do not use standard header search paths<br> # if installed elsewhere<br> .IF "$(BUILD_SOSL)"!=""<br>-CFLAGS=<br>+CFLAGS=-g<br> .ENDIF<br> CFLAGS+=-fmessage-length=0 -c $(INCLUDE)<br> # flags for the C++ Compiler<br>-CFLAGSCC= -pipe -mcpu=pentiumpro<br>+CFLAGSCC= -g -pipe -mcpu=pentiumpro<br> # Flags for enabling exception handling<br> CFLAGSEXCEPTIONS=-fexceptions -fno-enforce-eh-specs<br> # Flags for disabling exception handling<br> CFLAGS_NO_EXCEPTIONS=-fno-exceptions<br> <br> # -fpermissive should be removed as soon as possible<br>-CFLAGSCXX= -pipe -mcpu=pentiumpro -fno-for-scope -fpermissive -fno-rtti <br>+CFLAGSCXX= -g -pipe -mcpu=pentiumpro -fno-for-scope -fpermissive -fno-rtti <br> <br> # HACK: enable Hamburg developers to build on glibc-2.2 machines but compile vs. glibc-2.1 headers<br> .IF "$(BUILD_SOSL)"==""</pre>
+      <br>
+Bien sûr, sans les symboles de débuggage gdb devient encore plus
+inutile. Pour appliquer le patch copiez et collez la partie ci-dessus
+dans /tmp/foo et dans le répertoire de base.<br>
+      <pre>patch -p0 &lt; /tmp/foo</pre>
+      <span style="font-weight: bold;">6.2 Positionner des points de
+rupture</span><br>
+Dû à un niveau assez élevé de plantages dans gdb, il est à peu près sûr
+que positionner des points de ruptures avant l'exécution ne
+fonctionnera pas, aussi le meilleur schéma est de <br>
+      <pre>gdb ./soffice<br>break main<br>run # don't forget the arguments here<br># ... traps in main ...<br>break osl_readFile<br>continue</pre>
+      <br>
+Bien sûr cela ne marchera jamais si le code est implémenté dans un
+librairie qui est dlopened plus tard, ce qui arrive pour une vaste
+majorité du code de OOo. Aussi vous devez&nbsp; attraper le chargement
+du code et alors mettre les points de rupture dedans. Pour faire cela
+appliquez un point de rupture dans osl_psz_loadModule et souffrez.<br>
+Alternativement si vous pouvez instrumenter le code, c'est plutôt
+facile d'ajouter #include &lt;signal.h&gt; et mettez un (SIGSTOP);
+quelque part dans le code qui sera attrapé dans le débuggueur.<br>
+      <br>
+      <span style="font-weight: bold;">6.3 Commencer au début</span><br>
+Nous commençons dans 'main' avec un wrapper sal, cela appelle
+vcl/source/app/svmain.cxx(SVMain). Cela invoque Main dans
+pSVData-&gt;mpApp; mais pSVData est un en-ligne local. Pour débugguer
+cela utilisez la variable globale pImplSVData, ex :<br>
+      <pre>p pImplSVData-&gt;maAppData</pre>
+Cette méthode 'Main' est typiquement : desktop/source/app/app.cxx (Main)<br>
+      <br>
+      <span style="font-weight: bold;">6.4 Examiner strings</span><br>
+Le char * modeste (que gdb peut afficher nativement) est évité dans le
+monde des objets en le wrappant avec différentes classes innombrables
+que gdb ne comprend pas. Le pire, dans pas mal de cas
+il est extrèmement difficile même d'imprimer le string, une des
+conséquences qui a fait que nous avons pris la décision d'utiliser un
+encodade ucs-2. Il y a aussi des classes string à la fois variables et
+invariables.<br>
+Merci de lire la <a href="#5.7.2">section 5.7.2</a> pour savoir
+comment les strings marchent
+dans OOo et pour avoir des indications de débuggage.<br>
+      <br>
+      <span style="font-weight: bold;">6.5 Permettre une compilation
+dans le bon ordre</span><br>
+Les dépendances de compilation des modules sont vraiment cruciales pour
+obtenir une version propre. Lorsque vous tapez 'build' dans un module,
+la compilation examine d'abord prj/build.list, ex neon/prj/build.lst :<br>
+      <pre>xh      neon  :  soltools external expat NULL</pre>
+cela signifie que 'soltools, 'external' et 'expat' doivent être
+compilés et délivrés correctement avant que neon ne puisse être
+compilé. Occasionnellement ces règles peuvent être brisées et personne
+ne s'en aperçoit avant un moment.<br>
+      <br>
+      <span style="font-weight: bold;">6.6 Cela plante, mais seulement
+dans gdb</span><br>
+Vraiment sympa, vous avez lié symboliquement
+desktop/unxlngi4.pro/bin/soffice à soffice.bin dans votre tronc
+d'install, n'est-ce pas ? Cela marche correctement si vous ne faites
+que l'exécuter, mais il semble que gdb défait les liens symbolique
+et&nbsp; passe un lien complètement qualifié come argv[0], qui ne
+permet pas d'atteindre le binaire dans le chemin, il assigne alors le
+chemin du programme de base comme
+/opt/OpenOffice/OOO_STABLE_1/desktop/unxlngi4.pro/bin et commence à
+rechercher (ex applicat.rdb) dedans. Bien sûr quand il n'arrive pas à
+trouver les informations de setup, il plante silencieusement à quelques
+kilomètres du problème d'origine.<br>
+      <br>
+      <span style="font-weight: bold;">6.7 Cela plante, mais ne plante
+pas</span><br>
+Pour des raisons diverses, les détecteurs de signal sont attrapés et la
+vie peut devenir plutôt confuse, ainsi le mieux pour les compileurs est
+d'appliquer quelque chose comme ça :<br>
+      <pre>--- sal/osl/unx/signal.c<br>+++ sal/osl/unx/signal.c<br>@@ -188,6 +188,8 @@ static sal_Bool InitSignal()<br>             bSetILLHandler = sal_True;<br>        }<br> <br>+       bSetSEGVHandler = bSetWINCHHandler = bSetILLHandler = bDoHardKill = sal_False;<br>+<br>        SignalListMutex = osl_createMutex();<br> <br>        act.sa_handler = SignalHandlerFunction;</pre>
+NB. trailing space<br>
+      <br>
+      <span style="font-weight: bold;">6.8.1 Je ne peux trouver le code
+à partir de la trace</span><br>
+Quelques méthodes, décrites pour avoir un liage spécial, comme cette
+clé, peuvent être utilisées dans les callbacks ; typiquement elle a un
+préfixe 'LinkStub', et cherche ainsi la dernière partie de
+l'identifiant dans une recherche de texte libre ex <br>
+      <pre>IMPL_LINK( Window, ImplHandlePaintHdl, void*, EMPTYARG )</pre>
+compile la méthode 'LinkStubImplHandlePaintHdll'.<br>
+      <br>
+      <span style="font-weight: bold;">6.9 Comment puis-je recompiler
+seulement les fichiers que je vois dans
+la trace</span><br>
+Souvent lorsque vous exécutez gdb dans une compilation non débugguée,
+vous ne pouvez vous permettre d'attendre et recompiler (par exemple)
+tout oowriter. Aussi nous avons créé une petite aide perl avec laquelle
+vous pouvez couper et coller les noms de methode/classe qui vous
+intéressent à partir du stack, et cela touchera juste les fichiers
+contenant ces strings pour faciliter une recompilation. Voici un flux
+de travail typique de débuggage.<br>
+      <pre>gdb ./soffice.bin<br>...<br>    bt<br>#0  0x40b4e0a1 in kill () from /lib/libc.so.6<br>#1  0x409acfe6 in raise () from /lib/libpthread.so.0<br>#2  0x447bcdbd in SfxMedium::DownLoad(Link const&amp;) () from ./libsfx641li.so<br>#3  0x447be151 in SfxMedium::SfxMedium(String const&amp;, unsigned short, unsigned char, SfxFilter const*, SfxItemSet*) ()<br>   from ./libsfx641li.so<br>#4  0x448339d3 in getCppuType(com::sun::star::uno::Reference<com::sun::star::document::ximporter> const*) () from ./libsfx641li.so<br>...<br>    quit<br>    cd base/OOO_STABLE_1/sfx2<br>    ootouch SfxMedium<br>    build debug=true</com::sun::star::document::ximporter><br></pre>
+Ainsi tous les fichiers référençant/implémentant quelque chose avec
+SfxMedium seront touchés et recompilés avec des symboles de débuggage.<br>
+      <br>
+      <span style="font-weight: bold;">6.10 Comment puis recompiler
+tous les fichiers dans un répertoire source</span><br>
+Si vous souhaitez recompiler le code seulement dans vore répertoire
+courrant, vous pouvez utiliser la cible killobj dmake pour enlever les
+fichiers objets :<br>
+      <pre>  dmake killobj<br>      dmake</pre>
+      <br>
+      <span style="font-weight: bold;">6.11 Cela plante toujours dans
+sal_XErrorHdll</span><br>
+Vous êtes victime d'un rapport d'erreur X asynchrone <br>
+      <pre>export SAL_SYNCHRONIZE=1</pre>
+rendra le traffic de X syncrhone et rapportera l'erreur par la méthode
+qui l'a causé, cela rendra également OOo beaucoup plus lent et le
+timing différent.<br>
+      <br>
+      <span style="font-weight: bold;">6.12 Il échoue silencieusement à
+charger mez fichiers word</span><br>
+Coalan a suggéré : mettez un point de rupture sur le dessus de
+ww8par.cxx&nbsp; et la queue de SwWW8ImplReader::LoadDoc et confirmez
+que le document va aussi loin que le fichier d'import.<br>
+Un endroit facile et humain pour mettre un point de rupture est&nbsp;
+dans SwWW8ImplReader::ReadPlainChars vous pouvez voir des tas de text
+au moment ou ils sont lus. Alternativement
+SwWW8ImplReader::ReadPlainChars à chaque paragraphe qui est inserré.<br>
+      <br>
+      <span style="font-weight: bold;">6.13 Comment est-ce que
+j'utilise une console de débuggage ?</span><br>
+Ainsi OOo contient une importante infrastructure de débuggage, vous
+pouvez la voir<a href="http://ooo.ximian.com/images/debug-window.png">
+ici</a> Malheureusement l'activer n'est pas trivial. Premièrement, rien
+n'est compilé dans une compilation de produit, aussi nous devons
+recompiler des parties centrales du code OOo comme des compilations
+non-produit et nous devons&nbsp; réexécuter linkoo pour lier ces
+nouvelles compilations dans notre set.<br>
+Tous d'abord, créer un fichier de débuggage d'Environnement, je
+l'appelle LinuxIntelEnv.Set.debug<br>
+      <pre>TMPFILE=~/.Env.Set.debug<br><br># Purge .pro bits<br>sed 's/\.pro//g' LinuxIntelEnv.Set.sh &gt; $TMPFILE<br>. $TMPFILE<br>rm $TMPFILE<br><br># Clobber product parts<br>unset PRODUCT PROSWITCH PROFULLSWITCH <br></pre>
+Maintenant faites<br>
+      <pre>source ./LinuxIntelEnv.Set.debug</pre>
+cela met en place votre environnement pour une build non productive.<br>
+cd vcl; build dbgutil=true --all linkoo<br>
+Maintenant - exécutez simplement OOo et quand c'est en plein travail,
+pressez &lt;Alt&gt;&lt;Maj&gt;&lt;Ctrl&gt; 'D' dans cet ordre, cela
+devrait provoquer l'affichage d'une fenêtre de débuggage. Les options
+de débuggage sont sauvés par la suite dans le fichier .dgbsv.init pour
+la prochaine exécution, vous pouvez en contrôler l'emplacement avec :<br>
+      <pre>export DBGSV_INIT=$(HOME)/.dbgsv.init</pre>
+ex : c'est (malheureusement) un fichier binaire<br>
+      <br>
+      <span style="font-weight: bold;">6.14 Debuggage Excel
+Interroperabilité</span><br>
+C'est assez facile, editez sc/source/filter/inc/biffdump.hxx,
+definissez EXC_INCL_DUMPER à 1 et recompilez 'sc'. Faites aussi une
+copie de sc/source/filter/escel/biffrecdumper.ini vers ~. Puis exécutez<br>
+      <br>
+et vous devriez avoir un foo.txt avec les données de débuggage à
+l'intérieur. Si vous n'obtenez rien, vous devez trouver/appliquer
+sc-biffdump.diff à partire <a
+ href="http://qa.openoffice.org/issues/show_bug.cgi?id=25430">d'ici</a>
+      <br>
+      <h3><a name="7._Contribuer_des_patches"></a>7. Contribuer des
+patches</h3>
+      <span style="font-weight: bold;">7.1 Style diff</span><br>
+Utilisez toujours des diffs unifiés 'cvx -z3 diff -u' dans la mesure où
+ils sont plus lisibles types de diff&nbsp; (et sensible) qui se lisent
+et d'appliquent.<br>
+      <span style="font-weight: bold;"><br>
+7.2 Quelques interactions</span><br>
+Cela semble une bonne idée de travailler sur la manière la meilleure
+pour implémenter votre fix, et/ou d'en discuter avec un ou deux
+développeurs avant tout. Une des meilleures façon est de poster sur
+dev@openoffice.org (labo@fr.openoffice.org pour le français) ou de
+regarder sur IRC irc.freenode.net sur le cannal #OpenOffice.org. IRC
+est un moyen de communication vraiment pauvre, mais mieux que pas de
+communication du tout. Voir <a
+ href="http://ooo.ximian.com/name-account.html">ici</a> pour savoir qui
+est qui.<br>
+      <span style="font-weight: bold;"><br>
+7.3 Création de patch ooo-buidl</span><br>
+Voir <a href="http://ooo.ximian.com/ooo-build.html#section-2.2">ici</a>
+pour plus d'informations sur notre infrastructure de patchage<br>
+      <br>
+      <span style="font-weight: bold;">7.4 soumettre un bug</span><br>
+Voir <a href="http://ooo.ximian.com/bug.html">ici</a> pour une
+interface saine/hackers pour IssueZilla
+d'OpenOffice.org<br>
+Dans la mesure où l'on peut toujours connaître le propriétaire d'un
+module en vérifiant le tag ADMIN_FILE_ OWNER il y a un petit outil dans
+ooo-build : bin/owner&lt;file-name&gt; qui vous aide à
+interagir/e-mailer au sujet d'un module donné, c'est mieux d'assigner
+ces bugs spécifiques à cette personne.<br>
+      <h3><a name="8_Conseils_divers"></a>8 Conseils divers</h3>
+      <span style="font-weight: bold;">8.1 Obtenir un accompte OOo CVS</span><br>
+Voici le process pour obtenir un accompte CVS pour le serveur CVS, les
+compte ooo-build sont maintenus <a
+ href="http://ooo.ximian.com/ooo-build.html#section-2.5.1">différemments</a>
+Pour connaître comment le processus de soumission d'issue marche, voir
+l'issue #7270. Une fois votre compte créé, vous devez ouvrir un tunnel
+pour sécuriser le server CVS, quelque chose comme :<br>
+      <pre>ssh -f -2 -P -L 2401:localhost:2401 tunnel@openoffice.org sleep 1400 &lt; /dev/null &gt; /dev/null<br></pre>
+Vous devez ensuite changer CVSROOT pour pointer sur votre machine
+locale, dans la mesure où c'est le point final du tunnel :<br>
+      <pre>:pserver:mmeeks@localhost:/cvs<br></pre>
+Votre nom de compte et mot de passe seront les mêmes que ceux que vous
+utilisez pour rentrer des bugs dans le système Source Cast. Logguez
+vous et... vous vous apercevrez rapidement que vous devez migrer vos
+paramètre CVS sur le serveur, pour faire cela sans perdre de place avec
+des checkouts répétés :<br>
+      <pre>bin/re-root /path/to/checkout ":pserver:&lt;account-name-here&gt;@localhost:/cvs"<br></pre>
+Bien sûr, pour faire un commit, vous devez avoir des privilèges liés au
+projet et vous battre avec la bureaucracie.<br>
+      <br>
+      <span style="font-weight: bold;">8.2 Utiliser patch/diff</span><br>
+Patch/diff sont des outils merveilleux, cependant les gens fournissent
+souvent des données qui provoquent la confusion et qu'il est très
+difficile de corriger. Voici quelques astuces pour remettre les choses
+dans l'ordre <br>
+      <ul>
+        <li>Si vous n'êtes pas sûr du tout, exécutez les patchs avec
+--dry-run d'abord, cela donnera l'apparence de faire l'action de
+patcher, mais en fait ne le fera pas [ cela peut donner de faux
+résultats avec des inter-dépendances compliquées de patches, mais c'est
+très utile]</li>
+        <li>Utilisez plus particulièrement le patch -p0, 0 signifie le
+nombre d'éléments de patchs à dépouiller depuis de début de chemin de
+fichier que le diff pointe.</li>
+        <li>Quand cela plante et que vous n'avez que la moitié du patch
+qui s'applique et que vous souhaitez revenir à un truc propre, à la
+fois supprimez les fichiers et faites un cvs update, ou repatchez avec
+l'option '-R' pour annuler l'effet.</li>
+        <li>Parfois, utiliser diff entre les modules avec beaucoup de
+modification des espaces rend le patch plus difficile à lire, le flag
+'-w' de (cvs) diff rend les choses plus faciles.</li>
+      </ul>
+      <span style="font-weight: bold;">8.3 Make clean</span><br>
+Utilisez dmake clean dans le répertoire supérieur. Dans les versions
+pre HEAD il n'y avait pas de cible 'clean' donc à la place vous devez
+faire quelque chose comme (ce que fait dmake clean maintenant)<br>
+      <pre>find -name 'unxlngi4.pro' -exec rm -Rf {} \;<br></pre>
+      <span style="font-weight: bold;">8.4 setup CVS</span><br>
+Pour une utilisation efficace de la largeur de bande passante, générez
+des diffs
+sensibles par défaut et suivez le cours, vous devez avoir ceci dans
+votre ~/.cvsrc.<br>
+      <pre>cvs -z3 -q<br>diff -upN <br>update -dP<br>checkout -P<br>status -v <br></pre>
+      <span style="font-weight: bold;">8.5 Ajouter des fichiers
+d'entêtes à une compilation.</span><br>
+Pour ajouter des entêtes de fichier dans
+external/ assurez-vous que vous les listez dans external/prj/d.lst pour
+qu'ils soient copiés dans le répertoire
+solver/641/unxlngi4.pro/inc/external pendant la compilation.<br>
+      <br>
+      <span style="font-weight: bold;">8.6 Trouver où hacker</span><br>
+Il y a souvent des éléments GUI utilisés près des trucs que vous
+essayez de localiser/fixer. Trouvez alors des string suffisemment
+inutilisés et recherchez les dans la recherche de texte LXR, cela
+devrait revéler un identifiant relatif à ce string ex : SID_AUTOFORMAT
+ou FN_NUM_BULLET_ON. Une fois cela obtenu, faites une nouvelle
+recherche de texte pour ce string et vous trouverez l'usage [ ou une
+définition chainée à quelque chose d'autre]. Par exemple, pour les
+menus/barre d'outils la fonctionnalité est habituellement dans une
+définition case ex : case SID_AUTOFORMAT:...<br>
+      <h3><a name="9._Liens_utiles"></a>9. Liens utiles</h3>
+9.1 www.openoffice.org<br>
+Alors que la structure initiale d'openoffice.org ne semble pas orientée
+hackers, il y a beaucoup de <a
+ href="http://www.openoffice.org/documentation.html">documentation</a>
+utile si vous la cherchez un peu.<br>
+Pour les nouvelles sur OOo et une perspective distincte sur OOo voir <a
+ href="http://www.ooodocs.org/">ooodocs.org</a><br>
+      <br>
+9.2 Archives de patch<br>
+En produisant différentes versions d'OpenOffice.org, différents
+projects ont produits des patchs (plutôt nombreux) pour OOo.
+Heureusement, ils commencent à être triés à un meilleur rythme, aussi
+aucun patch ne doit être nécessaire dans HEAD pour le compiler, de la
+même manière beaucoup sont allés dans OOO_STABLE_1. Il peut être utile
+de les utiliser tous ou certains néanmoins.<br>
+      <ul>
+        <li><a href="http://ooo.ximian.com/">Ximian</a> OOo patches et
+outils de compilation /snpashots sont tous disponibles sous forme de <a
+ href="http://ooo.ximian.com/packages">packages</a> ou de <a
+ href="http://ooo.ximian.com/patches">patches</a>.</li>
+        <li>Les <a href="http://www.linux-debian.de/openoffice/">pages
+          </a>d'aide <a href="http://www.debian.org/">Debian</a>, avec
+des patches. Et aussi le <a
+ href="http://cvs.debian.org/oo-deb/debian/?cvsroot=debian-openoffice">CVS
+          </a>Debian.</li>
+        <li><a
+ href="http://cvs.mandrakesoft.com/cgi-bin/cvsweb.cgi/SPECS/OpenOffice.org/">archive
+patch</a> de <a href="http://www.linux-mandrake.com/">Mandrake</a> OOo</li>
+        <li>patches de portage OOo <a
+ href="http://www.freebsd.org/cgi/cvsweb.cgi/ports/editors/openoffice/#dirlist">FreeBSD</a></li>
+        <li>les fichiers specs Red Hat (basés sur ceux de Mandrake)
+sont aussi intéressants à lire à partir de leur <a
+ href="http://rawhide.redhat.com/pub/redhat/linux/rawhide/SRPMS/SRPMS/openoffice-1.0.1-6.src.rpm">SRPM</a>.</li>
+        <li>les personnes qui veulent localiser OOo devraient étudier
+les <a
+ href="ftp://ftp.linux.cz/pub/linux/people/pavel_janik/OpenOffice.org_1.0.1_CZ/build-13/build/Patches">patches
+          </a>de Pavel Janik</li>
+      </ul>
+      <h3><a name="10_FAQ_non_fréquentes"></a>10 FAQ (non fréquentes)</h3>
+Comme personne ne m'a jamais demandé cela, I just made them up to
+astro-turf a bit (safer, wipe-clean, more durable questions).<br>
+      <br>
+      <span style="font-weight: bold;">10.1 Pourquoi les branches comme
+'mws_srx644' ont des nombres bizarre à l'intérieur</span><br>
+En consultant des oracles variés, des entrailles, etc, il transpire
+qu'en théorie ces nombres sont incrémentés chaque semaine, ils sont
+freezés chaque semaine&nbsp; ainsi que le solver et l'environnement de
+développement. Cependant, dans un temps plus récent, le processus de
+solidification d'une simple build pour une version plus large a pris
+plus lontemps qu'une semaine créant un dilemne et un tag mixé
+alphanumériquement. Le mws signifie 'Master Workspace'.<br>
+      <br>
+      <span style="font-weight: bold;">10.2 Pourquoi la build nécessite
+Java ?</span><br>
+Essentiellement, il semble qu'il y a beaucoup de fichiers XML impliqués
+dans l'enregistrement des composants et d'autres services divers. Il
+apparaît qu'utiliser Java est juste une façon aisée de faire simplement
+ces manipulations. Aussi Java peut-être utilisé gentiment pendant
+l'exécution s'il est sur la machine.<br>
+Mais à partir du tag SRC680_m44 il y a un <a
+ href="http://www.openoffice.org/issues/show_bug.cgi?id=28773">script
+python alternatif</a> inclut pour remédier au probleme de process de
+ces fichiers XML utilisés pour l'enregistrement, aussi, il est possible
+de compiler des versions après cette date sans java, donc votre choix
+variera suivant que la compilation par défaut se fait avec java.<br>
+      <br>
+      <span style="font-weight: bold;">10.3 Pourquoi [t]csh est cassé ?</span><br>
+C'est plutôt énigmatique, des cassages particulièrement curieux
+semblent venir de la façon de piper les commandes dans stdin de façon
+crucialement différente de la façon de les mettre dans tty aussi :<br>
+      <pre>echo 'echo #define DLL_NAME "libsch641li.so" &gt;./foo.hxx' | /bin/tcsh -s</pre>
+échoue à faire quoi que ce soit alors que taper la même chose dans le
+shell fonctionne correctement. Encore plus bizarrement<br>
+      <pre>tcsh -fc 'echo #define DLL_NAME "libsch641li.so" &gt;./foo.hxx'<br></pre>
+fait les choses correctement. Voir aussi <a
+ href="http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/">csh</a>.<br>
+      <br>
+      <span style="font-weight: bold;">10.4.1 Je viens juste d'essayer
+de faire un re-locate de la compilation
+pourquoi cela ne marche-t-il pas ?</span><br>
+La réponse simple est : vous devez exécuter :<br>
+      <pre>bin/relocate /path/to/new/build<br></pre>
+Un réponse plus complexe est :<br>
+Bon, en assumant que vous avez re-configuré les choses
+(LinuxIntelEnv.Set aura besoin de chemins modifiant aussi et
+ré-important dans votre shell) ensuite cela dépend grandement des
+chemins non relatifs ambigus, codés dans de nombreux fichiers
+générés/compilés, particulièrement les fichiers (dépendant) '.dpc*' .
+Essayez :<br>
+      <pre>find -name '*.dpc*' -exec rm {} \;</pre>
+Le stlport fait vraiment des trucs cassés, vous aurez donc besoin
+d'éditer le 'stl_gcc.h' à l'intérieur du solve/ et de replacer les deux
+instances de chemins ici (voir inc/stl/config/stl_gcc.h)<br>
+      <br>
+      <span style="font-weight: bold;">10.5 CVS dit 'Fatal error
+aborting. [acc] no suche user', pourquoi ?</span><br>
+Bien sûr il est possible que votre nom d'utilisateur ne soit pas
+enregistré, souvent, cela signifie simplement que ~/.cvspass a été
+perdu et/ou que vous ne vous êtes pas loggués dans cvs, logguez-vous et
+répétez la commande.<br>
+      <br>
+      <span style="font-weight: bold;">10.6 Que signifie '.pro' dans
+'unxlngi4.pro' </span><br>
+      <span style="font-style: italic;">Product</span>, n'est-ce pas
+évident ?<br>
+      <br>
+      <span style="font-weight: bold;">10.7 A quoi ressemble vraiment
+OpenOffice.org ?</span><br>
+Aujourd'hui, j'ai trouvé une photographie de lui sur mon système, je
+l'ai mise ici :<br>
+      <br>
+      <br>
+      <img alt="layers" src="layers.png"
+ style="width: 485px; height: 330px;"><br>
+      <br>
+      <span style="font-weight: bold;">10.8 Comment puis-je prendre une
+copie d'écran de OOo ?</span><br>
+OOo fait des choses vraiment étranges avec les ressources X, ainsi des
+applications habituels de copie d'écran n'arrive pas à prendre de
+photos. ImageMagick 'import' fait cependant un bon travail.<br>
+      <pre>import foo.png<br></pre>
+à partir de la console ou<br>
+à la place. NB à moins que vous ne vouliez que vous souhaitiez votre
+monde tout petit, vous devez afficher des grandes icônes de barre
+d'outils d'abord.<br>
+      <br>
+      <span style="font-weight: bold;">10.9 J'essaye de compiler avec
+gcc sur un préfixe avec BUILD dedans,
+pourquoi cela plante ?</span><br>
+C'est dû à de très sérieux crack fumeux en cours dans stlport.
+Essentiellement, il y&nbsp; a des entêtes principales désagréables et
+elles veullent être capable de retomber sur les entêtes précédents
+(avec le même nom) - ainsi elles ont a coder le chemin en dur. Pour
+éviter d'avoir à faire cela dans de multiples endroits, elles utilisent
+un #define, le #define a une marcor expansion faite sur lui. Ainsi si
+votre préfixe gcc contient un élément qui est une macro, vous êtes fait
+:<br>
+config de l'entête stlport :<br>
+      <pre>#define _STLP_NATIVE_INCLUDE_PATH \<br>        /home/michael/ximian-desktop/ooo/BUILD/ooo/include/c++/3.2.2</pre>
+stlport helpful macros:
+      <pre># define _STLP_MAKE_HEADER(path, header) &lt;path/header&gt;<br># define _STLP_NATIVE_CPP_C_HEADER(header)  \<br>        _STLP_MAKE_HEADER(_STLP_NATIVE_INCLUDE_PATH,header)</pre>
+and finally stlport cunning native include:
+      <pre>#include _STLP_NATIVE_CPP_C_HEADER(foo)</pre>
+      <p> Net result: </p>
+      <pre>      g++ ... -D<b>BUILD</b>=<b>7663</b> ...<br>      ...<br>from /home/michael/ximian-desktop/ooo/<b>BUILD</b>/ooo/OOO_1_0_2/xml2cmp/source/xcd/main.cxx:62:<br>/home/michael/ximian-desktop/ooo/<b>BUILD</b>/ooo/OOO_1_0_2/solver/641/unxlngi4.pro/inc/stl/cstddef:35:46:<br>/home/michael/ximian-desktop/ooo/<b>7663</b>/ooo/include/c++/3.2.2/cstddef: No such file or directory<br></pre>
+      <span style="font-weight: bold;">10.10 A quoi sret la description
+des composants UNO XML ?</span><br>
+Pas grand chose, souvent installé, mais plutôt non utilisés<br>
+      <br>
+      <span style="font-weight: bold;">10.11 Pourquoi le code est si
+moche</span><br>
+Les auteurs doivent utiliser un éditeur vraiment étrange. Il pense que
+les tabs stops sont toutes les 4 colonnes. Evidemment le fichier
+s'affiche mal dans les éditeurs Unix qui savent que le tab sont large
+de 4 characteres.<br>
+S'il vous arrive d'utiliser <a
+ href="http://www.gnu.org/software/emacs/">a Real Editor</a>, nous
+avons des lunettes roses à vous vendre. Collez le contenu de <a
+ href="http://ooo.ximian.com/emacs.el">http://ooo.ximian.com/emacs.el</a>
+dans votre .emacs ou chargez le avec une ligne comme celle-ci : <tt>(load
+"/path/to/that/file.el")</tt> . N'oubliez pas d'adapter
+my-openoffice-path-regexp à vos besoins.<br>
+      <h3>11. Travailler avec nous</h3>
+Voir le document <a href="http://ooo.ximian.com/ooo-build.html">About
+ooo-build</a><br>
+      <br>
+Traduction Sophie Gautier<br>
+      <br>
+      <a href="indexlabo.html"><span
+ style="font-family: helvetica,arial,sans-serif;">Retour à l'index Labo</span></a><br>
+      <br>
+      </td>
+    </tr>
+    <tr>
+      <td align="right" valign="bottom">
+      <p>&nbsp;</p>
+<!-- Copyrights -->
+      <p><small>OpenOffice.org native tongue concept and francophone
+project are built for you with pride by Guy Capra (Alomphega).<br>
+This fr project is also led and maintained by Sophie Gautier.</small></p>
+<!-- /Copyrights --> </td>
+    </tr>
+  </tbody>
+</table>
+<br>
+<br>
+<br>
+<br>
+<br>
+<br>
+</body>
+</html>

Propchange: incubator/ooo/ooo-site/trunk/content/fr/Laboratory/guide_hackers.html
------------------------------------------------------------------------------
    svn:eol-style = native

Added: incubator/ooo/ooo-site/trunk/content/fr/Laboratory/howto_write_doc_format_ooo1.0.sxw
URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/fr/Laboratory/howto_write_doc_format_ooo1.0.sxw?rev=1195287&view=auto
==============================================================================
Binary file - no diff available.

Propchange: incubator/ooo/ooo-site/trunk/content/fr/Laboratory/howto_write_doc_format_ooo1.0.sxw
------------------------------------------------------------------------------
    svn:mime-type = application/octet-stream

Added: incubator/ooo/ooo-site/trunk/content/fr/Laboratory/indexlabo.html
URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/fr/Laboratory/indexlabo.html?rev=1195287&view=auto
==============================================================================
--- incubator/ooo/ooo-site/trunk/content/fr/Laboratory/indexlabo.html (added)
+++ incubator/ooo/ooo-site/trunk/content/fr/Laboratory/indexlabo.html Mon Oct 31 00:18:42 2011
@@ -0,0 +1,188 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html>
+<head>
+  <title>Labo</title>
+  <meta http-equiv="content-type" content="text/html; charset=UTF-8">
+</head>
+<body>
+<table border="0" cellpadding="4" width="100%">
+  <tbody>
+    <tr>
+      <td align="left" valign="top" width="100%"><!-- Content -->
+      <h3 style="color: rgb(204, 102, 0);"><font
+ face="Helvetica, Arial, sans-serif"><b>Projet Laboratoire</b></font></h3>
+La plupart des documents de cette page ont été traduits à partir de
+ceux présents sur le projet <a href="http://tools.openoffice.org/">tools.openoffice.org</a>,
+c'est le site de référence du présent projet.<br>
+      <br>
+Ce projet a pour but de vous aider à comprendre comment est organisé,
+structuré, compilé le code d'OpenOffice.org. Nous mettons ainsi des
+documents à votre disposition et une liste sur laquelle vous pouvez
+poser toutes les questions qui vous viennent et également vous proposer
+pour aider dans les travaux de compilation, débuggage, codages en
+cours. Pour vous inscrire à cette liste labo@fr.openoffice.org envoyez
+un mail à labo-subscribe@fr.openoffice.org. Vous rencontrerez sur cette
+liste des plus grands débutants, aux plus grands expérimentés, donc ne
+soyez pas timide pour nous rejoindre :)<br>
+      <br>
+Les compilations que vous allez effectuer ne sont pas des compilations
+officielles d'OOo pour le moment. Afin de les différencier, nous vous
+demandons de bien vouloir y apposer le <a
+ href="../docs/splash-OOo-labo.bmp">splash screen du laboratoire</a>&nbsp;
+en suivant la procédure ci-dessous :<br>
+- le renommer en ooointro.bmp&nbsp; ; <br>
+- le copier dans svx/res à la place de celui qui s'y trouve ; <br>
+- reconstruire le module svx (build), après avoir supprimé l'ancien ; <br>
+- placer les nouveaux binaires obtenus dans le solver (deliver -force)
+; <br>
+- relancer la construction des paquets ( avec dmake openoffice dans
+instsetoo_native/util )<br>
+      <br>
+Si vous souhaitez pour une raison x ou y faire tester vos versions par
+d'autres, ou des patches un peu lourds, nous dipsosons également d'un
+espace de téléchargement. Renseignez vous sur la liste pour savoir
+comment y accéder.<br>
+      <h3>Passons aux choses sérieuses :)</h3>
+Les liens ci-dessous ne sont pas encore complets, nous sommes entrain
+de construire la documentation. Si vous avez des documents, des
+informations ou autres à proposer, n'hésitez pas à le faire via la
+liste du projet.<br>
+      <h3>Environnement de compilation</h3>
+      <ul>
+        <li>Développement OpenOffice.org avec les child workspaces <br>
+        </li>
+        <ul>
+          <li>Vue d'ensemble</li>
+          <li>Outils</li>
+          <li>Polices</li>
+          <li><a href="blog_pavel_eis.html">Utilisation de EIS</a>,
+traduction du blog de Pavel Janik<br>
+          </li>
+        </ul>
+        <li><a href="guide_hackers.html">Guide du Hackers
+OpenOffice.org non officiel</a> : avant de commencer, vous souhaiterez
+lire les conseils et idées données par ce guide non officiel du
+développeur, ou alors simplement naviguer dans les pages web de <a
+ href="http://ooo.ximian.org">ooo.ximian.org</a></li>
+      </ul>
+      <span style="font-weight: bold;">Utiliser CVS pour récupérer les
+sources</span><br>
+      <ul>
+        <li><a href="overview_codeline.html">Vue d'ensemble du
+codelines d'OpenOffice.org</a></li>
+        <li><a href="Branche_index.html">Description des branches
+courantes de CVS et de leur statut</a></li>
+        <li><a href="co_source.html">Télécharger les sources à partir
+de CVS</a></li>
+        <li>Modules CVS disponible à partir d'OpenOffice.org</li>
+      </ul>
+      <span style="font-weight: bold;">Compiler les sources</span><br>
+      <ul>
+        <li><a href="second_plan.html">Informations d'arrière-plan</a></li>
+        <li>Descriptions du processus de compilation</li>
+        <ul>
+          <li>Linux</li>
+          <li><a href="build_ppc.html">PPc</a><br>
+          </li>
+          <li>Solaris</li>
+          <li>Mac OS X</li>
+          <li>Windows</li>
+          <ul>
+            <li>En utilisant les outils 4NT et Microsoft Visual C++
+Compiler</li>
+            <li>En utilisant les outils Cygwin et Microsoft Visual C++
+Compiler</li>
+          </ul>
+        </ul>
+        <li>Description de l'environnement de compilation</li>
+        <li><a
+ href="http://tools.openoffice.org/project_dependencies.png">Diagramme
+des dépendances inter-projet</a> par C.P. Hennesy</li>
+        <li>Astuces pour se sortir des problèmes de compilation</li>
+      </ul>
+      <span style="font-weight: bold;">Travailler sur le code </span><br>
+      <ul>
+        <li>Guide du codage (.sxw)<br>
+        </li>
+        <li>Checklist pour la revue de l'interface C++ (.sxw)</li>
+        <li>Debugguer OpenOffice.org avec Valgrind (.sxw)</li>
+        <li>Si vous avez du CPU à dépenser, vous pouvez envisager
+d'exécuter un <a href="http://ooo.ximian.com/tinderbox-setup.html">tinderbox
+slave<br>
+          </a>Mettre en place des compilations tinderbox avec la chaine
+d'outils standards ou peut-être la nouvelle chaine d'outils pour toutes
+les plateformes principales (x86 Linux, Solaris Sparc et Windows) et
+permettre aux développeurs volontaires de voir les logs des erreurs de
+compilation et les progrès devrait finalement permettre aux
+développeurs d'avoir moins peur de faire un commit de quoi que ce soit
+(fixes ou améliorations) et de ne pas avoir peur de casser quelque
+chose pour les autres plateformes.</li>
+      </ul>
+      <span style="font-weight: bold;">Description des outils</span><br>
+      <ul>
+        <li>Description d'Auto-doc (génération automatique de
+documentation)<br>
+(pour <a href="autodoc_cpp.html">C++</a> et UNO-IDL ; <a
+ href="command_line_syntax_fr.htm">syntaxe en ligne de commande</a>)</li>
+        <li><a href="howto_write_doc_format_ooo1.0.sxw">Comment
+documenter le code source C++ pour AutoDoc</a> (traduction E. Bachar,
+auteur Nikolai Pretzell)<br>
+        </li>
+      </ul>
+      <span style="font-weight: bold;">Performance et profilage</span><br>
+Outils pour mesurer les performances et tâches relatives<br>
+      <ul>
+        <li>Performance et outils</li>
+        <li>outils de profilage</li>
+      </ul>
+      <span style="font-weight: bold;">Assurance Qualité (QA)</span><br>
+QA est un <a href="http://qa.openoffice.org/">projet</a> séparé. Le
+projet d'Assurance Qualité francophone est <a href="../QA-test2.html">ici</a>
+      <br>
+      <ul>
+        <li><a href="../QA-fr/index1.html">Description</a> des
+smokes-test</li>
+        <li><a href="../about-issuezilla.html">Guide</a> pour écrire
+des rapports de bugs</li>
+      </ul>
+      <span style="font-weight: bold;">Engénierie des versions</span><br>
+      <ul>
+        <li>Vue d'ensemble des <a
+ href="http://development.openoffice.org/releases/oo_branches.pdf">Branches
+et de la feuille de route d'OpenOffice.org</a> et description des
+branches</li>
+        <li><a
+ href="http://eis.services.openoffice.org/EIS2/servlet/GuestLogon">Environnement
+Information System</a> est une interface pour naviguer dans les Child
+Workspace (CWS)</li>
+        <li>Schéma de nommage des fichiers<br>
+        </li>
+      </ul>
+      <span
+ style="font-weight: bold; font-family: helvetica,arial,sans-serif; color: rgb(255, 255, 255);"></span><br>
+      <p style="margin-bottom: 0.5cm;"><font
+ face="Helvetica, Arial, sans-serif"><a href="../index.html">Retour à
+la page d'accueil</a><a href="../site_fr/fr/www/faq-fr.html"><br>
+      </a></font></p>
+<!-- /Table Navigation Bar --> <br>
+      </td>
+    </tr>
+    <tr>
+      <td align="right" valign="bottom">
+      <p>&nbsp;</p>
+<!-- Copyrights -->
+      <p><small>OpenOffice.org native tongue concept and francophone
+project are built for you with pride by Guy Capra (Alomphega).<br>
+This fr project is also led and maintained by Sophie Gautier.</small></p>
+<!-- /Copyrights --> </td>
+    </tr>
+  </tbody>
+</table>
+<br>
+<br>
+<br>
+<br>
+<br>
+<br>
+</body>
+</html>

Propchange: incubator/ooo/ooo-site/trunk/content/fr/Laboratory/indexlabo.html
------------------------------------------------------------------------------
    svn:eol-style = native

Added: incubator/ooo/ooo-site/trunk/content/fr/Laboratory/layers.png
URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/fr/Laboratory/layers.png?rev=1195287&view=auto
==============================================================================
Binary file - no diff available.

Propchange: incubator/ooo/ooo-site/trunk/content/fr/Laboratory/layers.png
------------------------------------------------------------------------------
    svn:mime-type = image/png

Added: incubator/ooo/ooo-site/trunk/content/fr/Laboratory/overview_codeline.html
URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/fr/Laboratory/overview_codeline.html?rev=1195287&view=auto
==============================================================================
--- incubator/ooo/ooo-site/trunk/content/fr/Laboratory/overview_codeline.html (added)
+++ incubator/ooo/ooo-site/trunk/content/fr/Laboratory/overview_codeline.html Mon Oct 31 00:18:42 2011
@@ -0,0 +1,197 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html>
+<head>
+  <title>Labo</title>
+  <meta http-equiv="content-type" content="text/html; charset=UTF-8">
+</head>
+<body>
+<table border="0" cellpadding="4" width="100%">
+  <tbody>
+    <tr>
+      <td align="left" valign="top" width="100%"><!-- Content --><span
+ style="font-family: helvetica,arial,sans-serif;"></span>
+      <h2>OpenOffice.org Branches de Code</h2>
+      <ul>
+        <li>&nbsp; OpenOffice.org <a
+ href="../Labo/fran%E7ais/ooo_roadmap.pdf">Gestion du Développement</a>
+          <br>
+          <ul>
+            <li>
+              <p><a href="../Labo/fran%E7ais/OpenOffice_org_trunk.html">OpenOffice.org
+2.0
+Branches</a><br>
+              </p>
+            </li>
+            <ul>
+              <li>
+                <p>Brouillon du Document Concept du Produit ( <a
+ href="../Labo/fran%E7ais/q-concept.html">html</a>, <a
+ href="../Labo/fran%E7ais/q-concept.pdf">pdf</a>, <a
+ href="../Labo/fran%E7ais/q-concept.sxw">sxw</a> )</p>
+              </li>
+              <li><a
+ href="http://development.openoffice.org/releases/OOo_2_0_timetable.html">Planning</a>
+du développement de la version 2.0 en cours<br>
+              </li>
+            </ul>
+            <li>
+              <p><a href="../Labo/fran%E7ais/OpenOffice_org_1_x.html">OpenOffice.org
+1.1.x
+Branches</a> (vous trouverez <a
+ href="../Labo/fran%E7ais/oo_branches.pdf">ici</a> les anciennes&nbsp;
+Branches de OpenOffice.org 1.0/1.1) </p>
+            </li>
+            <ul>
+              <li>
+                <p><a
+ href="http://www.openoffice.org/servlets/ReadMsg?msgId=228241&amp;listName=discuss">Objectifs
+de
+Développement</a> pour 1.1 </p>
+              </li>
+              <li>
+                <p><a
+ href="http://www.openoffice.org/dev_docs/features/1.1/features-text.html">Caractéristiques</a></p>
+              </li>
+              <li>
+                <p>Tinderbox pour <a
+ href="http://ooo.ximian.com/tinderbox/SRX643_OO/status.html">SRX643_OO</a>,
+ajouter <a href="javascript:addNetscapePanel_643();">le statut de
+Tinderbox</a>
+à votre barre latérale Mozilla&nbsp;<br>
+                </p>
+              </li>
+            </ul>
+            <li>
+              <p><a href="../Labo/fran%E7ais/OpenOffice_org_1_0.html">Branches
+OpenOffice.org
+1.0.x</a> </p>
+              <ul>
+                <li>
+                  <p><a href="../Labo/fran%E7ais/changelog.html">changelog</a>
+pour la version 1.0.x. </p>
+                </li>
+                <li>
+                  <p><a
+ href="http://www.openoffice.org/dev_docs/source/features.html">Caractéristiques</a>
+                  </p>
+                </li>
+                <li>
+                  <p>Tinderbox pour <a
+ href="http://ooo.ximian.com/tinderbox/OOO_STABLE_1/status.html">OOO_STABLE_1</a>,
+ajouter <a href="javascript:addNetscapePanel();">le statut de Tinderbox</a>
+à
+votre barre latérale Mozilla</p>
+                </li>
+              </ul>
+            </li>
+          </ul>
+        </li>
+      </ul>
+      <ul>
+        <li>OpenOffice.org <a
+ href="../Labo/fran%E7ais/Target_Milestone.html">Cibles de Développement</a><br>
+        </li>
+      </ul>
+      <br>
+      <br>
+      <script language="JavaScript"> 
+
+
+
+   function addNetscapePanel() { 
+
+      if ((typeof window.sidebar == "object") && (typeof window.sidebar.addPanel == "function")) 
+
+      { 
+
+         window.sidebar.addPanel ("Tinderbox: OOO_STABLE_1", 
+
+         "http://ooo.ximian.com/tinderbox/OOO_STABLE_1/panel.html",""); 
+
+      } 
+
+      else 
+
+      { 
+
+         var rv = window.confirm ("Cette page a été conçue pour une utilisation avec Netscape 6/7.  " 
+
+            + "Aimeriez-vous vous mettre à jour maintenant?"); 
+
+         if (rv) 
+
+            document.location.href = "http://home.netscape.com/download/index.html";
+
+      } 
+
+   } 
+
+
+   function addNetscapePanel_643() { 
+
+      if ((typeof window.sidebar == "object") && (typeof window.sidebar.addPanel == "function")) 
+
+      { 
+
+         window.sidebar.addPanel ("Tinderbox: SRX643_OO", 
+
+         "http://ooo.ximian.com/tinderbox/SRX643_OO/panel.html",""); 
+
+      } 
+
+      else 
+
+      { 
+
+         var rv = window.confirm ("Cette page a été conçue pour une utilisation avec Netscape 6/7.  " 
+
+            + "Aimeriez-vous vous mettre à jour maintenant?"); 
+
+         if (rv) 
+
+            document.location.href = "http://home.netscape.com/download/index.html";
+
+      } 
+
+   } 
+
+//--> 
+
+      </script>
+      <p> La distribution est gérée par le <a
+ href="file:///project/distribution/index.html">projet Distribution</a>
+et
+suit les directives pour la <a
+ href="http://distribution.openoffice.org/mirrors/#directory">structure
+de répertoire</a> and <a
+ href="file:///project/development/releases/filenames.html">file naming</a>.<br>
+      </p>
+      <p>Traduction Alex Thurgood<br>
+      </p>
+      <p style="font-family: helvetica,arial,sans-serif;"><a
+ href="indexlabo.html">Retour à l'index du Labo<br>
+      </a></p>
+      <a href="indexlabo.html"><span
+ style="font-weight: bold; color: rgb(255, 255, 255); font-family: helvetica,arial,sans-serif;"></span></a><!-- /Table Navigation Bar -->
+      <br>
+      </td>
+    </tr>
+    <tr>
+      <td align="right" valign="bottom">
+      <p>&nbsp;</p>
+<!-- Copyrights -->
+      <p><small>OpenOffice.org native tongue concept and francophone
+project are built for you with pride by Guy Capra (Alomphega).<br>
+This fr project is also led and maintained by Sophie Gautier.</small></p>
+<!-- /Copyrights --> </td>
+    </tr>
+  </tbody>
+</table>
+<br>
+<br>
+<br>
+<br>
+<br>
+<br>
+</body>
+</html>

Propchange: incubator/ooo/ooo-site/trunk/content/fr/Laboratory/overview_codeline.html
------------------------------------------------------------------------------
    svn:eol-style = native

Added: incubator/ooo/ooo-site/trunk/content/fr/Laboratory/second_plan.html
URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/fr/Laboratory/second_plan.html?rev=1195287&view=auto
==============================================================================
--- incubator/ooo/ooo-site/trunk/content/fr/Laboratory/second_plan.html (added)
+++ incubator/ooo/ooo-site/trunk/content/fr/Laboratory/second_plan.html Mon Oct 31 00:18:42 2011
@@ -0,0 +1,289 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html>
+<head>
+  <title>Labo</title>
+  <meta http-equiv="content-type" content="text/html; charset=UTF-8">
+</head>
+<body>
+<table border="0" cellpadding="4" width="100%">
+  <tbody>
+    <tr>
+      <td align="left" valign="top" width="100%"><!-- Content -->
+      <h3><font face="Helvetica, Arial, sans-serif"><b>Informations
+de second plan</b></font></h3>
+Cette section vous fournit des informations de second plan sur le
+processus de compilation de Star/OpenOffice.org. Notez que StarOffice
+et OpenOffice.org sont développés ensemble mais sont deux produits
+différents, pour plus de détails, voir les<a
+ href="http://www.openoffice.org/license.html"> licences</a> et la <a
+ href="http://www.openoffice.org/FAQs/faq-questions.html#licensing">FAQ</a>.
+Quelques
+parties de StarOffice utilisent du code tiers qui ne
+peut être utilisé avec OpenOffice.org. Des parties de ce code ont
+été remplacées par du code OpenSource et certaines parties restent à
+l'état de futur projet, par exemple la vérification grammaticale.<br>
+Ce document est séparé suivant ces différentes sections<br>
+      <ul>
+        <li><a href="#Branches_source_et_branche_de_sortie_">Branches
+sources et solver</a></li>
+        <li><a href="#Utilisation_de_proc%C3%A9dures_de_compilation">Utilisation
+de procédures de compilations identiques</a></li>
+        <li><a href="#Compilation_des_release_Engineering">Compilation
+Release Engineering</a></li>
+        <li>Développer dans le projet OpenOffice.org</li>
+      </ul>
+      <h3><a name="Branches_source_et_branche_de_sortie_"></a>Branches
+source et branches de sortie (solver)<br>
+      </h3>
+Les développeurs OpenOffice.org travaillent en parallèle sur toutes les
+plateformes. Le code source pour toutes les plateformes est identique,
+avec des exceptions pour le code de l'interface du système
+d'exploitation et du fenêtrage. Cela vous permet de compiler sur
+différentes plateformes simultanément à partir d'une seule <span
+ style="font-weight: bold;">branche source</span>, i.e. la structure du
+répertoire qui stocke tout le code source pour la suite bureautique.<br>
+      <br>
+La branche <code>solenv</code> contient les outils d'environnement que
+le processus de compilation utilise, pour toutes les plateformes
+supportées. A l'origine, elle contient également&nbsp; les outils de
+compilation spécifiques à la plateforme. Maintenant, ces outils de
+compilation sont créés à partir d'un script <code>bootstrap</code>
+créé avec le script <code>configure</code>.<br>
+      <br>
+Le processus de compilation génère les fichiers à partir de la branche
+source et les copie dans une branche de sortie, i.e une structure de
+répertoire qui stocke tout le code source pour la suite bureautique.<br>
+      <br>
+Lorsque vous exécutez <code>bootstrap</code>, le répertoire <code>solver</code>
+est créé. Initiallement, le répertoire <code>solver</code> est vide.
+Le processus de compilation peuple le répertoire. Le processus de
+compilation délivre tous les fichiers binaires, les librairies
+partagées, et les liens dynamiques des librairies au <code>solver</code>.<br>
+      <br>
+Lorsque vous souhaitez compiler un projet spécifique, vous n'avez
+besoin
+que des sources du module CVS correspondant et de la branche de sortie <code>solver</code>.
+Vous n'avez pas besoin de la branche source complète, ainsi,
+typiquement, un développeur va faire un check out d'une seule <a
+ href="http://tools.openoffice.org/builds">branche</a> et va la
+compiler complètement.<br>
+      <br>
+Pour plus d'informations sur les branches <code>solenv </code>et <code>solver</code>,
+voir le <a href="http://tools.openoffice.org/">projet Tools</a><br>
+      <h3><a name="Utilisation_de_procédures_de_compilation"></a>Utilisation
+de procédures de compilation identiques</h3>
+Le processus de compilation pour OpenOffice.org est identique sur
+toutes les plateformes.<br>
+      <br>
+Un outil de conception OpenOffice.org appelé <code>dmake</code>
+contrôle le
+processus de compilation.<br>
+      <br>
+Il y a des <code>makefiles</code> (makefile.mk) et des fichiers de
+compilation de
+projet <code>prj/build.lst</code>, qui prennent en charge les
+interdépendances des
+modules et des répertoires à travers la branche source. Les même <code>makefiles
+      </code>sont utilisés pour toutes les
+plateformes. Les macros
+utilisées contrôlent d'éventuelles étapes spécifiques aux plateformes
+dans le processus de compilation. Cela garantie un minimum d'effort
+lors
+du portage vers une nouvelle plateforme dans la mesure où seules les
+macros dans le <code>makefiles </code>ont besoin d'être adaptées. Le
+processus de
+compilation n'a pas besoin de scripts ou de makefiles dépendant des
+plateformes supplémentaires.<br>
+      <br>
+Les développeurs Sart/OpenOffice.org on réécrit la plupart des outils
+de compilation pour rendre l'expérience de compilation d'OpenOffice.org
+la plus proche possible de n'importe quelle autre
+compilation de projet OpenSource. Il en résulte que tous les outils
+utilisés lors du processus sont portables. Les développeurs
+OpenOffice.org en ont écrits certains, les autres sont des outils open
+source standards, habituellement des utilitaires GNU.<br>
+      <br>
+L'outil <code>dmake </code>est un utilitaire de conception similaire
+à GNU <code>make </code>ou
+du Workshop Compiler <code>dmake</code>. Cet utilitaire à une syntaxe
+irrégulière
+mais est disponible à partir des sources sur toutes les plateformes. La
+version OpenOffice.org de <code>dmake </code>est une version modifiée
+du freeware
+original <code>dmake</code>.<br>
+      <br>
+Lorsque vous exécutez <code>dmake </code>à partir du répertoire
+supérieur de la
+branche source, tous les modules sont contruits. Ceci est possible
+simplement en exécutant le <code>build -all</code>&nbsp; dans le
+répertoire <code>instsetoo</code>. Les commandes de compilation sont
+décrites dans une autre <a
+ href="http://tools.openoffice.org/build_env_tools.html">documentation</a>.
+Il y a beaucoup de dépendances entre les modules, aussi <code>build </code>doit
+les
+compiler dans un certain ordre. L'outil <code>dmake </code>compile
+les répertoires
+différents dans les modules, il délivre ensuite toutes les entêtes de
+fichier, les entêtes de fichiers générés, les fichiers binaires, les
+librairies partagées, les ressources et ainsi de suite, à la branche <code>solver</code>.<br>
+      <br>
+Pour plus d'information sur l'outil <code>dmake</code>, voir le <a
+ href="http://tools.openoffice.org/">projet Tools</a>.<br>
+      <h3><a name="Compilation_des_release_Engineering"></a>Compilation
+des release Engineering</h3>
+La branche source OpenOffice.org est structurée en projets.<br>
+      <br>
+Un projet compile un composant particulier de la suite openoffice.org.
+Par exemple, le projet Writer compile l'application Writer. Un projet
+est une application, une fonction ou simplement un sommaire de classes.
+Un projet peut être subdivisé en modules. Un module est une petite
+unité de la suite qui peut être compilée.<br>
+      <br>
+Les modules correspondent au répertoire sous le répertoire de niveau
+supérieur de la branche source. Par exemple, le projet Writer inclut
+les modules : sw, starmath, res, etc.<br>
+Pour déterminer à quel projet appartient un module, regarder dans les
+fichiers CVS/Repository. Par exemple :<br>
+      <pre>froddo: /data2/office<br>$ cd config_office<br><br>froddo: /data2/office/config_office<br>$ cat CVS/Repository<br>tools/config_office</pre>
+Nous vérifions que&nbsp; le répertoire (module) <code>config_office</code>
+fait
+partie du projet tools.<br>
+      <br>
+Il y a beaucoup de dépendances entre les modules et les modules doivent
+être construits dans un ordre particulier. Les prérequis pour les
+modules sont décrits dans la première ligne du ficheir <code>prj/build.lst</code>
+par exemple.<br>
+      <pre>froddo: /data2/office/sw/prj<br>$ cat build.lst<br>sw      sw      :       connectivity svx stoc uui sch NULL</pre>
+      <br>
+      <br>
+Nous trouvons que sw dépend de connectivity, etc. Ces modules à leur
+tour, dépendent d'autres, créant un arbre large et complexe.<br>
+      <h3>Compilations complètes</h3>
+Les développeurs OpenOffice.org réalisent une compilation complète pour
+compiler leurs modules. Une compilation complète recompile également
+tout le code source. Cela peut prendre jusqu'à 16 heures de réaliser
+une compilation complète de OpenOffice.org. Utiliser des outils comme <code>distcc
+      </code>et <code>ccache </code>peut conséquemment
+allonger le temps de compilation.<br>
+Pour éviter d'avoir à recompiler une version complète à chaque fois
+qu'un
+changement de code est introduit, il est demandé aux développeurs
+d'introduire uniquement des changements binaires compatibles à moins
+que le responsable du projet ait donné son accord (insérer une méthode
+nouvelle, non virtuelle dans une class C++ serait un exemple d'un tel
+changement binaire compatible). La suite bureautique sera alors
+recompilée comme une version respin avant que la prochaine master soit
+déclarée. Une version respin obéit uniquement à des dépendances weak,
+ie : dépendances à l'intérieur d'un module. Utiliser des dépendances
+weak vous permet, par exemple, de modifier une librairie de base d'un
+fichier head sans avoir besoin de réaliser une compilation complète.
+Dans la mesure où une compilation respin est basée sur des
+modifications
+binaires compatibles, les modules peuvent être construits en parallèle
+et la compilation prend beaucoup moins de temps (quelques heures)
+contrairement à une compilation complète.<br>
+      <br>
+Au contraire, les changements binaires incompatibles demandent une
+compilation complète. Pour des raisons d'efficacité, c'est uniquement
+permis avec l'autorisation du responsable du projet.<br>
+      <br>
+      <h3>Snapshots/Milestone compilations</h3>
+Le passage suivant est une illustration de la façon dont les
+développeurs OpenOffice.org contribuent au projet. Supposons que vous
+souhaitiez&nbsp; mettre à jour une méthode appelée xyz qui est définie
+dans le module svtools. Supposons aussi que le module svx utilise la
+métode xyz. Vous pouvez procéder de la façon suivante :<br>
+      <ol>
+        <li>Télécharger le tarball du solver correspondant à la version
+et à la plateforme sur laquelle vous souhaitez développer.</li>
+        <li>Faites un check out des utilitaires du projet sur la
+branche CVS. Cela copie le module svtools dans votre environnement
+local.</li>
+        <li>Mettez à jour la méthode dans le module svtools</li>
+        <li>Vérifiez les effets de la mise à jour de la méthode dans
+les autres modules. Vous souhaitez alors vérifier combien d'autres
+modules utilisent la méthode xyz. Cela peut être difficile de
+l'établir. Vous en arrivez à la conclusion que seulement le module svx
+utilise la méthode xyz. Si vous pensez que vous pouvez faire une
+modification compatible, vous pouvez continuer.</li>
+        <li>Faites les changements de méthode xyz dans le module
+svtools.</li>
+        <li>Compilez svtools, cela produit une sortie dans la branche
+de
+sortie appropriée.</li>
+        <li>Dans le modules svx, faites les changements correspondants
+aux modifications apportées au svtools.</li>
+        <li>Compilez svx, cela produit une sortie dans la branche de
+sortie appropriée.</li>
+        <li>Testez vos patches</li>
+        <li>Un volontaire de la communauté ou le responsable du projet
+vérifie vos patches, fait des commentaires ou les approuve</li>
+        <li>les patches sont alors committés dans la branche CVS.</li>
+      </ol>
+Note : un autre projet que vous n'avez pas vérifié peut porter le même
+nom de méthode.<br>
+      <br>
+      <h3>Astuces pour éviter de casser une build</h3>
+Lorsque vous développez dans OpenOffice.org, votre code doit respecter
+l'ordre dans lequel les modules sont construits. Autrement, vous
+risquez de créer une dépendance circulaire. Une dépendance circulaire
+est créer, lorsque un module essaye d'utiliser une fonctionnalité d'un
+autre module qui est construit ultérieurement.<br>
+      <br>
+Par exemple, si vous modifiez le module sot de manière à ce qu'il
+utilise des entêtes ou des fichiers de librairie dépendants du module
+toolkit. Le module toolkit est construit après le module sot, et dépend
+indirectement de celui-ci. Lorsque le module sot réferre au module
+toolkit, il en devient dépendant et une référence circulaire est créée.
+Cela cassera la compilation et une autre solution devra être trouvée.<br>
+      <br>
+Notez que la processus de build compile un répertoire complet et
+ensuite construit le répertoire suivant.<br>
+      <br>
+Lorsque vous travaillez à l'intérieur d'un module, votre code doit
+respecter la structure existante du module, de la manière suivante :<br>
+      <ul>
+        <li>Séparez la compilation des objets des librairies liées.
+Créez des liens dans le répertoire utils le plus possible. Cela vous
+permet également de retrouver facilement la cible des liens. <br>
+        </li>
+        <li>Pour réduire le temps de compilation, conservez des tailles
+raisonnables pour les sous répertoires de sources, c'est à dire moins
+de 50 fichiers.</li>
+        <li>Lorsque plus d'un répertoire utilise une entête ou un
+fichier de librairie, placez le fichier dans le répertoire inc. Lorsque
+vous compilerez, cela apparaîtra dans le répertoire module-name/inc de
+la branche de sortie liée après la phase de sortie du process de
+compilation.</li>
+      </ul>
+      <br>
+      <span
+ style="font-weight: bold; font-family: helvetica,arial,sans-serif; color: rgb(255, 255, 255);"></span>Traduction
+Sophie Gautier<br>
+      <br>
+      <p style="margin-bottom: 0.5cm;"><font
+ face="Helvetica, Arial, sans-serif"><a href="indexlabo.html">Retour à
+l'index Labo<br>
+      </a></font></p>
+<!-- /Table Navigation Bar --> <br>
+      </td>
+    </tr>
+    <tr>
+      <td align="right" valign="bottom">
+      <p>&nbsp;</p>
+<!-- Copyrights -->
+      <p><small>OpenOffice.org native tongue concept and francophone
+project are built for you with pride by Guy Capra (Alomphega).<br>
+This fr project is also led and maintained by Sophie Gautier.</small></p>
+<!-- /Copyrights --> </td>
+    </tr>
+  </tbody>
+</table>
+<br>
+<br>
+<br>
+<br>
+<br>
+<br>
+</body>
+</html>

Propchange: incubator/ooo/ooo-site/trunk/content/fr/Laboratory/second_plan.html
------------------------------------------------------------------------------
    svn:eol-style = native

Added: incubator/ooo/ooo-site/trunk/content/fr/Mac/faq103.htm
URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/fr/Mac/faq103.htm?rev=1195287&view=auto
==============================================================================
--- incubator/ooo/ooo-site/trunk/content/fr/Mac/faq103.htm (added)
+++ incubator/ooo/ooo-site/trunk/content/fr/Mac/faq103.htm Mon Oct 31 00:18:42 2011
@@ -0,0 +1,47 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html>
+<head>
+  <title>FAQ_item</title>
+
+
+  <meta http-equiv="content-type" content="text/html; charset=UTF-8">
+
+</head>
+
+
+<body>
+
+<h2>FAQ Mac pour l'utilisation d'OpenOffice.org sous Mac OS X (X11)</h2>
+
+<br>
+
+<span style="font-weight: bold;"><br>
+
+ATTENTION</span> : La FAQ est d&eacute;sormais disponible sur
+le wiki : <br>
+
+<ul>
+
+  <li><a href="http://wiki.services.openoffice.org/wiki/Fr.openoffice.org/FAQ">http://wiki.services.openoffice.org/wiki/Fr.openoffice.org/FAQ</a></li>
+
+  <li><a href="http://wiki.services.openoffice.org/wiki/Fr.openoffice.org/FAQ/Mac">http://wiki.services.openoffice.org/wiki/Fr.openoffice.org/FAQ/Mac</a></li>
+
+</ul>
+
+<br>
+
+<br>
+
+<br>
+
+<!-- Copyrights -->
+<p><small>OpenOffice.org native tongue concept and
+francophone project are built for you with pride by Guy Capra
+(Alomphega).<br>
+
+This fr project is also led and maintained with pride too by Sophie
+Gautier.</small></p>
+
+<!-- /Copyrights -->
+</body>
+</html>



Mime
View raw message