URL: https://linuxfr.org/news/libreoffice-4-3-est-sorti Title: LibreOffice 4.3 est sorti Authors: woprandi Syvolc, coid, Davy Defaud, Crao, Nÿco, kpet, palm123, j, Benoît Sibaud, bobble bubble, ariasuni, ZeroHeure, BAud, Frédéric Massot, patrick_g, jcr83, skone, NeoX, Bruno Michel, rootix, azerttyu, phoenamandre et Nonolapéro Date: 2014年07月30日T18:31:00+02:00 License: CC By-SA Tags: bureautique, libreoffice et coulisses Score: 85 [[LibreOffice]] 4.3 vient d’être publié en ce 30 juillet 2014. Cette nouvelle version est destinée aux utilisateurs expérimentés — les autres, comme les entreprises et les administrations, sont invités à utiliser LibreOffice 4.2.6. ![Titre de l'image](//img.linuxfr.org/img/68747470733a2f2f77696b692e646f63756d656e74666f756e646174696f6e2e6f72672f696d616765732f372f37372f4c696272654f66666963655f65787465726e616c5f6c6f676f5f33303070782e706e67/LibreOffice_external_logo_300px.png) [Michael Meeks](https://en.wikipedia.org/wiki/Michael_Meeks_%28software_developer%29) est un développeur qui travaille sur la suite bureautique LibreOffice pour l’éditeur [Collabora](https://en.wikipedia.org/wiki/Collabora). Il vient de publier sur [son _blog_](http://www.gnome.org/~michael/blog/2014-07-29-under-the-hood-4-3.html) une longue description du travail de refactorisation et de nettoyage qui a eu lieu lors de ce cycle de développement menant à la version 4.3 de LibreOffice. Cette dépêche est une traduction de son article initialement publié dans le domaine public ou licence [CC0](http://fr.wikipedia.org/wiki/Licence_CC0), comme indiqué au bas de l’article. ---- [Article original](https://people.gnome.org/~michael/blog/2014-07-29-under-the-hood-4-3.html) [Nouveautés de LibreOffice 4.3 (notes de version)](https://wiki.documentfoundation.org/ReleaseNotes/4.3/fr) [LibreOffice](http://fr.libreoffice.org) [LinuxFr : Ascension de la bureautique libre en Europe de l’ouest](http://linuxfr.org/news/ascension-de-la-bureautique-libre-en-europe-de-l-ouest) [LinuxFr : Sortie de LibreOffice 4.2](https://linuxfr.org/news/libreoffice-4-2-0-est-disponible) ---- Aujourd’hui, nous publions LibreOffice 4.3.0, livré avec beaucoup de nouvelles fonctionnalités que vous allez aimer. Vous pouvez lire et apprécier toutes les nouveautés visibles apportées par tant de développeurs. Mais il y a aussi des contributeurs dont le travail se fait principalement en arrière-plan et dont les résultats ne sont pas si faciles à voir. Pourtant ces développements sont aussi vitaux pour le projet. Mais il peut être difficile de les distinguer parmi les quatorze mille _commits_ faits depuis LibreOffice 4.2, alors laissez‐moi détailler : # Interface utilisateur La migration de l’interface utilisateur depuis les composants graphiques [VCL](http://cgit.freedesktop.org/libreoffice/core/tree/vcl) vers [[Glade]] approche finalement de sa fin. Plus de deux cents boîtes de dialogues ont été converties dans cette version, les boîtes restantes étant les plus dures à trouver — [de l’aide serait d’ailleurs appréciée](https://wiki.documentfoundation.org/Development/WidgetLayout/FindDialogs). Grands mercis à _Caolán McNamara (Red Hat) pour son incroyable travail ici, et également à Szymon Kłos, Michal Siedlaczek, Olivier Hallot (EDX), Andras Timar (Collabora), Jan Holesovsky (Collabora), Katarina Behrens, Thomas Arnhold, Maxim Monastirsky, Manal Alhassoun, Palenik Mihály, et beaucoup d’autres_... Merci aussi à nos traducteurs qui ont aidé à la migration des chaînes de caractères. ![UI Layout dialog Conversion](http://people.gnome.org/~michael/images/2014-07-15-ui-layout.png) Si vous souhaitez vous impliquer pour arriver à 100 % de conversion, allez voir le [_howto_](http://caolanm.blogspot.ie/2013/01/converting-libreoffice-dialogs-to.html) de Caolán et son superbe _blog_ : [_99 to go update_](http://caolanm.blogspot.ie/2014/06/dialog-conversion-status-99-to-go.html) ([plus que 54 au 25 juillet](http://caolanm.blogspot.ie/2014_07_01_archive.html)), illustré par ceci : ![Titre de l'image](http://3.bp.blogspot.com/-9Sqmxek2qFU/U6GwOe1dC5I/AAAAAAAAAow/JpyL9AAGIoY/s1600/Barge-Haulers-on-the-Volga-by-Ilya-Repin.jpg) # Améliorations de la compilation LibreOffice est beaucoup plus facile à compiler, et cette étape est mieux documentée — cela est important pour les nouveaux contributeurs ## Prise en charge de Visual Studio Non seulement _Jesus Corrius_ a ajouté la prise en charge initiale de Visual Studio 2013, mais nous avons fait une avancée majeure grâce à _Honza Havlíček_ qui, utilisant un travail similaire de Bjoern Michaelsen (Canonical) sur [KDevelop](http://skyfromme.wordpress.com/2013/12/04/libreoffice-ide-integration/), a implémenté la compilation depuis un fichier projet Visual Studio, permettant une amélioration importante de la compilation et du débogage : voyez la [vidéo](https://www.youtube.com/watch?v=Xn3CtIrMpIA) ou tapez juste : `make vs2012-ide-integration`. ## Dépendance à l’exécution sur OpenGL Dans le passé nous avions un chemin de code spécifique à OpenGL que l’on compilait dans une bibliothèque partagée liée à OpenGL, puis l’on chargeait dynamiquement ce composant — comme, par exemple, pour le diaporama en OpenGL. Dans la version 4.3, nous avons unifié tout notre code OpenGL pour utiliser _glew_, et nous avons maintenant une interface de programmation (API) VCL centrale pour s’initialiser et se lier à OpenGL, permettant une utilisation beaucoup plus facile dans le futur. Un autre bénéfice à l’utilisation de _glew_ est la possibilité de vérifier dynamiquement les extensions OpenGL en cours d’exécution, pour mieux les adapter aux capacités de votre plate‐forme plutôt que de se limiter aux fonctions de base. ## En‐têtes pré‐compilés et mises à jour de PCH _Thomas Arhnold_ a découvert que nos fichiers _pch_ (utilisés pour accélérer la compilation sous Windows) se sont détériorés, et a fait un bon ménage parmi eux. Cela a accéléré significativement le temps de compilation pour un certain nombre de modules. ![Titre de l'image](http://people.gnome.org/~michael/images/2014-07-15-pch.png) ## Réduction de la taille de code mobile Beaucoup de travail a été effectué dans LibreOffice 4.3 pour nous permettre de diminuer la taille du code et l’adapter à la taille mémoire des plates‐formes mobiles. Merci à _Matus Kukan (Collabora)_ qui a découpé un grand nombre de composants UNO en différentes fonctions de construction, ce qui permet à l’éditeur de liens de supprimer les composants non utilisés. Matus a également créé un script Python `solenv/bin/native-code.py` pour partager les listes de compilations de composants liés statiquement dans diverses combinaisons de fonctionnalités. _Tor Lillqvist (Collabora)_ a retravaillé ICU pour empaqueter les tables de données, qui sont globalement assez grandes, dans un fichier plutôt que dans le code. _Vincent Saunders (Collabora)_ a pas mal travaillé pour améliorer `dwarfprofile`, afin d’identifier les plus gros morceaux de fichiers objets et savoir d’où ils venaient. _Jan Holesovsky_ a découplé beaucoup de code concernant l’accessibilité et supprimé beaucoup de variables statiques non nécessaires dans certaines parties du code. _Miklos Vajna_ a transformé les _OOXML custom shape preset definitions_ (`oox::drawingml::CustomShapeProperties::PresetsMap`) de code généré à donnée générée : cela a permis la suppression de 50 000 lignes de code. Grand merci à son auteur, _Tsahi Glik_, et CloudOn, pour avoir financé ce travail. # Travail sur la qualité du code Il y a eu beaucoup de travail sur la qualité du code, et pour améliorer la maintenabilité et la propreté de ce code. Nous remercions _Julien Nabet_ pour les (à peu près) 75 correctifs concernant les erreurs **cppcheck**, et pour les _commits_ quotidiens, ce qui a permis d’avoir des compilations sans alertes sur toutes les plates‐formes. Merci également à _Tor Lillqvist (Collabora), Caolán McNamara (Red Hat), et Thomas Arnhold_. ## Utilisation de _assert_ Un autre outil que les développeurs utilisent pour s’assurer qu’ils n’introduisent pas de nouveaux bogues sont les assertions (_asserts_). Historiquement le code _OOo_ a eu un système d’assertions spécifique qu’on peut facilement occulter, ce qu’ont fait la plupart des développeurs. Grâce à _Stephan Bergmann (Red Hat)_, nous avons commencé à utiliser les macros standards `assert()` dans LibreOffice, ce qui a l’énorme avantage qu’elles arrêtent le programme : si une assertion est fausse, le développeur voit un plantage, ce dont il est plutôt difficile de ne pas se rendre compte, comparé à du texte s’affichant dans le terminal. Grands mercis à tous ceux qui ont rendu efficientes les assertions. ![Titre de l'image](http://people.gnome.org/~michael/images/2014-07-15-asserts.png) ## Coverity Nous avons été submergés par l’énorme quantité d’analyses venant de [_Coverity Scan_](https://scan.coverity.com/), et _Caolán McNamara (Red Hat)_, en particulier, a fait un travail incroyable ici ; son [_blog_](http://caolanm.blogspot.ie/2014/07/libreoffice-coverity-defect-density.html) sur ce sujet est, comme à l’accoutumée, modeste. Nous avons maintenant une densité de défauts (nombre de défauts par 1 000 lignes de code) de 0,08, ce qui signifie 8 bogues pour 100 000 lignes de code trouvés par l’analyse statique. Ceci se compare favorablement avec les projets libres de cette taille qui contiennent en moyenne 65 bogues pour 100 000 lignes. Peut‐être que le plus utile dans les rapports Coverity sont les nouveaux problèmes signalés, car beaucoup d’entre eux sont plus sérieux que les précédents rapports de basse priorité en vrac. Ceci a été réalisé avec 2 679 _commits_, 88 % d’entre eux venant de _Caolán_, puis ensuite _Norbert Thiebaud, Miklos Vajna (Collabora), Noel Grandin, Stephan Bergmann (Red Hat), Chris Sherlock, David Tardon (Red Hat), Thomas Arnhold, Steve Yin (IBM), Kohei Yoshida (Collabora), Jan Holesovsky (Collabora), Eike Rathke (Red Hat), Markus Mohrhard (Collabora)_ et _Julien Nabet_. ## Test de l’importation et maintenant de l’exportation Le grand _crash-test_ de _Markus Mohrhard_ sur l’importation et l’exportation a été étendu à plus de 55 000 documents contenant des problèmes ou suscitant des bogues, et couvre maintenant l’importation PDF. Le nombre de crashs et de problèmes de validation continue à diminuer. Markus a également réécrit et simplifié le script de test en Python. Cependant nous avons régulièrement des soucis avec ce test (qui tourne pendant 5 jours en utilisant une machine costaude), ce qui bloque plusieurs systèmes GNU/Linux de plusieurs distributions, versions de noyau, à la fois sur du matériel virtuel et réel ; ce qui a un impact négatif sur son utilité. ## Refactorisation des gros objets Dans certains cas, LibreOffice a des classes qui semblent faire « un peu tout », y compris le café. Mercis à _Valentin Kettner, Michael Stahl (Red Hat) et Bjoern Michaelsen (Canonical)_ pour avoir aidé à retravailler ces classes. Par exemple, SwDoc (un document Writer) hérite maintenant de seulement 9 classes au lieu de 19, et l’en‐tête du fichier a diminué de plus de 300 lignes. ## Corrections Valgrind Valgrind s’avère toujours être un outil merveilleux pour trouver et isoler les fuites et les mauvais comportements sur différents morceaux du code, même si les chemins de code normaux sont maintenant plutôt propres. Dave Richards, de Largo, a très gentiment donné du temps processeur sur sa nouvelle machine GNU/Linux à 80 processeurs. Nous utilisons cette machine pour lancer le test d’importation et exportation de Markus sous Valgrind, et trouver et résoudre un certain nombre de problèmes. Les journaux de Valgrind sont [_ici_](http://dev-builds.libreoffice.org/crashtest/memcheck.zip). Nous serions très heureux d’aider les autres pour leurs tests de charge. ## Assainisseur d’adressage et de fuite de mémoire Il y a plein de super nouvelles façons de faire de l’assainissement de code (à la compilation) et, grâce à _Stephan Bergmann (Red Hat)_, nous les utilisons avec enthousiasme. L’option `-fsanitize` est disponible pour Clang et gcc 4.9. Cela nous permet de faire de la vérification mémoire (comme Valgrind), mais avec une visibilité sur la pile corrompue, et de faire ça vraiment beaucoup plus rapidement. Les détails sur [`-fsanitize` pour LibreOffice](https://wiki.documentfoundation.org/Development/-fsanitize) sont disponibles sur le wiki. Beaucoup de fuites et de mauvais comportements ont été résolus grâce à cet outil. Merci également à _Markus Mohrhard_ et _Caolán McNamara_. ## Tests unitaires Nous compilons et exécutons plus de **tests unitaires** avec LibreOffice 4.3, pour éviter les régressions au fur et à mesure du développement. La recherche `grep` sur `CPPUNIT_TEST()` et `CPPUNIT_ASSERT`, comme la dernière fois, montre bien que la tendance à la croissance continue : ![Titre de l'image](http://people.gnome.org/~michael/images/2014-07-15-unit-test.png) Notre idéal est que tous les bogues corrigés soient accompagnés d’un test unitaire, afin qu’ils ne réapparaissent pas. Avec 1 100 correctifs, et plus de 80 participants pour les tests unitaires dans la 4.3, il est difficile de citer toutes les personnes impliquées, je m’excuse pour cela. Ce qui suit est la liste triée de ceux qui ont fait plus de 20 correctifs sur les répertoires `qa/` : _Miklos Vajna (Collabora), Kohei Yoshida (Collabora), Caolán McNamara (Red Hat), Stephan Bergmann (Red Hat), Jacobo Aragunde Pérez (Igalia), Tomaž Vajngerl (Collabora), Markus Mohrhard (Collabora), Zolnai Tamás (Collabora), Tor Lillqvist (Collabora), Michael Stahl (Red Hat)_ et _Alexander Wilms_. ## SAL_OVERRIDE et plus Traditionnellement, C++ autorisait une grosse ambiguïté sur la surcharge des méthodes, permettant l’omission du mot clé « _virtual_ » dans les surcharges et permettant également les surcharges polymorphiques accidentellement. Pour se préparer au nouveau standard C++, nous avons annoté toutes nos méthodes virtuelles qui sont surchargées dans des sous‐classes avec la macro `SAL_OVERRIDE`, pour être sûrs que nous compilons nos _vtables_ correctement. Grands mercis à _Noel Grandin_, et _Stephan Bergmann (Red Hat)_ pour avoir écrit un greffon Clang qui aide à produire ces annotations et un autre pour vérifier que les résultats restent cohérents. Ceci corrige certains bogues présents de longue date. Et comme bonus, quand vous lisez le code, il est beaucoup plus facile de trouver la déclaration de la méthode virtuelle initiale : c’est celle qui n’est pas annotée avec `SAL_OVERRIDE`. QA / bugzilla ------------- Dans cette version, l’équipe assurance qualité a grandi et fait un travail fantastique sur à la fois le tri des bogues et la fermeture de ceux‐ci, nous ramenant sous la valeur ô combien symbolique des 1 000 bogues non triés. Nous avons actuellement environ 750 bogues non confirmés, ce qui est le nombre le plus bas depuis plus de deux ans. Merci à tous pour ce bon travail, malheureusement c’est assez difficile d’extraire les remerciements pour les bogues confirmés, mais la liste des héros recouvre bien la liste des non‐développeurs ayant fermé le plus de bogues (voir plus bas). Nous avons aussi eu un de nos meilleurs week‐ends de chasse aux bogues pour la 4.3, voir ce qu’a [écrit](http://joelmadero.wordpress.com/2014/05/25/successful-bug-hunting-weekend/) _Joel Madero_. L’équipe assurance qualité a également fait un excellent travail en « bissectant » nos dépôts Git pour isoler les régressions à de petits blocs de correctifs, ce qui améliore grandement la vie des développeurs. Un des indicateurs que nous regardons pendant l’_ESC call_ est ce qui est dans le _top 10_ dans le [_Freedesktop Weekly bug summary_](https://bugs.freedesktop.org/page.cgi?id=weekly-bug-summary.html). Voici la liste des 20 personnes qui apparaissent le plus fréquemment dans le _top 10_ des gens fermants le plus de bogues, par ordre de fréquence d’apparition : _Jorendc, Kohei Yoshida (Collabora), Maxim Monastirsky, tommy27, Joel Madero, Caolán McNamara (Red Hat), Foss, Jay Philips, m.a.riosv, Julien Nabet, Sophie Gautier (TDF), Cor Nouws, Michael Stahl (Red Hat), Jean‐Baptiste Faure, Andras Timar (Collabora), Adolfo Jayme, ign-christian, Markus Mohrhard (Collabora), Eike Rathke (Red Hat)_ et _Urmas_. Et merci aux nombreux autres qui ont aidé à fermer tant de bogues pour cette version. _Bjoern Michaelsen (Canonical)_ a aussi écrit une [belle taxonomie](http://skyfromme.wordpress.com/2014/02/11/libreoffice-bugzilla-status/) sur nos 25 000 bogues rapportés jusqu’à présent, et a fourni les données pour une belle répartition : ![Titre de l'image](http://people.gnome.org/~michael/images/2014-07-15-bug-stats.png) # Nettoyage du code Le code sale doit être nettoyé — et une fois encore, nous n’avons pas chômé. ## La mort finale de UniString Même si nous avions éliminé dans la version 4.2 la dernière classe `string` de `tools/` pour la remplacer par une nouvelle classe uniforme (OUStrings) partout, nous utilisions encore en d’autres endroits des quantificteurs de 16 bits pour décrire des _offsets_ textuels. Merci à _Caolán McNamara (Red Hat)_ pour avoir permis d’avoir des paragraphes de plus de 65 535 caractères dans Writer, une fonctionnalité demandée depuis fort longtemps par certains utilisateurs, voir le [_billet idoine_](http://caolanm.blogspot.cz/2014/01/long-writer-paragraphs.html). ## Nettoyage du code et de la structure de VCL Les bibliothèques graphiques natives de LibreOffice — _Visual Class Libraries_ — n’ont pas reçues toute l’attention qu’elles auraient mérité ces dernières années. Mille mercis à _Chris Sherlock_ pour les centaines de correctifs inaugurant le nettoyage de ces bibliothèques. Beaucoup de bonnes choses en découlent : une structure de code plus logique, de sorte qu’il est aisé de trouver les méthodes ; une écriture systématique d’une documentation (Doxygen) pour les méthodes de l’API, assurant que celles‐ci possèdent des noms judicieux et descriptifs. Ceci commence à nous désengluer de pauvres choix de conception historiques. Ce travail est très apprécié. ## Suivi des commentaires en allemand Nous progressons toujours dans la traduction des derniers commentaires en allemand qui parsèment le code vers un anglais correct, précis et technique. Merci à _Luc Castermans, Sven Wehner, Christian M. Heller, Philipp Weissenbacher, Stefan Ring, Philipp Riemer, Tobias Mueller, Chris Sherlock, Alexander Wilms_ et les autres. Dans ce cycle (NdT: de version), nous avons aussi accéléré l’outil de détection des commentaires allemands et réduit le nombre de faux positifs. ![Titre de l'image](http://people.gnome.org/~michael/images/2014-07-15-german-comments.png) ## Refactorisation automatisée de code avec Clang Un des héros du nettoyage de code est _Noel Grandin_ qui améliore constamment le code de différentes façons, par exemple en remplaçant le code inutilement dupliqué pour utiliser les _wrappers_ standards comme _SimpleReferenceObject_. Noel a été lourdement impliqué dans les greffons Clang, qui servent à réécrire notre format de fichier binaire qui est sujet aux erreurs. La surcharge de flux `pStream >> nVar` a l’air d’être une très bonne idée, jusqu’à ce que l’on réalise qu’un changement inattendu du type de `nVar`, loin de là, change le format du fichier. Ces opérateurs ont maintenant tous été réécrits pour l’utilisation explicite de `ReadFloat`, améliorant ainsi la robustesse du code à modifier. Noel a aussi créé des greffons pour mettre à la file automatiquement les membres de fonctions simples, détecter les passages inefficaces de `uno::Sequence` et `OUString`. _Stephan Bergmann (Red Hat)_ a aussi écrit pas mal d’outils perfectionnés d’analyse statique, de vérification de déréférencement de pointeurs `NULL` permettant de trouver rapidement des problèmes de mise en file (_inlining_) sous GNU/Linux qui posent des problèmes essentiellement sous Windows, et a réécrit les utilisations non nécessaires de `sal_Bool` en `bool`. Stephan a aussi écrit un greffon pour trouver les fonctions non utilisées dans les modèles ou non, et émet aussi des alertes sur les conversions illicites des littérales vers un `bool`, par exemple `if (n == KIND_FOO || KIND_BAR)`. Tout cela améliore la lisibilité, la cohérence, la fiabilité et, dans certains cas, la performance du code. ## Amélioration du cycle de vie _Takeshi Abe_ s’est beaucoup investi pour rendre les cycles de vie des objets plus utiles. Se servir de pointeurs intelligents rend le code non seulement plus lisible et court, mais surtout le sécurise du point de vue des exceptions, ce qui est vraiment très utile. ## Suppression de DocTok Ce nettoyage nous débarrasse de presque 80 000 lignes de code et rend le code bien plus simple à comprendre. Merci à _Miklos Vajna_ de Collabora. Vous pouvez voir l’avant et l’après dans ce [_billet_](http://vmiklos.hu/blog/doctok.html). # Tenir bon sur la performance La performance fait partie de ces choses difficiles à conserver. Elle a la fâcheuse manie de partir en sucette dès qu’on a le dos tourné. C’est pourquoi _Matus Kukan (Collabora)_ a construit une machine de test qui compile régulièrement LibreOffice et lance des tests sur le chargement, conversions, etc, de documents sous _callgrind_. L’utilisation du simulateur de processeur de _callgrind_ a cette magnifique propriété de répétabilité de comportement, ce qui permet de détecter la moindre diminution ou amélioration des performances et de tout de suite résoudre le problème. C’est facile de voir sur le graphique — admirez au passage la superbe platitude des lignes entre les évènements importants. L’axe _x_ représente le temps (annoter les axes avec les _hashes_ de Git n’est pas photogénique). ![Titre de l'image](http://people.gnome.org/~michael/images/2014-07-15-performance.png) Souvent on regarde les performances juste avant la sortie finale. Ici, il est intéressant de voir la grosse bosse orange d’un point de vue fragilité des performances, trouvée et résolue grâce à ces tests. [Les données brutes de _callgrind_](http://dev-builds.libreoffice.org/callgrind_report/traces/) sont disponibles pour examen des dernières traces avec le [fichier plat ODS](http://dev-builds.libreoffice.org/callgrind_report/history.fods) (_flat ODS_) des derniers tests. # S’investir J’espère que vous comprendrez que de plus en plus de développeurs arrivent et se sentent comme chez eux parmi nous. Nous travaillons ensemble pour achever des travaux d’importance à la fois sous le capot et sur la carrosserie. Si vous voulez vous impliquer, il y a plein de merveilleuses personnes à rencontrer et avec qui œuvrer. Comme vous pouvez le constater, les indépendants ont un impact significatif sur la diversité de LibreOffice (la légende de couleurs se lit de gauche à droite, de haut en bas, ce qui représente les couleurs de haut en bas dans le graphique. [NdT: les indépendants, c’est le gros morceau orange au milieu.]) ![Titre de l'image](http://people.gnome.org/~michael/images/2014-07-15-committers.png) Et en ce qui concerne la diversité des patchs, nous adorons voir le volume des contributions apportées par les indépendants, même si clairement ce volume et les équilibres changent selon les saisons, les cycles de publication, le temps libre des volontaires et les business-plans. ![Titre de l'image](http://people.gnome.org/~michael/images/2014-07-15-commits.png) Naturellement, nous maintenons une liste de petites ou minuscules tâches sur notre page [Easy Hacks](https://wiki.documentfoundation.org/Development/Easy_Hacks) dont vous pouvez vous emparer pour vous impliquer dans ce projet, avec des [instructions simples d’installation ou de compilation](http://www.libreoffice.org/community/developers/). C’est extrêmement facile de compiler LibreOffice. Chaque "easy hack" indique où aller dans le code et représente une tâche simple à résoudre dans un cadre bien restreint. De plus, certaines de ces tâches sont des fonctionnalités vraiment utiles ou des améliorations de performance. S’il vous plaît, envisagez de vous impliquer sur quelque chose. ![Titre de l'image](http://people.gnome.org/~michael/images/2014-07-15-easy-hacks.png) Autre chose qui aide vraiment : lancer les préversions et rapporter les bogues. Il suffit de télécharger et d’installer une [préversion](http://www.libreoffice.org/download/pre-releases/) et vous êtes prêt pour contribuer avec l’équipe de développement. Conclusion ========== LibreOffice 4.3 est la suivante d’une série de versions qui vont améliorer progressivement non seulement les fonctionnalités, mais aussi les fondations de la suite bureautique libre. Soyez patient, c’est juste la première version parmi la longue série des cycles mensuels de publication 4.3._x_, qui apporteront leurs lots de correctifs et d’améliorations qualitatives pour les mois à venir, tandis que nous commençons à travailler sur LibreOffice 4.4. J’espère que LibreOffice 4.3 vous plaira. Merci de m’avoir lu, et merci de soutenir LibreOffice. Les données brutes de la plupart graphiques ci‐dessus sont [disponibles](http://people.gnome.org/~michael/data/2014-07-12-4.3-data.ods).

AltStyle によって変換されたページ (->オリジナル) /