URL: https://linuxfr.org/news/libreoffice-5-0-sous-le-capot Title: LibreOffice 5.0 : sous le capot Authors: Crao Nÿco, Olivier, Yves Bourguignon, BAud, jcr83, Benoît Sibaud, bubar🦥, Frédéric Massot, Jiehong, Lucas, ɹǝɓuᴉɹǝɐH ʅǝnuɐɯɯƎ-sᴉxǝʅⱯ, yeKcim, Florent Zara, ʭ ☯ , scorpio810, ppb, Ytterbium, djibb, M5oul, Jarvis, François et skone Date: 2015年08月06日T10:24:29+02:00 License: CC By-SA Tags: libreoffice et coulisses Score: 122 La suite bureautique multiplateforme LibreOffice 5.0 a été publiée le 5 août 2015. Cette nouvelle version non finalisée est destinée aux utilisateurs expérimentés — les autres, tel que les entreprises et les administrations sont invités à rester sous LibreOffice version 4.4.5. ![Logo LibreOffice](https://wiki.documentfoundation.org/images/8/8b/LibreOffice_Initial-Artwork-Logo_ColorLogoContemporary_500px.png "Source : https://wiki.documentfoundation.org/Gallery_Logos") Nous vous proposons la traduction d'un billet du blog d'un meneur dans le développement de LibreOffice. Il s'agit de [Michael Meeks](https://en.wikipedia.org/wiki/Michael_Meeks_%28software_developer%29) vice-président de l'éditeur [Collabora](https://libreoffice-from-collabora.com/) spécialisé dans l'intégration de la suite LibreOffice. Ce [billet](https://people.gnome.org/~michael/blog/2015-08-05-under-the-hood-5-0.html) décrit l'ensemble des actions réalisées en profondeur durant tout le cycle de développement menant à cette version 5.0 de LibreOffice. Son billet est publié sous licence CC0, et également dans le domaine public. ---- [Article original](https://people.gnome.org/~michael/blog/2015-08-05-under-the-hood-5-0.html) [Notes de version](https://wiki.documentfoundation.org/ReleaseNotes/5.0/fr) [Dépêche sur la version précédente (4.4)](https://linuxfr.org/news/libreoffice-4-4-sous-le-capot) [Téléchargement](http://fr.libreoffice.org/) [Présentation : Porting LibreOffice to GTK3](http://www.skynet.ie/~caolan/guadec2015/GUADEC-2015-GTK3.pdf) ---- Le 5 août 2015, nous [avons publié LibreOffice 5.0.0](https://blog.documentfoundation.org/2015/08/05/libreoffice-5-0-stands-out-from-the-office-suite-crowd), une nouvelle base pour le travail des prochains mois et années. Elle inclut beaucoup de nouvelles fonctionnalités que les utilisateurs apprécieront. Vous pouvez prendre connaissance de toutes ces [nouveautés visibles par les utilisateurs](https://wiki.documentfoundation.org/ReleaseNotes/5.0/fr) codées par tant d'excellents développeurs, mais il y a, comme toujours, de nombreux contributeurs dont le travail se situe principalement sous le capot, et beaucoup de travail qui est plus technique que ce qui est visible par l'utilisateur. Ce travail a, bien sûr, une importance vitale pour le projet. Il peut être difficile d'extraire tout ceci des quelque onze mille contributions ajoutées depuis la version 4.4 de LibreOffice, donc je vais essayer de développer : # VCL - Améliorations de la boîte à outils VCL # L’un des plus grands travaux dans LibreOffice 5.0 concerne [VCL](http://docs.libreoffice.org/vcl/html/classes.html), la boîte à outils graphiques que LibreOffice utilise pour le rendu et tous ses objets graphiques. La version 5.0 modernise et améliore différents aspects de celle-ci, et les met au niveau des autres boîtes à outils graphiques multi-plateformes. ## Boucle principale / gestion du temps d'attente ## C'est un changement radical majeur qui est arrivé dans la 5.0, et qui est un fondement essentiel pour les futures tentatives de rendre VCL et LibreOffice plus efficaces et performants, grâce à _Jennifer Liebel et Tobias Madl_ ([entretien](https://libreoffice-from-collabora.com/interview-with-jennifer-liebel-and-tobias-madl-from-munich/)). Le souci essentiel avec la précédente approche était que le choix de la prochaine tâche à effectuer dans LibreOffice (doit-on compter plus de mots, ou bien traiter du travail de redimensionnement de fenêtre différé, ou alors redessiner le contenu d'une fenêtre ?) était déterminé par un ensemble assez arbitraire de valeurs de délais d'attentes maximaux, par exemple : 30 ms pour redessiner, 50 ms redimensionner. Cela posait non seulement des problèmes de concurrence, mais était aussi terriblement inefficace. Il n'y avait aucune base solide pour ces valeurs choisies un peu au hasard. Heureusement dans LibreOffice 5.0 nous avons un nouveau concept de « boucle d'attente » qui priorise les tâches que nous voulons terminer, permettant de les exécuter dans l'ordre, à la vitesse maximale. Ceci, combiné avec le travail de _Jan Holesovsky (Collabora)_, destiné à permettre l'enchaînement des délais d'attente inférieurs à 10 ms sous Windows, signifie que nous avons enfin une boucle principale utile. Cela nous a aussi aidés à trouver quelques mauvais comportements fortement consommateurs d'énergie qui auparavant étaient moins visibles. Ces tâches, généralement courtes, pouvaient s’exécuter selon une fréquence de l'ordre de 30 ms. Elles réveillaient trop discrètement et inutilement le processeur pour un faible bénéfice. Désormais, ce type de tâches provoque un pic d'activité processeur à 100 %, ce qui facilite sa détection et son traitement. Merci à _Ashod Nakashian_ de s'être attaqué à plusieurs de ces problèmes. ## Réfection du cycle de vie (VclPtr) ## Pendant une grande partie de son existence, le cycle de vie d'un widget VCL (NdT: la boîte à outils graphiques Visual Components Library) est resté un poil mystérieux, même pour VCL. Les widgets pouvaient être alloués sur le tas, sur la pile, ou être membres d'autres widgets. S'ils étaient alloués sur le tas, ils pouvaient être enveloppés dans différents types de pointeurs partagés (_shared pointers_). Ainsi, prédire quand un widget pouvait être détruit et/ou suivre son cycle de vie dans le code était loin d'être évident. Dans VCL, nous utilisions des identifiants : des écouteurs spécifiques qui passaient à `null` quand un objet était détruit pour essayer d'éviter de référencer un objet impliqué dans plusieurs fonctions de rappel (_callbacks_). Malheureusement, ce système était plutôt incomplet, et beaucoup de code se résignait à retarder la suppression d'un widget alloué sur le tas jusqu'au retour à la boucle d'attente, dans le but d'éviter des problèmes. Pour essayer de résoudre tout ce bazar, nous avons maintenant un seul type de pointeur intelligent : le type `VclPtr` qui compte les références à toutes les sous-classes de `Window` (et `OutputDevice`), et elles sont dorénavant toutes allouées sur le tas. Ceci donne un mécanisme de cycle de vie cohérent, et qui est même [documenté](https://gerrit.libreoffice.org/gitweb?p=core.git;a=blob;f=vcl/README.lifecycle;h=6b5cbd6e8df4bcc77b28b0e296e50a96ca8899a0;hb=HEAD). Nous sommes passés à un mécanisme de type 'dispose' pour casser les références cycliques, remplaçant le précédent mécanisme explicite ou implicite de type 'delete', nous avons aussi rendu beaucoup de méthodes sûres à appeler même sur les widgets libérés. Ceci devrait finalement fournir un cycle de vie prédictible et des chemins de destruction de code beaucoup moins fragiles, facilitant le ré-usinage de code. Pendant ce temps nous continuons à aplanir les problèmes, grâce à l'aide inestimable de _Noel Grandin (Peralex)_, et de _Caolan McNamara (RedHat) et Julien Nabet entre autres_ pour résoudre les conséquences de ces changements. Il faut espérer que (finalement) à peu près tous les types VCL à longue durée de vie utiliseront un mécanisme de cycle de vie similaire. Ce travail a été rendu possible grâce à l'énorme réusinage de _Caolan_ pour utiliser `VclBuilder` pour tous les dialogues. ## Un mode de rendu moderne : RenderContext ## Une tentative audacieuse pour passer les fondements du code d’un rendu immédiat à un rendu différé a été lancée. Jusqu’à présent, LibreOffice générait le rendu de ce que l’on voit sur l’écran de deux façons : soit immédiatement, c’est-à-dire lorsque vous appuyez sur un « A », il essaie aussitôt d'afficher les pixels pour « A » à l'écran ; soit par un rendu très différé (délai : 30 ms et plus) sans priorité d’exécution (les _callbacks_). Cette situation n’est vraiment pas idéale pour les API et le matériel modernes - où nous voulons nous assurer que l’image est totalement et parfaitement peinte dans son ensemble avant de la montrer à l'écran. Heureusement avec les nouveaux travaux sur la gestion des tâches, il n’y a plus de délai codé en dur avant que le rendu différé puisse avoir lieu. Nous avons donc commencé à supprimer le mode de rendu immédiat et à le remplacer par le rendu différé. Cela signifie remplacer les appels de rendu explicites avec invalidation de zone pour les placer dans une file d’attente destinée à un rendu différé. Dans de nombreux cas, cela peut enlever le scintillement visible et les artefacts de rendu intermédiaires lors du rafraîchissement de l’interface graphique. Mille mercis à Tomaž Vajngerl (Collabora), Miklos Vajna (Collabora), avec l’aide et les corrections de Krisztian Pinter, Noel Grandin (Peralex), Jan Holesovsky (Collabora), Caolán McNamara (RedHat) et Laszlo Nemeth (Collabora). ## Le backend Gtk3 : Wayland ## Le port initial grossier de gtk3 a été codé il y a longtemps par votre serviteur pour prototyper _LibreOffice en ligne_ via gdk-broadway. Cependant, merci à Caolan McNamara (RedHat) d'avoir fait 80 % du travail pour terminer cela, nous donnant un _backend_ VCL poli et complet pour gtk3. Son entrée de blog se concentre sur l'importance de cette opération pour mener LibreOffice nativement sous Wayland - le précédent _backend_ GTK2 était fortement lié au rendu X11 natif, tandis que le nouveau _backend_ gtk3 utilise le rendu CPU via le _backend headless_ (sans affichage) VCL, voir plus ci-dessous. ## Améliorations du rendu OpenGL ## Avec un grand nombre de bogues corrigés et d'améliorations, le rendu OpenGL a bien mûri dans cette version, nous permettant d'utiliser le matériel directement pour améliorer nos rendus. Merci à Louis-Francis Ratté-Boulianne (Collabora), Markus Mohrhard, Luboš Luňák (Collabora), Tomaž Vajngerl (Collabora), Jan Holesovsky (Collabora), Tor Lillqvist (Collabora), Chris Sherlock et les autres. Avec toutes les réparations de bogues en cours dans cette partie, nous espérons que le rendu OpenGL pourra être activé par défaut, comme fonctionnalité de dernière minute, après les tests adéquats, dans LibreOffice 5.0.1 ou, plus tard, dans 5.0.2. # Améliorations de LibreOfficeKit # LibreOfficeKit procure une méthode simple pour réutiliser le rendu et le formatage des fichiers de LibreOffice, mais à présent aussi le noyau de l’éditeur. Dans les six derniers mois, son utilité est passée de la conversion des fichiers principalement, à constituer aujourd’hui les fondations de LibreOffice sur Android, et c’est la base de la version en-ligne. ## Amélioration du rendu sans affichage ## LibreOfficeKit réutilise notre moteur de rendu sans affichage, ce qui nous permet de rendre les documents sans utiliser l'assistance du système d'exploitation, c'est-à-dire sans X11, Windows, OS/X, etc. Un certain nombre d'améliorations de performances et des corrections sur le rendu ont été implémentés au titre du travail sur le moteur gtk3 et l'utilisation en ligne (le rendu sans affichage est également utilisé sur Android jusqu'à ce que notre moteur de rendu GL puisse arriver à maturité sur cette plateforme). Merci à Caolán McNamara (RedHat) et Michael Meeks (Collabora). ## Extensions de l'édition Android ## L'édition Android est construite au-dessus des fonctions d'édition de LibreOfficeKit, et offre à l'utilisateur l'équivalent Android de la [liste des fonctionnalités de gtktiledviewer](https://wiki.documentfoundation.org/Development/Android#gtktiledviewer), comme le curseur natif, la sélection de texte et graphique, le redimensionnement et plus encore. Merci à _The Document Foundation_ et à leurs [généreux donateurs](https://donate.libreoffice.org/). Ces importantes extensions d'API et le travail sur le cœur ont été réalisés grâce à Miklos Vajna, Tor Lillqvist, Andrzej Hunt, Siqi Liu, Mihai Varga, Tomaž Vajngerl et Jan Holesovsky tous de Collabora, ainsi que grâce aux travaux de Pranav Kant (GSOC), et aux nettoyages de Stephan Bergmann (RedHat). ## Des bouts de LibreOffice en ligne ## LibreOfficeKit (accompagné d'un dépliant adapté) est à la base du nouveau travail ciblant LibreOffice sur le Cloud. Regardez le [code](https://gerrit.libreoffice.org/gitweb?p=online.git;a=tree) et une [présentation](https://libreoffice-from-collabora.com/the-cloud-is-our-future-collabora-presents-libreoffice-online-in-bern/). D'énormes quantités d'allègements et de simplifications ont été réalisés ici grâce à : Tor Lillqvist, Mihai Varga, Jan Holesovsky, Henry Castro et Miklos Vajna, tous de Collabora. Avec nos remerciements à [IceWarp](https://libreoffice-from-collabora.com/icewarp-and-collabora-are-working-on-libreoffice-online-document-editing-an-open-source-alternative-to-google-apps-office-365/) pour le financement de ces travaux. ## Améliorations des performances de conversion ## LibreOfficeKit offre une belle API, simple et propre pour charger et sauvegarder (convertir) des documents. Grâce à Laszlo Nemeth (Collabora) et Mihai Varga (Collabora), nous avons maintenant un nouvel attribut de filtre, `SkipImages`, qui permet une accélération significative pour le cas de conversion de n'importe quel fichier en HTML. C'est vraiment utile pour la réutilisation de la vaste gamme de filtres de LibreOffice pour faire de l'indexation de documents texte, en étant beaucoup plus rapide pour les documents gros et complexes. Un autre gain vital a été d'éviter de compter les mots avec précision (pour les statistiques du document) avant l'export. La conversion de document en texte avec cette option devrait être significativement plus rapide pour certains documents. # Amélioration de la compilation et de la gestion des plateformes # ## Réduction du temps de compilation ## Avec l’augmentation de l’utilisation des _templates_ dans les entêtes, la compilation a peu à peu pris de plus en plus de temps. Mais Michael Stahl (RedHat) a créé un script `bin/includebloat` pour localiser les entêtes les plus larges et les plus problématiques à supprimer. À titre d’exemple, supprimer `boost/utility.hpp` de plusieurs endroits nous épargne ~830 Mo de prétraitement de `boost/preprocessor/SEQ/fold_left.hpp`. ## Port vers Win64 ## La version 5.0 arrive avec des compilations 64 bits pour Windows. Un grand merci à David Ostrovsky (CIB), ainsi qu’à Thorsten Behrens (CIB), Norbert Thiebaud, Stephan Bergmann (RedHat) et d’autres pour avoir aidé à corriger les bugs et nettoyé dans toute l’application un bon nombre de problèmes ardus spécifiques à la plateforme. Nous avons de nombreuses versions 64 bits pour différentes plateformes depuis des années, mais le modèle LLP64 de Windows peut créer des problèmes. # Travail sur la qualité du code # Le travail se poursuit autour de la qualité du code dans de nombreux domaines, avec environ 120 corrections `cppcheck`. Merci à Caolán McNamara (RedHat), Michael Weghorn, Julien Nabet, Noel Grandin (Peralex) et aux autres. Pareillement, il y a les _commits_ quotidiens pour compiler sans aucun avertissement du compilateur `-Werror -Wall -Wextra`, etc. sur de nombreuses plateformes. Merci principalement à Tor Lillqvist (Collabora) et à Caolán McNamara (RedHat). Cette catégorie de problèmes diminue néanmoins grâce à l’utilisation croissante d'[intégration continue](https://fr.wikipedia.org/wiki/Int%C3%A9gration_continue). ## Coverity presque à zéro ## L’exécution du vérificateur de code source [Coverity](http://blog.coverity.com/2014/09/16/libreoffice-improving-quality-coverity-scan-service/#.VdiAgbOYrCI) donne un résultat proche de zéro à présent. Chaque semaine, Caolán McNamara (RedHat) (avec l’aide de quelques autres) a accompli un travail formidable en conservant le compte à zéro (ou presque) avec environ 360 _commits_ pour ce cycle. De nouveaux rapports de bogues apparaissent automatiquement à chaque _build_ et nous en corrigeons quelques autres. Actuellement, le total des rapports est de deux (sur plus de 6 millions de lignes analysées). Heureusement, conserver ce nombre à zéro est un but raisonnablement accessible : ![Graph of coverity static checking issues](http://people.gnome.org/~michael/images/2015-08-01-coverity-stats.png) ## PVS-Studio ## La compagnie OOO « Program Verification Systems » développe l’outil d’analyse statique PVS-Studio et a publié les résultats d’une analyse unique rendue disponible pour les développeurs de LibreOffice. Des douzaines de problèmes rapportés ont été corrigés par Caolán McNamara (RedHat), Michael Stahl (RedHat), David Tardon (RedHat) et Markus Mohrhard. Vous pouvez en apprendre plus sur ce point [ici (illustrations incluses)](http://www.viva64.com/en/b/0308/). ## Tests de l’importation et de l’exportation ## Grâce au nouveau matériel de crash-tests [payé par les donateurs] (https://people.gnome.org/~michael/blog/2015-01-29-under-the-hood-4-4.html#impexp) et aux efforts significatifs de Caolán McNamara (RedHat), Michael Stahl (RedHat), Markus Mohrhard et plusieurs autres, nous avons réduit à pratiquement zéro un nombre d’assertions (paranoïaques) et de crashs d’importation sur notre imposant corpus de documents de tests (plus de 75 000 documents douteux et bogués). C’est merveilleux de pouvoir saisir au vol les _commits_ qui provoquent des régressions et les corriger en quelques jours seulement sur _master_, avant qu’ils aient une chance d’atteindre les utilisateurs. ![Graph of import crash-testing results](http://people.gnome.org/~michael/images/2015-08-01-impexp-import.png) ![Graph of export crash-testing results](http://people.gnome.org/~michael/images/2015-08-01-impexp-export.png) Le travail en cours est de compiler les binaires des crash-tests avec `Adress Sanitizer` et aussi de commencer à tester différents types de documents et d'étendre l'ensemble des types de fichiers en entrée. ## Greffons Clang / vérificateurs ## Nous avons continué à ajouter des greffons à notre compilateur clang ; un rapide `git grep` avec le motif « Registration » dans les greffons du compilateur montre que nous sommes passés de 38 à 59 au cours des six derniers mois (croissance doublée depuis la dernière version). Ceux-ci sont utilisés pour vérifier toutes sortes de vilains pièges, et aussi pour ré-écrire automatiquement différents bouts de codes problématiques. Beaucoup sont exploités automatiquement par _tinderboxes_ pour attraper des erreurs. Merci à : Stephan Bergmann (Red Hat) et Noel Grandin (Peralex) pour leur travail acharné sur ces vérificateurs lors de ce cycle. Les nouvelles extensions font toutes sortes de choses, et viennent généralement avec un ensemble de correctifs pertinents pour le code sous-jacent ; Voici quelques exemples : * `loplugin:loopvartoosmall` - vérifie que la variable d'index de boucle est d'au moins la taille de ce qu'elle indexe. Dans le cas de valeurs non signées, cela peut protéger de boucles infinies. Dans les autres cas, cela évite simplement de tronquer les données. * `loplugin:staticmethods` - cherche les méthodes qui peuvent être déclarées `static`. C'est à la fois plus efficace et rend le code plus compréhensible, puisque cela indique clairement que la méthode ne dépend de l'état d'aucun objet. * `loplugin:vclwidget` - met en application différentes règles sur l'usage de notre nouveau pointeur intelligent à compteur de référence `VclPtr` pour les objets `VCL`. Les classes à compteur de référence peuvent être délicates à utiliser dans les cas limites, donc avoir un vérificateur qui valide à la compilation autant de règles autrement implicites est vraiment très utile. * `loplugin:constantfunction` - cherche les fonctions qui devraient être supprimées ou avoir le mot clé `inline`, puisqu'elles retournent toujours la même valeur. C'est utile pour trouver du vieux code devenu redondant du fait du ré-usinage. * `simplifybool` - il détecte et démêle des expressions booléennes particulièrement alambiquées pour les simplifier. Par exemple en convertissant `a ? false : true` en `!a`. * `cstylecast` et `redundantcast` - ceux-ci détectent et préviennent les _casts_ en style langage C, par exemple `class Foo; Foo *pFoo = (Foo *)pBaa;`, donc quand le type est incomplet. On devrait utiliser le beaucoup plus sûr `static_cast`. Ils détectent et suppriment également les _casts_ inutiles pour que le code soit plus facile à comprendre. * `de-virtualization` - il détecte les méthodes virtuelles qui ne sont jamais surchargées pour les remplacer par des méthodes non virtuelles qui sont plus rapides. * `lopluign:deletedspecial` - trouve les déclarations de membres de fonctions spéciales qui restent indéfinies, et qui en réalité, devraient être marquées comme supprimées pour apporter des optimisations de compilation et des _warnings_. D'autres séries de nettoyages ont également été assistées par Clang telles que l'action de Noel sur le nettoyage, rendant nos énumérations cohérentes et améliorant leur portée. Le lecteur de Stephan pour détecter et supprimer la _conversion de bool_ implicite, le passage de nombreuses méthodes _inline_ de _sal_Bool_ (vraiment en _unsigned char_) à un véritable _bool_ chaque fois que possible, et plusieurs autres extensions utiles. ## Tests unitaires ## Nous avons également construit et exécuté plus de tests unitaires avec LibreOffice 5.0 pour éviter les régressions lorsque nous modifions le code. Une recherche (grep) sur les macros TEST et ASSERT nous indique une augmentation du nombre de tests unitaires : ![Graph of number of unit tests and assertions](http://people.gnome.org/~michael/images/2015-08-01-unit-tests.png) Notre idéal est que chaque bogue qui est corrigé ait un test unitaire pour éviter qu'il revienne. Avec près de 800 changements, et plus de soixante-dix auteurs pour les tests unitaires de la version 5.0, il est difficile d'énumérer ici toutes les personnes impliquées, nous nous en excusons ; ce qui suit est une liste triée de ceux qui ont 10 fois plus de changements par répertoires concernés de *Q&A* : Miklos Vajna (Collabora), Markus Mohrhard, Caolan McNamara (RedHat) Stephan Bergmann (RedHat), Noel Grandin (Peralex), Michael Meeks (Collabora), Michael Stahl (RedHat), Zolnai Tamás, Tor Lillqvist (Collabora), Bjoern Michaelsen (Canonical), Eike Rathke (RedHat), Takeshi Abe, Andras Timar (Collabora), PriyankaGaikwad (Synerzip). ## Tests de Windows ## Alors que nous avions un sous-ensemble de tests unitaires que l'on lançait au moment de la compilation sous Windows, notre batterie de tests plus large était entravée par des problèmes étranges de comportement de tâches, liés à la gestion de plusieurs fenêtres et d'événements. Grâce à divers verrous et messages inter-tâches de Michael Stahl (RedHat) et de Stephan Bergmann (Redhat), nous avons maintenant des tests unitaires beaucoup plus robustes et fiables sous Windows. ## QA / bugzilla ## Une mesure que nous regardons lors des réunions du ESC (Engineering Steering Committee) est de savoir qui est dans le top dix du [résumé hebdomadaire de bogues](https://bugs.documentfoundation.org/page.cgi?id=weekly-bug-summary.html) de freedesktop. Voici une liste des personnes qui ont figuré plus de cinq fois dans la liste hebdomadaire des meilleurs résolveurs de bogues par ordre de fréquence d'apparition : Adolfo Jayme, Beluga, Caolán McNamara (RedHat), raal, Julien Nabet, Jean-Baptiste Faure, Markus Mohrhard, m.a.riosv, Gordo, V Stuart Foote, Eike Rathke (RedHat), Andras Timar (Collabora), Alex Thurgood, Yousuf (Jay) Philips, Miklos Vajna (Collabora), Joel Madero, Cor Nouws, Michael Stahl (RedHat), Michael Meeks (Collabora), Matthew Francis, David Tardon (Redhat), tommy27, Timur, Robinson Tryon (qubit) (TDF). Et merci aux nombreux autres qui ont aidé à trier et fermer de si nombreux bogues pour cette version. ## Jenkins / CI ## Grâce à Norbert Thiebaud nous avons maintenant une excellente intégration continue via Jenkins/gerrit, ce qui permet de tester la compilation de tous les correctifs qui arrivent sur les trois plateformes principales. Utiliser l'intégration continue pour tester les correctifs avant de les envoyer sur le dépôt principal est devenu un autre outil sans pareil pour augmenter la qualité dudit dépôt (et ainsi son accessibilité aux utilisateurs occasionnels), tout en testant le code pour Windows et Mac sans qu'ils n'aient besoin de vérifier leur code sur ces plateformes par eux-mêmes. Grâce à [ByteMark](https://www.bytemark.co.uk/) et à nos [donateurs](https://donate.libreoffice.org/), nous espérons obtenir plus de matériel plus rapide pour notre ferme d'intégration continue afin de rendre celle-ci encore plus attractive. Avec plus de 25 000 compilations de 13 unités d'intégration depuis le début de l'année (ce qui se compare raisonnablement bien aux quelques 11 000 changements intégrés), nous espérons pouvoir lancer les compilations et les tests sur tous les changements soumis sans introduire de retard significatif. Aussi pour le prochain cycle de développement, nous avons ajouté des tests outre ceux exécutés lors de la compilation. Nous activons un tas de propositions supplémentaires dans une version _dbgutil_, l'exécutons et faisons vérifier au moins sur Linux en appliquant un ensemble beaucoup plus vaste de tests supplémentaires à chaque apport individuel. ## Bibisect étendu ## Dans ce cycle, nous avons étendu les remarquables dépôts de [Bi(nary)Bisect(ion)](https://wiki.documentfoundation.org/QA/Bibisect) - qui contiennent des milliers de binaires pré-compilés compressés pour permettre aux utilisateurs de déterminer rapidement quel est le changement susceptible d’avoir introduit une régression longtemps après - jusqu'à inclure les réalisations Windows et Mac de la période 5.0 (c’est-à-dire de la branche 4.4 à la branche 5.0). La période 5.1 est compilée et rafraîchie régulièrement à un rythme raisonnable. Mille mercis à Norbert Thiebaud, Matthew Jay Francis & Robinson Tryon (qubit) (TDF). # Nettoyage de code # Le code sale devrait être nettoyé — et c'est ce que l'on a fait de-ci, de-là : ## Mise à jour vers (un) sous-ensemble de C++11 ## Dans la version 5.0, nous avons commencé à migrer agressivement vers un sous-ensemble de C++11 que l'on peut maintenant utiliser avec notre compilateur mis-à-jour, et ainsi utiliser les modèles variadiques, l'initialisation plus simple, et bien d'autres. Du travail visant à enlever des bouts obsolètes de la `std` tels que les `std::ptr_fun` utilisant `std::any_of` et `std::none_of`. Les lauriers reviennent aux nettoyeurs de code dont Stephan Bergmann (RedHat), Takeshi Abe, Nathan Yee, Bjoern Michaelsen (Canonical) et bien d'autres. ## Nettoyage du cadriciel ## Grâce à Maxim Monastirsky, nous avons éliminé du cadriciel plusieurs centaines de lignes de code redondant, en créant des contrôleurs génériques configurés par de petits fichiers XML. C'est agréable de voir de tels nettoyages. ## Expansion des types d'index entiers ## Un certain nombre d'anciennes structures dans LibreOffice ont utilisé des index de 16 bits, et stocké/sérialisé ceux-ci dans diverses structures pendant de nombreuses années. Cela peut causer des problèmes lors de la fusion de très gros messages de courrier - tels que ceux utilisés dans la ville de Munich. Grâce à Katarina Behrens (CIB), Writer 5.0 permet plus de 64k de descriptions de page, de sections et de noms de style. ## Réduction des commentaires allemands ## Nous avons continué de progresser, mais d’une manière ou d’une autre les [dernières ~5000 lignes](http://people.gnome.org/~michael/data/2015-08-01-german-comments.txt) de commentaires semblent défier toute tentative de traduction. Toute aide des germanophones via courriel est grandement appréciée. Mille mercis à Michael Weghorn, Michael Jaumann (Munich), Daniel Sikeler (Munich), Albert Thuswaldner, Christian M. Heller et Philipp Weissenbacher. Il ne reste à présent que huit modules à traduire : include, reportdesign, rsc, sc, sfx2, stoc, svx, sw. ![Graph of remaining lines of German comment to translate](http://people.gnome.org/~michael/images/2015-08-01-german-comments.png) ## Conteneurs std:: ## Nous avons continuellement amélioré notre utilisation des conteneurs `std::` à travers notre code. Des choses comme éviter l’héritage de `std::vector`, changer `std::deque` pour `std::vector` et commencer à utiliser les nouveaux constructeurs C++ pour des itérations comme `for (auto& it : aTheContainer) { ... }`. Il y a beaucoup de gens à remercier ici. Merci à Stephan Bergmann (RedHat), Takeshi Abe, Tor Lillqvist (Collabora), Caolan McNamara (RedHat), Michaël Lefèvre, et beaucoup d’autres. ## Writer ## Grâce à Bjoern Michaelsen (Canonical), dans la version 5.0, Writer a reçu un nettoyage longtemps désiré sur nombre de points-clés : * Amélioration et factorisation de plusieurs implémentations UNO du noyau de Writer concernant les tables, réduisant la taille du code d’environ 20 % et éliminant du code redondant. Des tests unitaires ont été ajoutés et il devrait maintenant être plus facile d’en ajouter d’autres, y compris pour vérifier le noyau de Writer. * Nettoyage de certaines classes très anciennes implémentant le modèle observateur d’une manière maladroite (SwClient/SwModify). Ajout d’un atelier de tests afin de clarifier son interface. En fin de compte, l’objectif est de s’éloigner de cette implémentation vers une des implémentations plus modernes que nous utilisons ailleurs. Ce travail devrait aider à trouver une voie de migration plus tard. * Plusieurs implémentations ad hoc de [listes doublement chaînées](https://en.wikipedia.org/wiki/Doubly_linked_list) intrusives ont été consolidées et fondues en une seule : `sw::Ring`. Ajout de tests pour clarifier son interface. * Utilisation de [greffons du compilateur](https://gerrit.libreoffice.org/gitweb?p=core.git;a=tree;f=compilerplugins/clang/store;h=master) pour chasser à la fois les expressions conditionnelles en cascade les plus profondes et les affectations survenant au cours de l’évaluation des instructions conditionnelles, qui sont source d’erreurs, et transformer les pires contrevenants en quelque chose de plus lisible et de plus facilement maintenable. ## Le _resourcemodel_ de _writerfilter_ ## Le bloc de construction de `resourcemodel` de `writerfilter` (qui gère l'importation des DOCX et RTF de Writer dans LibreOffice) était essentiellement un tas de vieux trucs inutilisés. Les quelques morceaux encore nécessaires de celui-ci sont maintenant déplacés dans les parties utiles de `mapper / tokenizer / filter`, et le reste est maintenant supprimé. Vous pouvez lire plus de [détails](http://vmiklos.hu/blog/resourcemodel.html) grâce à Miklos Vajna (Collabora). # Autres gains # Nous avons eu un certain nombre d'autres victoires qui sont un peu difficiles à classer, mais voici ce qui mérite d'être noté : ## OOXML contre MS Office 2007 ## MS Office 2007 dispose d'un ensemble inutile de différentes valeurs par défaut pour beaucoup de ses attributs - par exemple, le même XML (avec un attribut manquant) peut produire des résultats différents dans Office 2007 et dans les versions suivantes. Il est clair que c'est assez irritant. Merci à Markus Mohrhard d'avoir ajouté certaines infrastructures (et un ensemble de correctifs) pour les attributs problématiques connus à cet égard. Cela devrait améliorer notre interopérabilité avec ce bazar de documents. ## Abstraction du système de fichiers Android ## Grâce aux donateurs de *TDF* et à Jacobo Aragunde Pérez (Igalia), nous avons mis en place une API d'abstraction de système de fichiers pour Android - pour permettre aux backends des systèmes de fichiers arbitraires d'être connectés (dans un processus séparé). Un exemple de backend OwnCloud a été mis en œuvre pour montrer ce cas. ## Trucs de base ## Grâce à Matthew Nicholls nous avons supprimé deux mille lignes de code de _glue_ redondant dans la partie `dbtoolsclient` de `svx`, qui était dupliqué ailleurs dans `connectivity`. C'est génial de voir autant de cochonneries quitter le code. # S'impliquer # J'espère que vous admettez l'idée que de plus en plus de développeurs se sentent chez eux sur LibreOffice et travaillent ensemble à l’achèvement de certains travaux significatifs aussi bien sous le capot qu'en surface. Si vous voulez vous impliquer, il y a beaucoup de gens formidables à rencontrer et avec qui travailler. Comme vous pouvez le voir, les individus ont un impact énorme sur la diversité de LibreOffice (les légendes de couleur à droite doivent être lues de gauche à droite, de haut en bas, et vues de haut en bas sur le graphique) : ![Graph showing individual code committers per month](http://people.gnome.org/~michael/images/2015-08-01-committers.png) Également en termes de diversité des changements apportés dans le code, nous aimons voir le volume des contributions spontanées des bénévoles, bien que clairement, volume et équilibre changent avec les saisons, le cycle de sorties, et les projets de vacances / affaires des bénévoles : ![Graph of number of commits per month by affiliation](http://people.gnome.org/~michael/images/2015-08-01-commits.png) Naturellement, nous maintenons une [liste de tâches de petites tailles](https://wiki.documentfoundation.org/Development/Easy_Hacks), que vous pouvez consulter pour participer, avec des [instructions simples de compilation / configuration](http://www.libreoffice.org/developers/). Il est extrêmement facile de compiler LibreOffice, chaque _easy-hack_ ayant des liens vers le code et incluant une tâche facile à résoudre. En outre, certains d'entre eux sont des fonctionnalités vraiment sympas à avoir ou des améliorations de performance. Merci de ne pas vous considérer limité par quoi que ce soit. Autre chose qui aide vraiment est d'exécuter des pré-versions et faire des rapports de bogues. Il faut juste récupérer et installer une [pré-version](http://www.libreoffice.org/download/pre-releases/) et vous êtes prêt à contribuer aux côtés du reste de l'équipe de développement. # Conclusion # LibreOffice 5.0 est une excellente base pour construire les prochaines versions qui seront améliorées peu à peu, non seulement en fonctionnalités, mais également la base d’un intégré bureautique libre. Ce n’est bien sûr pas encore parfait, c’est la première publication d’une longue série de sorties mensuelles pour le cycle 5.0.x, et de sorties biannuelles pour le cycle 5.x, qui apporteront un flux de corrections et d’améliorations de la qualité pour les mois et années à venir. J'espère que vous aimerez LibreOffice 5.0.0. Merci pour la lecture de ce billet, et n'oubliez pas de jeter un œil sur les [nouveautés visibles par les utilisateurs](https://wiki.documentfoundation.org/ReleaseNotes/5.0/fr) et merci de soutenir LibreOffice. La plupart des [données brutes](http://people.gnome.org/~michael/data/2015-08-01-5.5-data.ods) pour les graphiques ci-dessus sont disponibles.

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