URL: https://linuxfr.org/news/libreoffice-4-2-0-est-disponible Title: LibreOffice 4.2.0 est disponible Authors: patrick_g esdeem, Xavier Verne, woprandi, Davy Defaud, coid, NeoX, j, olivierweb, pamputt, Nonolapéro, Thomas Debesse, Florent Zara et rpnpif Date: 2014年01月30日T19:35:28+01:00 License: CC By-SA Tags: libreoffice, traduction, coulisses et fosdem Score: 94 [[LibreOffice]] [4.2.0](http://linuxfr.org/redirect/89251) vient d’être publié (le 30 janvier 2014). Cette [nouvelle version](http://linuxfr.org/redirect/89251) est destinée aux utilisateurs expérimentés – les autres, comme les entreprises et les administrations sont invitées à utiliser LibreOffice [4.1](https://wiki.documentfoundation.org/ReleaseNotes/4.1/fr).4 ([publié le 18 décembre 2013](http://fr.libreoffice.org/telecharger/notes-de-version/#4.1.x)). ![Logo LibreOffice](https://wiki.documentfoundation.org/images/7/77/LibreOffice_external_logo_300px.png) [Michael Meeks](https://en.wikipedia.org/wiki/Michael_Meeks_%28software_developer%29) est un _hacker_ qui travaille sur la suite bureautique LibreOffice pour l’éditeur [Collabora](https://en.wikipedia.org/wiki/Collabora). Il vient de publier [sur son blog](https://people.gnome.org/~michael/blog/2014-01-30-under-the-hood.html) une longue description du travail de refactorisation et de nettoyage qui a eu lieu lors du cycle menant à la version 4.2 de LibreOffice. Comme ce texte est fort intéressant et qu’il est placé dans le domaine public (et sous licence CC0, quand la législation locale interdit à un auteur d’opter pour le domaine public), il m’a semblé pertinent de traduire son billet. Vous trouverez donc dans la suite de la dépêche une traduction du texte de Michael. Merci à tous les contributeurs de cette dépêche qui ont participé à cette traduction et à la relecture. ---- [L’article de Michael Meeks](https://people.gnome.org/~michael/blog/2014-01-30-under-the-hood.html) [Vidéo de quelques nouveautés](https://www.youtube.com/watch?v=oqo2MIA5eQk) [Nouveautés de LibreOffice 4.2 (notes de version)](https://wiki.documentfoundation.org/ReleaseNotes/4.2/fr) [LibreOffice](http://fr.libreoffice.org/) ---- Nous publions aujourd’hui même LibreOffice 4.2.0, truffé de nouvelles fonctionnalités ! Vous pouvez bien sûr lire et profiter de toutes les fonctionnalités visibles pour les utilisateurs, fournies par nos nombreux contributeurs héroïques, mais il y a également des contributions dont l’effet se ressent principalement en coulisses, à des endroits pas forcément faciles à apprécier, et qui sont vitales pour le projet. Comme il peut être assez malaisé d’extraire celles-ci au milieu des 12 000 modifs depuis la séparation de la branche LibreOffice 4.1, laissez‐moi vous les détailler : # Interface utilisateur et boîtes de dialogue # La migration de l’interface utilisateur vers des fichiers XML au format [[Glade]] se poursuit activement avec des contributions multiples. Nous sommes parvenus à convertir 280 dialogues dans cette version, portant notre avancée globale à environ 70 %. Un grand merci à Caolán McNamara (Red Hat), Manal Alhassoun (KACST), Olivier Hallot (EDX), Faisal M. Al‐Otaibi (KACST), Laurent Balland‐Poirier, Efe Gürkan Yalaman, Krisztian Pinter, Jan Holesovsky (Collabora), Andras Timar (Collabora), Cao Cuong Ngo, Gergo Mocsi, Katarina Behrens, Abdulmajeed Ahmed (KACST) et Alia Almusaireae (KACST). Merci aussi à nos traducteurs qui ont aidé à la migration des chaînes de caractères. ## Progression de la migration des modèles d’interface utilisateur ## ![DLFP](http://people.gnome.org/~michael/images/2014-01-29-ui-layout.png) Si vous souhaitez vous impliquer pour porter cet effort jusqu’à 100 %, reportez‐vous aux [mises à jour](http://caolanm.blogspot.ch/2014/01/622-conversions-70-complete.html) et aux _[Howto](http://caolanm.blogspot.ie/2013/01/converting-libreoffice-dialogs-to.html)_ de Caolán. # Améliorations de la chaîne de compilation # Dans cette version, nous avons beaucoup progressé en termes de facilité pour compiler le code source, et rendre le tout plus compréhensible — un point toujours important pour les nouveaux contributeurs. ## Une chaîne de compilation et d’exécution drastiquement améliorée ## Il y a 6 mois, nous avions annoncé la très bonne nouvelle d’une compilation [entièrement fondée sur GNU make](https://people.gnome.org/~michael/blog/2013-06-13-under-the-hood.html#config-make), plus rapide et plus agréable. Pour accentuer encore les bienfaits en 4.2, nous avons travaillé dur pour nous assurer que vous pouvez compiler et immédiatement exécuter LibreOffice sans — longue — phase intermédiaire d’installation. Nous compilons en direct un binaire exécutable dans `instdir/`, ainsi : ```sh ./autogen.sh make cd instdir/program ./soffice -writer ``` suffit pour avoir une suite pleinement fonctionnelle sous Windows, Mac OS X ou GNU/Linux. Ceci nous évite une tonne de Perl, nettoie une grande partie de `scp2/` et permet de supprimer des étapes de configuration à l’installation. Merci à Michael Stahl (Red Hat), David Tardon (Red Hat), Matus Kukan (Collabora) et Marcos Paulo de Souza. C’est toujours amusant de voir des contributeurs et partenaires s’échanger des exécutables Windows au format `instdir.zip`. Cerise sur le gâteau : nous avons également fait le ménage un peu partout des vieux sous‐répertoires spécifiques à la configuration de l’installation comme `unxlngi6.pro` ; si les gens ciblent plusieurs plates‐formes à partir du même source, il leur suffit de lancer `./configure` depuis des répertoires différents. Merci à Michael Stahl (Red Hat), et Tor Lillqvist (Collabora). ## Compilation individuelle des fichiers de localisation## Compiler le grand nombre de fichiers de localisation de LibreOffice crée une importante demande en temps de compilation (nous supportons plus de 100 langues nativement). Grâce à Bjoern Michaelsen (Canonical) nous pouvons à présent [compiler séparément](https://gerrit.libreoffice.org/#/c/6660/) du paquet principal les fichiers de localisation. Cela aide les empaqueteurs des distributions GNU/Linux de nombreuses façons. Cette séparation diminue les besoins en espace disque sur la machine de compilation, besoins qui peuvent dépasser les 25 Gio pour chaque compilation publiable, ce qui est utile pour porter sur des architectures aux ressources plus limitées. Les compilations et les _respins_ sont plus rapides. Avec les binaires de LibreOffice exécutables sur place dans `instdir`, nous pouvons également éviter d’utiliser les macros moisies `scp2/` interprétées par Perl pour les empaqueter directement. Ce changement rend aussi plus simples les mises à jour liées aux correctifs de sécurité, sans avoir à recompiler des centaines de fichiers de localisation non modifiés. Nous nous réjouissons d’avance de voir les distributions GNU/Linux profiter de cela pour faciliter leur travail d’empaquetage et de maintenance. ##Autodoc est mort, vive Doxygen !## Depuis de nombreuses années, une horrible version hackée de (...) mais maintenant, grâce à l’[excellent travail](http://cgit.freedesktop.org/libreoffice/core/commit/?id=7a5a19218707ab580d58a3fbadec1148368661f1) de Michael Stahl (Red Hat) Doxygen a appris le UNO IDL de LibreOffice, et nous nous sommes débarrassés de `cosv`, `udm` et des modules haut niveau d’`autodoc`, bon débarras de 57 000 lignes de code. Merci aussi à ceux qui ont aidé à améliorer, nettoyer et « doxygéner » les commentaires du code, à savoir : Julien Nabet, Miklos Vajna (Collabora), Christian Lohmaier (TDF), Thorsten Behrens (SUSE), Stephan Bergmann (Red Hat) et Zolnai Tamas (Collabora). Vous pouvez lire la documentation générée pour l’[API publique](http://api.libreoffice.org/docs/idl/ref/namespaces.html) et l’[API interne](http://docs.libreoffice.org/). # Travail sur la qualité du code # Un travail important a été fourni quant à la qualité du code, l’amélioration de sa maintenabilité et sa lisibilité : une autre salve de 80 modifs pour corriger des erreurs relevées par [_cppcheck_](http://cppcheck.sourceforge.net/) a été envoyée par Julien Nabet, ainsi que le brouhaha quotidien pour compiler sans aucun avertissement de compilation avec les drapeaux de compilation `-Werror -Wall -Wextra`, et ce, sur toutes les plates‐formes, principalement grâce au travail de Tor Lillqvist (Collabora) et de Caolán McNamara (Red Hat). ## Analyse statique de code via Coverity Scan Nous avons beaucoup œuvré sur l’énorme quantité de résultats donnés par l’analyse faite par Coverity Scan. Selon les résultats du rapport sur LibreOffice, dans cette version seulement, il y eut 210 corrections (et bien plus encore de tickets clos). Merci à Caolán McNamara (Red Hat), Eike Rathke (Red Hat), Julien Nabet, Norbert Thiebaud, Andrzej Hunt (Collabora), Markus Mohrhard (Collabora) et Gergo Mocsi. ## Tests d’importation et d’exportation ## Grâce au travail de Markus Mohrhard nous disposons d’un outil permettant de tester l’importation de fichiers corrompus afin de provoquer des crashs. Il teste maintenant plus de 45 000 documents problématiques issus des remontées de bogues sur tous les projets sur lesquels on peut mettre la main. Nous les testons un par un avec un binaire suractivé en assertions et informations de débogage en tout genre. Depuis peu, nous avons également commencé à exporter ces documents dans plusieurs formats de sortie, de manière à identifier des problèmes, en exécutant également toute une batterie d’outils de validation. Dans la durée, tout ceci impacte positivement la qualité. La sortie est consignée par [_git hash_](http://dev-builds.libreoffice.org/crashtest/). ## Maîtrise des fuites via Valgrind ## Valgrind demeure un outil merveilleux pour dénicher et isoler les fuites [NdT : de mémoire] et les comportements erratiques de diverses sections du code. Merci à Mark Wielaard d’avoir colmaté nombre de fuites et résolu divers problèmes relatifs, de même que de nombreux autres problèmes récurrents. ## Tests unitaires ## Nous avons également complété et exécuté plus de tests avec LibreOffice 4.2 pour éviter des régressions en changeant le code. Ces ajouts sont assez difficiles à évaluer dans la mesure ou les gens aiment bien empiler les nouveaux tests au sein de modules de tests existants. Une estimation naïve est de rechercher la macro `CPPUNIT_TEST()`, qui montre que nous avons ajouté 216 de ceux‐ci depuis la 4.1, mais nous avons également ajouté plus de `CPPUNIT_ASSERT` par test, soit plus de 2 160. L’idéal serait que chaque bogue corrigé donne lieu à un test unitaire associé pour l’empêcher de revenir à jamais. Avec plus de 80 contributeurs à ces tests pour la 4.2, c’est assez difficile de citer tout le monde ici, mais je dois dire que c’est formidable d’avoir une culture de tests systématique et bien ancrée, liée aux corrections de bogues. ## Nombre de tests unitaires et de vérifications ## ![DLFP](http://people.gnome.org/~michael/images/2014-01-29-unit-test.png) ## Assurance qualité ## Pour cette version, l’équipe d’assurance qualité s’est agrandie et a accompli un travail remarquable pour tirer et clore les bogues. Merci à Bjoern Michaelsen (Canonical), Robinson Tryon et Joel Madero d’avoir effectué un bon travail ici, et aussi particulièrement à nos meilleurs correcteurs de bogues. Il y a une longue liste de personnes qui [répondent aux bogues](http://wiki.documentfoundation.org/Releases/4.2.0/RC3#Thanks_to_all_who_took_part_in_handling_the_issues). Une métrique que nous suivons est de regarder qui est dans le top 10 du [résumé hebdomadaire des bogues](https://bugs.freedesktop.org/page.cgi?id=weekly-bug-summary.html) centralisé sur _freedesktop.org._ Il contient une liste des 20 personnes qui apparaissent le plus souvent au palmarès des correcteurs de bogues. Merci à eux : _tommy27_, Caolán McNamara (Red Hat), _Maxim_, Jean‐Baptiste Faure, Eike Rathke (Red Hat), _ign_christian_, _Foss_, _Urmas_, Joel Madero, Cor Nouws, Julien Nabet, Michael Stahl (Red Hat), Maxim Monastirsky, Jorendc, Andras Timar (Collabora), Lionel Élie Mamane, Kohei Yoshida (Collabora), _mariosv_, _bfoman_, Thomas Arnhold, Adolfo Jayme (_fitoschido_), Sophie (TDF), Samuel M., Markus Mohrhard (Collabora) et Rob Snelders. Pour en savoir plus sur les [bogues et leurs statistiques](http://skyfromme.wordpress.com/2014/01/22/numbers/), vous pouvez consulter le blog de Bjoern (avec des chats). Pour résumer, on peut dire que des milliers de bogues ont été traités. - L’équipe de l’assurance qualité trie les nouveaux bogues, teste et confirme que les bogues sont reproductibles, en fournissant les infos nécessaires. Elle s’efforce de maintenir le flot de bogues non triés aussi bas que possible. Il est très simple de participer et d’aider à cela [_ici_](https://wiki.documentfoundation.org/QA/BugTriage/fr). - À chaque cycle de version, elle trouve et étiquette environ un millier de bogues en doublon. - À chaque cycle de version, elle clôt et invalide environ un millier de bogues (pour diverses raisons, comme l’absence de réponse du demandeur pendant des mois). - À chaque cycle de version (environ 6 mois), les développeurs corrigent environ un millier de bogues. - À chaque cycle, le nombre de nouveaux bogues croît un peu, mais cette croissance diminue. En ce moment, nous avons environ 25 000 bogues, dont 6 500 sont nouveaux et 800 non confirmés. Par ailleurs, environ 25 % des bogues sont des demandes de nouvelles fonctionnalités, ce à quoi il n’y a vraisemblablement pas de fin. - Concernant les bogues les plus fâcheux [NdT : crashs et dysfonctionnements majeurs] et les régressions, la tendance est plate, tandis que le nombre de corrections sur ces deux points croît rapidement. # Nettoyage du code # Le code crade doit être éradiqué et, sur ce chapitre, nous n’avons pas chômé. ## La mort définitive d’UniString ## Le plus gros changement dans la 4.2, en gestation depuis les tout débuts du projet LibreOffice, consiste à supprimer nos différents types de chaînes de caractères, obsolètes, nous laissant ainsi avec seulement _2_ types de chaînes, l’une pour toutes les chaînes à 8 bits d’encodage, et l’autre pour toutes les chaînes en UTF-16. Le dernier [_commit_](http://cgit.freedesktop.org/libreoffice/core/commit/?id=b37e2dd071c83454b3b06c0959a76b6012f53abb) a détruit ce monstre une bonne fois pour toutes. Bien sûr, de très nombreuses personnes ont contribué à cette tâche et au nettoyage afférent depuis maintenant plusieurs années ; dans cette version, 30 personnes environ y ont participé. Merci en particulier à Noël Grandin d’avoir mené l’offensive, mais aussi à tous les autres : Matteo Casalin, Caolán McNamara (Red Hat), Stephan Bergmann (Red Hat), Ivan Timofeev, Michael Stahl (Red Hat), Thomas Arnhold, Kohei Yoshida (Collabora), Eike Rathke (Red Hat), Tor Lillqvist (Collabora), Palenik Mihály, Markus Mohrhard (Collabora), Luboš Luňák (SUSE), Máté Gergely, Andrzej J.R. Hunt (Collabora), Christina Rossmanith, Laurent Balland‐Poirier, Julien Nabet, Sean Young, Neil Moore, Jelle van der Waa, Donizete Waterkemper et Arnaud Versini. Enfin, nous aurons pour la version 4.3 les premiers bénéfices visibles de ce travail, qui permettra d’écrire des paragraphes plus longs que 65 000 caractères. Allez voir notre page Wiki en construction des [fonctionnalités de la 4.3](http://wiki.documentfoundation.org/ReleaseNotes/4.3/fr#Writer) et l’[article de blog](http://caolanm.blogspot.cz/2014/01/long-writer-paragraphs.html) associé. Par ailleurs, en corrigeant récemment un bogue, j’ai trouvé assez intéressant le [bourbier des types de chaînes de caractères sur la plate‐forme Windows](http://www.codeproject.com/Articles/4829/Guide-to-BSTR-and-C-String-Conversions). ## Une API de gestion des fichiers temporaires en moins ## Nous avons un nombre certain d’API hétérogènes pour gérer les fichiers temporaires, de la plus vieille à la plus emberlificotée... `tools/tempfile.hxx` fut gentiment codé par Palenik Mihály. Dans l’idéal, il y aurait un seul endroit sécurisé dans le répertoire `sal/` où les fichiers temporaires seraient gérés. ## Traduction des commentaires allemands ## Nous avons continué à progresser du côté de la traduction des derniers commentaires restant encore en allemand, pour les remplacer par des commentaires techniques en anglais précis. Remerciements à Philipp Weissenbacher, Philipp Riemer, Laurent Balland‐Poirier, Rolf Hemmerling, Chris Hoppe, Rodolfo Ribeiro Gomes, Matthias Freund et Henning Diedler. Je suspecte que l’effet de traînée dans les chiffres est en partie dû à des faux positifs, conséquence de notre outil de type `find` qui devine la langue des commentaires. ## Commentaires allemands restant à traduire ## ![DLFP](http://people.gnome.org/~michael/images/2014-01-29-german-comments.png) ## Suppression du code mort grâce aux avertissements du compilateur ## Beaucoup de code mort a été identifié et supprimé grâce à de récentes améliorations dans les avertissements de compilation Clang / GCC (`-Wunsued-function, -Wunused-variable, -Wunused-private-field`, etc.) et via l’utilisation de `SAL_WARN_UNUSED`. (Caolán McNamara (Red Hat), Luboš Luňák (SUSE), Stephan Bergmann (Red Hat), Tor Lillqvist (Collabora)). # Compilation sous Windows et symboles de déboguage # Le temps de compilation sous Windows a été réduit de [10 minutes](http://cgit.freedesktop.org/libreoffice/core/commit/?id=66a0713dc9c676182fcd7aa1e21f8dc25c05be5e), soit 10 % environ, grâce au travail de Bjoern Michaelsen (Canonical), pour ensuite immédiatement augmenter à nouveau, du fait de l’ajout d’optimisations au moment de l’édition de liens à destination des nouveaux compilateurs Microsoft. Une autre fonctionnalité souvent demandée, qui permet aux utilisateurs de fournir des traces de qualité lors des crashs et gels de l’application, et permet ainsi de corriger les bogues plus rapidement, est l’utilisation du serveur de symboles Windows de Cloph. Renseignez‐vous sur la méthode pour [générer une _backtrace_](https://wiki.documentfoundation.org/How_to_get_a_backtrace_with_WinDbg) , c’est un excellent moyen pour les utilisateurs d’améliorer la qualité des bogues remontés sur cette plate‐forme. Merci à Fridrich Štrba (SUSE), Luboš Luňák (SUSE), et Christian Lohmaier (TDF). # Refonte du cœur de Calc # Il y a beaucoup à dire sur ce point. Le détail des changements sera exposé prochainement lors du FOSDEM. Qu’il suffise de dire que le moteur de Calc a été refondu massivement, améliorant l’utilisation de la mémoire, les performances dans de nombreux cas, permettant l’usage d’OpenCL pour calculer certaines formules via le processeur graphique, et plus encore. Mille mercis à Kohei Yoshida (Collabora), Markus Mohrhard (Collabora), et à l’équipe de MultiCoreWare : I‐Jui (Ray) Sung, Hao Chen, Shiming Zhang, Yiming Ju, Yang Zhang, Hongu Zhong, Ming Li, Min Wang, De Chuang, Feng Zheng, _mulei_, Xin Jiang, Zhenyu Yuan et les autres. # S’impliquer dans LibreOffice # J’espère que vous comprendrez que de plus en plus de développeurs trouvent une nouvelle maison à LibreOffice et travaillent de concert pour accomplir un tâche significative à la fois sous le capot et en surface. Si vous voulez vous impliquer, il y a beaucoup de gens formidables à connaître et avec qui travailler. Comme vous pouvez le constater, les individus peuvent avoir un impact considérable parmi la diversité des contributeurs à LibreOffice (la légende colorée à droite doit être lue de gauche à droite, de haut en bas, et correspond aux couleurs de haut en bas sur le schéma). _NdT : le schéma est peu clair, mais je pense que la grosse zone rouge apparue à la naissance de LibreOffice correspond aux individus sans affiliation connue._ ## Développeurs actifs par mois par affiliation ## ![DLFP](http://people.gnome.org/~michael/images/2014-01-29-committers.png) De même, si l’on regarde la diversité des contributeurs du code, c’est très plaisant de voir autant de contributions de volontaires non affiliés [NdT : à une compagnie], même si clairement cette composante varie selon les saisons, les cycles de versions et notre temps de mentorat disponible : ## _Commits_ mensuels par affiliation ## ![DLFP](http://people.gnome.org/~michael/images/2014-01-29-commits.png) Bien sûr, nous maintenons une liste de bogues et de tâches réputées faciles, dont vous pouvez vous saisir pour commencer à contribuer. Notre page « [_Easy hacks_](https://wiki.documentfoundation.org/Development/Easy_Hacks) » est là pour ça, avec des [instructions simples pour compiler](http://www.libreoffice.org/developers/) et configurer le code. Nous avons maintenant un environnement plus propre et plus sain pour travailler à l’amélioration du code. À titre d’illustration, [cette vidéo](http://www.youtube.com/watch?v=2gIqOOajdYQ&hd=1) montre à quel point il est simple de se lancer dans le développement de LibreOffice aujourd’hui. Il est aussi encourageant de voir comment les _« easy hacks »_ progressent. Arriverez‐vous à clore le 400^(e) ? _NdT : les _« [easy hacks](https://wiki.documentfoundation.org/Development/Easy_Hacks/lists/by_Required_Skill) » sont des tâches simples offertes aux nouveaux contributeurs pour les aider à mettre le pied à l’étrier dans le code de LibreOffice, et même certaines tâches ne requièrent pas de savoir coder. Ça libère du temps pour les développeurs confirmés et c’est indispensable pour la clarification et le nettoyage du code. Par exemple : supprimer du code mort, traduire les commentaires en allemand, réécrire des [bouts de code](http://cgit.freedesktop.org/libreoffice/core/commit/?id=22b928d7d7e03e0a8506263ae556a0e3d15b0d86), des [types](http://cgit.freedesktop.org/libreoffice/core/commit/?id=6fd75d6a34e1a696a766776326f589b471b84d82), des méthodes obsolètes, [virer des vieilles macros inutiles](http://cgit.freedesktop.org/libreoffice/core/commit/?id=30ac3942b44b8f903180488f87e1df4e02ff88e8)._ ## Progrès concernant la résolution des _« easy hacks »_ ![DLFP](http://people.gnome.org/~michael/images/2014-01-29-easy-hacks.png) Une autre chose aide réellement : faire tourner les [pré‐versions](http://www.libreoffice.org/download/pre-releases/) et signaler les bogues. Il suffit de récupérer et d’installer une pré-version et vous êtes prêt à contribuer avec le reste de l’équipe de développement. # Conclusion # LibreOffice 4.2 est la suite d’une série de versions qui améliorent non seulement les fonctionnalités, mais aussi les fondations de la suite bureautique libre. Bien sûr, c’est seulement le premier d’une longue série de parutions 4.2.x mensuelles qui vont apporter une série de corrections de bogues et d’améliorations de la qualité durant les prochains mois. J’espère que vous aimez LibreOffice 4.2.0, merci pour la lecture et merci de supporter LibreOffice.

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