LibreOffice : de 5.0 à 5.2, un an après

LibreOffice 5.2 est publié depuis le 3 août 2016. Cette nouvelle version est destinée aux utilisateurs expérimentés — les autres, comme les entreprises et les administrations, sont invités à utiliser LibreOffice 5.1.6

Michael Meeks est un développeur qui travaille sur la suite bureautique LibreOffice pour l’éditeur Collabora.

Il vient de publier sur son blog une longue description du travail de refactorisation et de nettoyage qui a eu lieu lors de cette année de développement menant de la version 5.0 à la version 5.2 de LibreOffice. Cette dépêche est une traduction de son article initialement publié dans le domaine public ou licence CC0, comme indiqué au bas de l’article.

Sommaire

• Centre développeurs
• La fin de Vigra
• Améliorations de l’accélération matérielle
• Améliorations des performances
• Rapports de crashs
• Travail en cours sur la qualité du code
• Améliorations du cycle de vie
• Tests unitaires
• Améliorations de LibreOfficeKit
• Divers
• QA / bugzilla
• Jenkins / CI
• Réduction des commentaires en allemand
• Windows XP
• Contribuer
• Conclusion

Aujourd’hui nous publions LibreOffice 5.2.0, la dernière étape de notre voyage, qui sera la base de la toujours plus stable série 5.2.x. Il y a une belle série de nouveautés, faites par des super‐développeurs, qui plairont aux utilisateurs finals (vous pouvez lire les notes de version pour vous réjouir), mais, comme toujours, il y a beaucoup de contributeurs dont le travail se fait principalement dans les coulisses et dont les œuvres concernent surtout la technique plutôt que ce qui est visible des utilisateurs.

Il y a quelque temps, l’ESC (Engineering Steering Comittee, le comité de pilotage d’ingénierie) a décidé d’ajouter quelques pages wiki à propos du travail fait sous le capot, pour que les gens puissent ajouter leurs propres crédits. Je vous encourage à lire les pages 5.1 et 5.2. Il y a beaucoup de bonnes choses et ça m’évite de devoir lire et résumer les ≃ 10 000 commits de chaque version, même si, là encore, ça peut être drôle. Ceci est ma très rapide tentative pour parler de l’année écoulée au travers des 17 734 commits (ce qui donne environ 50 commits par jour) depuis libreoffice-5-0-branch-point jusqu’à libreoffice-5-2-branch-point.

Centre développeurs

Une excellente initiative de Norbert Thiebaud a été de collecter et centraliser la plupart des infrastructures et leur point d’entrée disponibles au sein de TDF (The Document Foundation) dans une jolie liste afin d’aider les nouveaux arrivants à trouver et utiliser nos outils et services. Jetez‐y un œil : http://devcentral.libreoffice.org/.

La fin de Vigra

LibreOffice a été en mesure de fonctionner en mode headless (sans écran ni clavier), en faisant sa propre et longue chasse aux pixels, ce qui est utilisé de manière intensive à la fois par LibreOffice en ligne et aussi par le portage de GTK3/Linux. Ça a été, pour moi‐même et pour d’autres, une source d’étonnement sans fin que le code (illisible) du modèle de Vigra produise un code aussi peu performant dans toutes sortes de cas. Une des grandes joies avec LibreOffice 5.2, c’est la mort définitive de Vigra et du répertoire basebmp et l’utilisation de Cairo en natif (accéléré par l’assembleur) pour la chasse aux pixels. Merci à Caolan McNamara (Red Hat) pour tout ça.

Améliorations de l’accélération matérielle

Pendant cette période, un grand nombre d’améliorations a été apporté à OpenGL et OpenCL :

• Le modèle de rendu d’OpenGL a été fortement simplifié — en effectuant tous les rendus par une texture en back‐buffer à double mise en tampon, puis en les affichant à l’écran à un moment inactif après une requête de rafraîchissement. Il s’agit de la suite des travaux réalisés pour Mac OS X et désormais GTK 3. Combiné avec quelques ajustements dynamiques dans les priorités des rendus, cela donne un rafraîchissement et des redimensionnements doux sans traces. Ce travail a également fortement simplifié la gestion et le cycle de vie des contextes GL.

• Protection contre les crashs d’OpenGL et CL — en raison du grand nombre de problèmes dans la qualité des pilotes — nous avons mis en place une surveillance de chaque appel à GL ou CL — de façon à ce que notre gestionnaire de crashs puisse détecter un plantage lié à ceux‐ci et, dans ce cas, désactiver la fonctionnalité au redémarrage.

• Vérification du comportement d’OpenCL et OpenGL avant leur utilisation réelle, notamment pour éviter des problèmes fonctionnels, en particulier de mauvais calculs dans le tableur.
  Ainsi, à chaque changement de version du pilote CL ou de LibreOffice, nous recalculons une feuille de test au lancement et en vérifions les résultats, afin de détecter un mauvais comportement des implémentations CL et pour désactiver, si besoin, l’accélération CL. De même, pour OpenGL, nous compilons par lots et mettons en cache tous nos shaders pour nous assurer qu’il n’y a pas d’erreurs de compilation qui pourraient causer des problèmes plus tard.

• Améliorations de la mise en liste noire d’OpenGL et CL, avec de jolis fichiers cache/opengl_device.log contenant des détails de vos pilotes. Après beaucoup de travail, nous avons découvert que les pilotes GL d’Intel sous Windows 7 étaient incroyablement loufoques et donc ont été mis en liste noire.

• Les performances ont beaucoup été améliorées en combinant les shaders. Il est intéressant de noter que la charge pour passer d’un shader à un autre, ainsi que pour les changements d’état des programmes associés, est très significative. Ce qui fait que l’utilisation d’un seul, et assez compliqué, shader qui gère de nombreux cas est plus rapide que plusieurs shaders très simples (un par cas). C’est pourquoi nous avons fusionné toutes nos routines de dessin texturé et non texturé dans deux gros shaders combinés, qui contiennent un switch().

• En combinaison avec ça, le travail de groupement et de mise en file pour agréger de nombreuses opérations de dessin en une seule invocation de GL/programme nous confère un avantage indéniable. Combiné avec les améliorations de l’atlas textuel [N. D. T. : ???], ceci nous permet de déférer le dessin d’un grand nombre de glyphes en un seul appel GL.

• D’autres accélérations GL incluant l’utilisation d’un shader pour calculer les CRC 64 bits des images (à des fins de comparaison), la mise en cache de nos matrices MVP, et la coordination des transformations spatiales sur le processeur graphique, ainsi que la conversion des dégradés de gris et le rendu des (poly)lignes basées sur les shaders.

• L’absence d’une bonne API pour le rendu matériel des polices de caractères sur Windows nous a poussés à implémenter la prise en charge de DirectWrite pour le rendu du texte. Merci à Tim Eves (SIL) et Martin Hosken (SIL).

• Il y a aussi de nombreuses améliorations et corrections diverses : l’implémentation de « invert », l’amélioration de l’anticrénelage, le rendu XOR, la subdivision des polygones basés sur des angles, l’amélioration et l’accélération du clipping [N. D. T. : je crois qu’il s’agit de la découpe du rendu par petits cadres à la façon de Google Map, ça sert surtout pour l’affichage Web], de meilleurs chemins de tests pour vcldemo, l’amélioration du rendu des widgets natifs. Il y a aussi des petits bouts d’amélioration sur les bogues du cycle de vie et du nettoyage fait sur la fermeture, ainsi que de nombreuses corrections de bogues.

Merci donc à tous ceux ayant fait plus de cinq commits dans vcl/opengl, opencl/ et sc/source/core/opencl : Tomaž Vajngerl (Collabora), Tor Lillqvist (Collabora), Noel Grandin (Peralex), Stephan Bergmann (Red Hat), Caolán McNamara (Red Hat), Markus Mohrhard et Marco Cecchetti (Collabora).

Améliorations des performances

Les améliorations des performances sont difficiles à montrer mais sont malgré tout importantes. Nous maintenons des tests de régression de performance (qui tournent sous Valgrind) à l’adresse http://perf.libreoffice.org, ce qui aide vraiment à localiser avec précision les problèmes lorsqu’ils apparaissent.

Une belle victoire dans les travaux sur la 5.2 que celle d’Armin Le Grand (CIB) pour améliorer notre gestion des threads et s’en servir pour accélérer le rendu 3D logiciel — ce qui donne une accélération particulièrement notable du rendu des graphiques en 3D.

Rapports de crashs

Markus Mohrhard a fait un travail tout simplement excellent sur les rapports de crashs — pour nous aider à trouver les plantages les plus fréquents sur Windows. Alors que de nombreuses distributions GNU/Linux ont des outils similaires déployés depuis des années, couvrir Windows était également important. L’implémentation réutilise Breakpad de Google pour créer des mini‐vidages de mémoire qui sont analysés côté serveur et joliment tracés sur http://crashreport.libreoffice.org/stats/.

Markus aimerait l’aide de quelqu’un ayant des compétences en développement Web pour l’aider à améliorer l’interface, et l’analyse, l’interrogation et la présentation des données. Merci de vous signaler sur la liste des développeurs libreoffice@lists.freedesktop.org.

Ce travail a déjà permis plusieurs correctifs vitaux pour les crashs les plus récurrents, en utilisant les données adéquates pour remédier aux plus gros problèmes de qualité. Merci à Markus Mohrhard, Caolán McNamara (Red Hat) et Miklos Vajna (Collabora) dont les commits référencent les adresses URL de rapports de crash.

Travail en cours sur la qualité du code

Il y a du travail en cours sur la qualité du code dans de nombreuses zones, avec au moins 196 correctifs issus de cppcheck. Merci à Caolán McNamara (Red Hat), Julien Nabet, Jochen Nitschke, Noel Grandin (Peralex), Michael Weghorn, Takeshi Abe, Giuseppe Castagno et aux autres.

Caolán et les gars de Red Hat font en sorte de garder le compte d’erreurs de l’analyse de Coverity et le nombre de crash‐tests (charger et sauvegarder ≃ 91 000 documents en plein de formats) à près de zéro tout le temps, en faisant également des tests aléatoires (fuzzing) et d’autres corrections.

Améliorations du cycle de vie

En poursuivant la refonte du VclPtr [N. D. T. : pointeur sur les objets du toolkit graphique], où nous avons ajouté un robuste cycle de vie référencé à tous nos widgets, Dipankar Niranjan (rapport de bogue TDF nᵒ 96888) a nettoyé entièrement le vieil et horrible outil de référencement qui essayait de gérer le cycle de vie correctement à l’intérieur de VCL, en utilisant des références beaucoup plus propres.
Plus récemment, Yurtoglu, Melike Ayse et Noel Grandin ont œuvré à abstraire la VclReferenceBase et à appliquer ça aux menus, afin de s’assurer que leur cycle de vie soit correctement géré. Merci aussi à Jocken Nitschke pour avoir internalisé le DeletionListener (bogue TDF nᵒ 97525) qui devrait être supprimé quand un jour nous référencerons et compterons les ressources du back‐end sal/ [N. D. T. : « sal » ou « system abstraction layer »].

Il y a un autre travail formidable : avoir exorcisé le comptage de références manuel. Grâce à Thomas Arnhold, Daniel Robertson, Noel Grandin, Aleksas Pantechovskis et surtout Xisco Fauli pour les travaux sur les bogues TDF nᵒ 96525 et nᵒ 89329, qui ont converti de nombreux comptages de référence manuels ou des structures copy‐on‐write pour utiliser l’excellent modèle cow_wrapper. Ils ont aussi converti des pointeurs pIpml pour utiliser std::unique_ptr [N. D. T. : modernisation du code C++]. Ceci réduit l’étendue des erreurs de programmation et des cas particuliers et nous permet de faire des « copy‐on‐write ref‐counting thread‐safe » si nécessaire. Il y a 140 cas corrigés et encore à peu près 68 instances de comptage de références qui ont besoin qu’on s’occupe d’elles.

Tests unitaires

Nous avons continué d’ajouter des tests unitaires critiques cette année. Chacun d’eux permet d’empêcher à jamais la réapparition de régressions. Un grep sur les macros TEST et ASSERT montre que le nombre continue d’augmenter :

Notre rêve est que chaque bogue corrigé soit accompagné d’un test unitaire pour l’empêcher de revenir. Avec environ 1 800 commits (20 % en plus par rapport à l’année dernière) et plus de cent contributeurs durant cette période, c’est difficile de lister tout le monde impliqué ici, mes excuses pour cela ; ce qui suit est une liste triée de ceux avec plus de vingt commits dans core.git et online.git : Miklos Vajna (Collabora), Caolán McNamara (Red Hat), Stephan Bergmann (Red Hat), Ashod Nakashian (Collabora), Noel Grandin (Peralex), Markus Mohrhard, Tor Lillqvist (Collabora), Eike Rathke (Red Hat), Michael Stahl (Red Hat), Henry Castro (Collabora), Chris Sherlock, Varun, Andrea Gelmini, Jan Holesovsky (Collabora), Takeshi Abe, Łukasz Hryniuk, Xisco Faulí, Mike Kaganski (Collabora) et ceux avec plus de 10 commits ont aussi droit à une mention honorable — les tests unitaires sont importants ! David Tardon (Red Hat), Katarina Behrens (CIB), Marco Cecchetti (Collabora), Tomaž Vajngerl (Collabora), Oliver Specht (CIB), Zdeněk Crhonek, Mark Hung, Justin Luth, Julien Nabet, Aleksas Pantechovskis, Pranav Kant (Collabora).

Améliorations de LibreOfficeKit

L’API LibreOfficeKit est le fondement de l’application Android, GNOME Documents et le travail en cours sur LibreOffice Online, et beaucoup de choses ont changé l’année dernière. Les deux principaux blocs de construction de l’API LOK sont les méthodes des objets exposés et les types de rappels. Depuis la version 5.0, les nouvelles méthodes suivantes ont été ajoutées :

• lok::Office::getFilterTypes() permet d’obtenir une liste à jour de noms filtrés — paire de types MIME, ajouté pour GNOME documents ;
• lok::Office::setOptionalFeatures() et lok::Office::setDocumentPassword() permet d’ouvrir un document protégé par mot de passe ;
• lok::Office::freeError() permet de libérer une chaîne de caractères d’erreur allouée par l’API ;
• lok::Document::getPartPageRectangles() permet d’obtenir la taille et la position des pages d’un document Writer ;
• lok::Document::getTileMode()permet aux clients qui écrivent de travailler avec le nouveau (Cairo) et l’ancien (Vigra) backend headless (voir plus haut) ;
• lok::Document::initializeForRendering() a été étendu pour accepter une option clef‐valeur durant l’initialisation, comme le mode « espaces cachés » de Writer ;
• lok::Document::postMouseEvent() a été étendu pour manipuler les clics et les modificateurs ;
• lok::Document::postUnoCommand() a été étendu pour obtenir un rappel lorsque le résultat d’une commande UNO est prête ;
• lok::Document::getTextSelection() et lok::Document::paste() ont été ajoutés pour manipuler le copier‐coller ;
• lok::Document::getCommandValues() a été ajouté pour pourvoir effectuer des requêtes sur les valeurs possibles pour les commandes UNO (police et nom de style, détails des en‐têtes de lignes et de colonnes de Calc, curseur de cellules Calc) ;
• lok::Document::setVisibleArea()a été ajouté pour pouvoir pour avancer ou reculer d’une page correctement ;
• lok::Document::createView(), lok::Document::destroyView(), lok::Document::setView(), lok::Document::getView() et lok::Document::getViews() ont été ajoutés pour un début de prise en charge de l’édition collaborative ;
• lok::Document::renderFont() a été ajouté pour aider à la prévisualisation des polices ;
• lok::Document::getPartHash() a été ajouté pour aider les clients à suivre la réorganisation des diapos ;
• lok::Document::paintPartTile() a été ajouté pour permettre un rendu sans état de différentes parties d’un document.

Et les nouveaux rappels suivants sont disponibles :

• LOK_CALLBACK_DOCUMENT_SIZE_CHANGED : la taille du document a changé ;
• LOK_CALLBACK_SET_PART : le numéro de la partie courante est modifié ;
• LOK_CALLBACK_SEARCH_RESULT_SELECTION : les rectangles de sélection des résultats quand on utilise la fonctionnalité « Tout rechercher » ;
• LOK_CALLBACK_UNO_COMMAND_RESULT : le résultat de l’exécution d’une commande UNO ;
• LOK_CALLBACK_CELL_CURSOR : la taille et/ou la position d’un curseur de cellule a changé ;
• LOK_CALLBACK_MOUSE_POINTER : le style courant du pointeur de souris ;
• LOK_CALLBACK_CELL_FORMULA : le contenu textuel de la barre de formule dans Calc ;
• LOK_CALLBACK_CONTEXT_MENU : la structure du menu contextuel (après un clic droit).

Merci à Andrzej Hunt (Collabora), Ashod Nakashian (Collabora), Henry Castro (Collabora), Jan Holesovsky (Collabora), Michael Stahl (Red Hat), Mihai Varga (Collabora), Miklos Vajna (Collabora), Oliver Specht (CIB) et Pranav Kant (Collabora) pour cela.

Divers

Un des apports réalisés lors de notre Hackfest turque à Ankara fut la découverte que LibreOffice ne se compile même pas avec les paramètres régionaux tr_TR.UTF-8. Il est intéressant de constater que dans cette langue, toupper('i') != 'I' ; amusant (cf. Bogue TDF nᵒ 99589). Merci à Krishna Keshav, Gökhan Gurbetoğlu et Apurva Priyadarshi pour les corrections.

Un grand nombre de défauts de l’expérience utilisateur ont été corrigés et améliorés, comme les raccourcis clavier, les problèmes de cohérence de l’affichage, les contrôles mal placés et mal dimensionnés, ainsi que quelques régressions concernant la conversion des fichiers d’interface. Merci à Caolán McNamara (Red Hat), Akshay Deep, Regina Henschel, Maxim Monastirsky, Jürgen Funk (CIB), Bubli Behrens (CIB), Samuel Mehrbrodt (CIB) et Jay Philipps.

QA / bugzilla

Une métrique que nous regardons lors des conférences ESC, c’est qui est dans le top 10 du résumé hebdomadaire de freedesktop.org. Voici une liste de personnes qui sont apparues plus de dix fois parmi ceux clôturant le plus de bogues. Dans l’ordre de fréquence d’apparition : Stuart Foote, Adolfo Jayme, Cor Nouws, Maxim Monastirsky, Eike Rathke (Red Hat), raal, m.a.riosv, Julien Nabet, Caolán McNamara (Red Hat), Miklos Vajna (Collabora), Beluga, Alex Thurgood, Michael Meeks (Collabora), Buovjaga, Yousuf (Jay) Philips, Joel Madero, Samuel Mehrbrodt (CIB), Markus Mohrhard, Timur, Jean‐Baptiste Faure, Xisco Faulí, Aron Budea, tommy27, Michael Stahl (Red Hat), Heiko Tietze, David Tardon, Laurent BP. Avec beaucoup de remerciements pour tous les autres qui ont aidé à clôturer et trier un tel nombre de bogues pour cette version.

Jenkins / CI

Principalement grâce à Norbert Thiebaud, nous disposons désormais, non seulement d’une infrastructure d’intégration continue sous Jenkins, associée à Gerrit, mais aussi d’une ferme de compilation agrandie disposant d’un matériel plus fiable, ce qui encourage les utilisateurs à utiliser Jenkins pour vérifier leur travail avant l’envoi de leur code. Cela se concrétise par une qualité et une fiabilité renforcées de la branche principale. Cette année, nous avons constaté les bénéfices engendrés par notre suite de vérification des tests unitaires sur nos compilations de débogage sous GNU/Linux.

Le travail accompli par Jenkins simplement sur la branche principale pour les six mois de route vers la branche 5.2 : nous avons 34 124 compilations sur Tinderbox couvrant sept configurations sous GNU/Linux, Mac OS X et Windows. Avec 27 737 compilations couvrant ces trois plates‐formes testées sur notre infrastructure Gerrit. Ça, c’est pour le matériel d’intégration continue, il y a de nombreux autres volontaires qui lancent des Tinderbox builders. Ceci est extrêmement utile pour maintenir la branche master compilable et utilisable, rendant l’arrivée des nouveaux plus facile. Avec 60 000 compilations pour 8 000 commits, nous faisons beaucoup de tests en boucle et de validation du code de LibreOffice au rythme de l’intégration continue.

Réduction des commentaires en allemand

Parmi mes héros préférés, il y a ceux qui clarifient le code pour que les autres puissent travailler dessus. L’une des tâches clefs est la traduction des commentaires en allemand restants (liste). Les dernières 4 000 lignes semblent défier toute tentative de traduction — je n’ai aucune idée des raisons pour lesquelles ce graphe s’aplatit de la sorte. Tous les correctifs provenant de personnes parlant allemand aimant finir le travail seront grandement appréciés. Un grand merci à ceux qui sont dessus, avec plus de deux commits ; dans l’ordre du nombre de commits : Albert Thuswaldner, Phillip Sz, Thomas Klausner, Chris Sherlock, Philipp Weissenbacher et Matteo Casalin. Il ne reste plus que sept modules à traduire : include, reportdesign, sc, sfx2, stoc, svx et sw.

Windows XP

La série 5.2.x tourne bien sur Windows XP, mais nous ne pouvons pas savoir combien de temps nos outils continueront à prendre en charge cette plate‐forme. Notre gouvernance n’a pas de plans concrets visant à supprimer la prise en charge de Windows XP, nous allons le marquer obsolète après la série 5.2.x — ce qui signifie qu’avoir pour base un compilateur C++ moderne et un système d’exploitation Windows moderne est une plus grande priorité. Cela signifie qu’à l’avenir il est possible que les futures versions majeures de LibreOffice ne tournent pas sur Windows XP ; vous êtes prévenus. Pour l’instant, pas de changement à ce niveau.

Contribuer

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 réaliser des travaux importants à la fois sous le capot et sur la carrosserie. Si vous voulez vous impliquer, il y a plein de gens compétents à 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 des couleurs se lit de gauche à droite, de haut en bas, ce qui représente les couleurs de haut en bas dans le graphique. [N. D. T. : les indépendants, c’est le gros morceau vert au sommet]).

Il manque à ces graphiques, générés tôt ce mois, quelques individus et commits mis en attente dans Gerrit pour une revue, d’où le nombre faible en juillet. En termes de diversité, nous adorons voir la quantité de contributions de volontaires non affiliés, bien que le volume et l’équilibre varie selon la saison, le cycle de version, les vacances des volontaires et les business‐plans.

Naturellement, nous maintenons une liste de petites ou minuscules tâches sur notre page Easy Hacks, dont vous pouvez vous emparer pour vous impliquer dans ce projet, avec des instructions simples d’installation ou de compilation. 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.

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 et vous êtes prêt pour contribuer avec l’équipe de développement.

Conclusion

LibreOffice 5.2 est génial, fait par un groupe de développeurs qui travaillent ensemble avec plaisir à construire une suite bureautique libre de plus en plus belle et attirante. J’espère que vous l’apprécierez. Merci pour la lecture. Et n’oubliez pas de vérifier la page des fonctionnalités visibles et merci de soutenir LibreOffice.

Si j’ai raté votre bon travail (car ceci n’est qu’une vue incomplète basée sur quelques heures d’analyse), merci de vous ajouter vous‐même sur la page wiki correspondante et envoyez‐moi un diff de cette page. Merci !

Les données brutes et les statistiques de commits générées via notre gitdm-config sont disponibles pour la plupart des graphiques ci‐dessus.

Aller plus loin

• Article original (448 clics)
• Notes de version 5.2 (460 clics)
• Dépêche de la précédente version (5.1) (134 clics)