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

79
21
nov.
2016
Bureautique

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

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/.

Regroupement des sites web dédiés au développement de LibreOffice

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 doublement bufferisée, 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 et désormais GTK3. 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'erreur de compilation qui pourrait 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é black-listés.

  • 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 (NDT: ???), 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 GPU. 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 (NDT: 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 bugs du cycle de vie, et du nettoyage fait sur la fermeture, ainsi que de nombreuses corrections de bugs.

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 (RedHat), Markus Mohrhard, Tomaž Vajngerl (Collabora), 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) à 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 crash — pour nous aider à trouver les plantages les plus fréquents sur Windows. Alors que de nombreuses distributions 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 minidumps qui sont analysés côté serveur et joliment tracés sur http://crashreport.libreoffice.org/stats/

Affichage d'un graphique de Crash Report

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 / 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 (RedHat) et Miklos Vajna (Collabora) dont les commits référencent les 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 (RedHat), Julien Nabet, Jochen Nitschke, Noel Grandin (Peralex), Michael Weghorn, Takeshi Abe, Giuseppe Castagno et aux autres.

Caolan et les gars de RedHat font en sorte de garder le compte d’erreurs de l’analyse de Coverity et le nombre de crash-tests (charger et sauvegarder ~91k documents en plein de formats) à près de zéro tout le temps, en faisant également du fuzzing et d’autres corrections.

Améliorations du cycle de vie

En poursuivant la refonte du VclPtr (NDT: 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 bug tdf#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 (tdf#97525) qui devrait être supprimé quand un jour nous référencerons/compterons les ressources du backend « sal/ » (NDT: « 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 tdf#96525 et tdf#89329 (NDT : ce sont des rapports de bugs), qui ont converti de nombreux comptages de référence manuels ou des structures copy-on-write pour utiliser l’excellent template « cow_wrapper » ; ils ont aussi converti des pointeurs « pIpml » pour utiliser std::unique_ptr (NDT : 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 :

Histogrammes représentant la croissance du nombre de tests unitaires, de LibreOffice 3.5 à 5.2

Notre rêve est que chaque bug corrigé soit accompagné d'un test unitaire pour l'empêcher de revenir. Avec environ 1800 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 (RedHat), Stephan Bergmann (RedHat), Ashod Nakashian (Collabora), Noel Grandin (Peralex), Markus Mohrhard, Tor Lillqvist (Collabora), Eike Rathke (RedHat), Michael Stahl (RedHat), Henry Castro (Collabora), Chris Sherlock, Varun, Andrea Gelmini, Jan Holesovsky (Collabora), Takeshi Abe, Łukasz Hryniuk, Xisco Fauli, Mike Kaganski (Collabora) et ceux avec plus de 10 commits ont aussi droit à une mention honorable — les tests unitaires sont importants ! David Tardon (RedHat), 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 clé-valeur durant l'initialisation, comme le mode espaces cachés de Writer ;
  • lok::Document::postMouseEvent()a été étendu pour manipuler les clics et les modifieurs ;
  • 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 requêter les valeurs possibles pour les commandes UNO (police et nom de styles, détails des en-têtes lignes/colonnes de Calc, curseur de cellules Calc) ;
  • lok::Document::setVisibleArea()a été ajouté pour pouvoir pour avancer / 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: rectangles de sélection des résultats quand on utilise la fonctionnalité « Tout rechercher » ;
  • LOK_CALLBACK_UNO_COMMAND_RESULT: 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: 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 compile même pas avec les paramètres régionaux tr_TR.UTF-8. Il est intéressant de constater que toupper('i') != 'I' dans cette écriture; amusant (cf. tdf#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 claviers, 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) & 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'apparence : Stuart Foote, Adolfo Jayme, Cor Nouws, Maxim Monastirsky, Eike Rathke (RedHat), raal, m.a.riosv, Julien Nabet, Caolán McNamara (RedHat), 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 (RedHat), 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 / 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 Linux.

Le travail accompli par Jenkins simplement sur la branche principale pour les 6 mois de route vers la branche 5.2 : nous avons 34 124 compilations sur tinderbox couvrant sept configurations sous Linux, Mac et Windows. Avec 27 737 compilations couvrant ces trois plateformes 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 clés est la traduction des commentaires en allemand restants (une liste). Les dernières 4000 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 patchs 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 & Matteo Casalin. Il ne reste plus que sept modules à traduire : include, reportdesign, sc, sfx2, stoc, svx et sw.

Graphique représentant la réduction du nombre de lignes de commentaires en allemand entre LibreOffice 3.3 et 5.2

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 plateforme. 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 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 vert au sommet.])

Graphique représentant le nombre de développeurs par organisation

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.

Graphique représentant le nombre de commits par organisation

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.

  • # atlas textuel

    Posté par . Évalué à 10 (+17/-0).

    Concernant l'«atlas textuel», je vais tenter une explication (même si je ne connais pas le code de LibO). Quand on rend du texte, on doit d'abord avoir à disposition le rendu de la fonte utilisée, dans la taille utilisée, et avec divers autres paramètres (la graisse par exemple). C'est le rôle de bibliothèque comme Freetype. Elles prennent en entrée des descriptions vectorielles (TrueType par exemple) et font le rendu de chaque lettre à la demande. Freetype se contente de renvoyer un tableau à deux dimensions de niveaux d'opacité (parce qu'il y a de l'anti-aliasing évidemment), après on l'utilise comme on veut.

    Or, pour pouvoir minimiser les appels OpenGL, il faut avoir un minimum de textures. Donc, pour rendre un texte, on va rendre toutes les lettres dans la même texture et ensuite, rendre le texte grâce à cette texture. Généralement, on utilise le terme d'«atlas de texture» pour décrire ce genre de texture (ça peut aussi être utilisé avec autre chose que des lettres). Peut-être que «text atlas» (dans la VO) est un atlas de texture spécialisé dans le texte (ce qui ne change fondamentalement pas grand chose).

    Pour aller un peu plus loin, créer une telle texture est intéressant, c'est un problème d'optimisation NP-complet: le 2D bin-packing. Il faut donc trouver des heuristiques de manière à maximiser la place utilisée (ou minimiser la place perdue). Si on dispose de toutes les lettres au départ, c'est la version offline. Mais si on a les lettres au fur et à mesure, c'est la version online, beaucoup plus difficile. Il existe des résultats intéressants sur toutes ces versions et des algorithmes d'approximation (pas forcément simple à comprendre).

  • # Des problèmes d'espaces

    Posté par . Évalué à 2 (+3/-1).

    Je sais que c'est n'est pas le lieu, mais parfois, avec la police par défaut (libération je crois) j'ai des problèmes d'espaces entre les lettres… fort heureusement pour moi, j'utilise monospace au quotidien ^

  • # Anglicisme

    Posté par (page perso) . Évalué à 4 (+3/-0).

    « problèmes de consistance de l’affichage » → « problèmes de cohérence de l'affichage »

    Sinon, bravo pour une dépêche très complète et détaillée (même si c'est « juste » une traduction, ça représente un gros boulot alors félicitations).

  • # Mise à jour intégrée ?

    Posté par . Évalué à 2 (+1/-0).

    Pour les utilisateurs de système sans gestion de package, il serait cool d'avoir une mise à jour intégrée…

    • [^] # Re: Mise à jour intégrée ?

      Posté par . Évalué à 3 (+2/-0).

      Il y a des pistes: https://wiki.documentfoundation.org/Development/Online_Update notamment s'appuie sur ce que fait Mozilla pour Firefox: https://bugs.documentfoundation.org/show_bug.cgi?id=68274

    • [^] # Re: Mise à jour intégrée ?

      Posté par (page perso) . Évalué à 2 (+2/-0).

      Si tu penses aux utilisateurs de "Fenêtres", tu pourrais regarder du côté de Chocolatey (présenté ici en bref -> https://envrac.tahikoi.net/logiciels-libres/mise-a-jour-simplifiee-des-logiciels-de-votre-poste-de-travail-windows/)
      LibreOffice est pris en charge, même si tu as droit à une réinstallation complète à chaque mise à jour, je trouve ça plutôt pratique.

      • [^] # Re: Mise à jour intégrée ?

        Posté par . Évalué à 3 (+0/-0).

        Je ne suis pas un utilisateurs de Winwin, mais je sais qu'il y a chocolatey, wapt et d'autres. Chocolatey sort du lot où ça en est un parmis tant d'autres ? Je dis ça parce que ce serait une bonne nouvelle qu'il y en ai un qui se démarque.

        LibO n'est pas dans le store de MS ?

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: Mise à jour intégrée ?

          Posté par (page perso) . Évalué à 1 (+1/-0).

          Pas d'avis sur wapt, a part que la logithèque est moins fournies, ce qui a fait pencher la balance côté Chocolatey.
          Et comme Chocolatey correspond tout à fait à mon besoin (=mettre à jour le PC de papy avec 1 ligne de commande 2 fois par an, et faire la même chose sur mon pc perso/pro bien plus régulièrement), je n'ai pas laissé sa chance à wapt.

        • [^] # Re: Mise à jour intégrée ?

          Posté par . Évalué à 1 (+0/-0).

          Non, mais Collabora l'a mis dans le store d'Apple et vu comment c'est apparement la galère d'avoir un LibreOffice en français sous macOS, c'est sûrement une bonne idée.

          • [^] # Re: Mise à jour intégrée ?

            Posté par . Évalué à 2 (+1/-0).

            Sinon Madame Michu peut lancer ce truc dans sa console :

            which brew || /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
            brew tap caskroom/cask
            brew cask install --force libreoffice

            Puis aller chopper la VF sur le site web … car il manque une recette libreoffice-fr

            • [^] # Re: Mise à jour intégrée ?

              Posté par (page perso) . Évalué à 4 (+1/-0).

              Sinon Madame Michu peut lancer ce truc dans sa console :

              Madame Michu n'arrivera jamais à écrire un truc aussi long et aussi cryptique dans sa console.
              Et puis d'abord, elle n'a pas de console, l’ordinateur est posé sur la table du salon.

              • [^] # Re: Mise à jour intégrée ?

                Posté par . Évalué à 1 (+0/-0).

                Bon j'ai fait une recette cask pour la langue FR, elle ne sera valable q'un temps

                http://pastebin.com/L56Brf1h

                Il faudrait maintenant faire un script pour générer les recettes pour chaque version et chaque langue, aussi il me faudrait une liste des sha256 associés a charge langue, a faire a chaque nouvelle révision

                Si quelqu'un connaît ou trouver l'info, car scrapper le site me paraît casse gueule

                • [^] # Re: Mise à jour intégrée ?

                  Posté par . Évalué à 1 (+0/-0).

                  Je n'ai pas les connaissances pour comprendre ce qu'est recette cask mais le souci sur Mac OS c'est que tout les logiciels doivent être signés. Si ce n'est pas le cas, il faut faire une combinaison de touche pour pouvoir lancer le programme: https://wiki.documentfoundation.org/MacOS/Gatekeeper

                  Or, ajouter le paquet de langue FR à LibreOffice (qui est par défaut en En-US) casse cette signature. Note que Apache OpenOffice (et feu OOo en son temps) propose un DMG unique pour chaque langue: https://www.openoffice.org/download/index.html
                  Là ou LibreOffice oblige à installer et 2 DMG. (un pour le programme en En-US et un autre pour le paquet de langue FR).

                  • [^] # Re: Mise à jour intégrée ?

                    Posté par . Évalué à 1 (+0/-0).

                    La recette fonctionne comme avec le package d'origine téléchargeable sur le site,
                    il n'y a pas d'altération de la signature du logiciel

                    $ codesign -dv --verbose=4 /Applications/LibreOffice.app
                    Executable=/Applications/LibreOffice.app/Contents/MacOS/soffice
                    Identifier=org.libreoffice.script.LibreOffice
                    Format=app bundle with Mach-O thin (x86_64)
                    CodeDirectory v=20200 size=218 flags=0x0(none) hashes=3+3 location=embedded
                    Hash type=sha1 size=20
                    CandidateCDHash sha1=f0fd5760906f487759b8423463803f9cd2b876b7
                    Hash choices=sha1
                    CDHash=f0fd5760906f487759b8423463803f9cd2b876b7
                    Signature size=8532
                    Authority=Developer ID Application: The Document Foundation
                    Authority=Developer ID Certification Authority
                    Authority=Apple Root CA
                    Timestamp=28 oct. 2016 18:56:02
                    Info.plist entries=20
                    TeamIdentifier=7P5S3ZLCN7
                    Sealed Resources version=2 rules=12 files=5891
                    Internal requirements count=1 size=196
                    

                    Je suis passé à l'étape supérieure : j'ai fait un script pour faire toutes les recettes pour toutes les langues, je me suis renseigné pour la liste des langues-sha256 et je tente de faire passer le principe du script et du template chez homebrew, à la fin de l'exécution du script il faudrait faire un pull request, mais avant je veux savoir si je n'ai pas fait de bêtises dans le template de la recette.

                    Voici le script : http://pastebin.com/W5LsvG2e

  • # LibreOffice online

    Posté par . Évalué à 6 (+5/-0).

    Michael Meeks a fait dernièrement une présentation de leur travail sur LibreOffice online:
    https://people.gnome.org/~michael/data/2016-11-17-libreoffice-online.pdf

  • # Macros

    Posté par (page perso) . Évalué à 5 (+4/-0).

    L'autre jour, j'ai eu besoin d'écrire une petite macro pour un export de compta. Voilà quelques années que je ne touche plus à Office, donc, je me suis dis que j'allais essayer avec Libre Office.
    Et bien, en ayant cherché une petite matinée, j'avoue que je n'y suis pas arrivé et je l'ai faite sur un vieux Excel qui tournait dans une VM.
    J'ai mal cherché ou cette partie n'est pas encore très claire ? Par où commencer ?
    Sinon, merci pour le superbe travail :)

  • # Intégration Java

    Posté par . Évalué à 1 (+1/-0).

    Personnellement j'espère qu'ils reprendront un jour le composant qui existait chez Open Office : un bean (ooobean.dll) capable de s'intégrer dans une application Swing (Java).
    Ce composant ne fonctionnait qu'en 32 bits et que sur Windows. Il a été abandonné depuis quelques années maintenant… Dommage

  • # icône sur le bureau

    Posté par . Évalué à 6 (+6/-2).

    ce n'est peut-être pas le lieu pour parler de ça, mais je trouve que si LibreOffice est un super projet dans la continuité d'OpenOffice, je trouve dommage qu'il se retrouve avec une icône (sur le bureau, pour les utilisateurs windows) franchement pas enthousiasmante :

    Titre de l'image

    Est-ce que ça donne envie de l'utiliser ?

    Ça manque carrément de couleur… le logo d'openoffice est carrément plus attractif.

    Les icônes pour writer, calc etc sont correctes, parce que plus colorées (d'ailleurs ça serait pas mal de traduire ça par "traitement de texte, tableur", plus parlant que des mots anglais).

    • [^] # Re: icône sur le bureau

      Posté par . Évalué à 6 (+5/-0).

      Il y a plusieurs jeux d’icônes.
      Celui que tu montres n’est pas l’icône par défaut. J’imagine que ça sort d’un des thèmes de LO.

      Les icônes officiels sont ceux-là:
      https://wiki.documentfoundation.org/Design/Whiteboards/LibreOffice_Initial_Icons#Present_State_of_the_Icon_Design

      Il est vrai que l’icône «neutre» est encore trop fade.

      Faut ouvrir un bug sur LO. Aucune chance que râler ici change quoi que ce soit. :)

      • [^] # Re: icône sur le bureau

        Posté par . Évalué à 2 (+0/-0).

        oui, ça ressemble quand même beaucoup. Sur le principe, il faudrait un logo général, pas que l'icône, avec une identité beaucoup plus forte, sans forcément en faire trop.

        Je vois qu'il y a déjà ça de signalé, même si c'est dans un cas particulier :
        https://bugs.documentfoundation.org/show_bug.cgi?id=96835

      • [^] # Re: icône sur le bureau

        Posté par . Évalué à 3 (+2/-0). Dernière modification le 22/11/16 à 17:21.

        Le jeu d'icône reste le même dans le gestionnaire de fichier de Windows ou MacOS, et ce, quelque soit le thème utilisé.
        Il faudrait, vraiment changer ces horribles icônes. En plus, il y a eu des propositions depuis belle lurette même si elles ne sont pas toutes à mon goût:
        https://wiki.documentfoundation.org/Design/Mimetype_Icons/Proposals

        • [^] # Re: icône sur le bureau

          Posté par . Évalué à 3 (+1/-0).

          oui, certains ne sont pas mal du tout. Mais pour le logo principal, il faut vraiment le colorer, ça lui donnera plus de consistance et il se verra mieux (cf. le problème soulevé dans le bugtracker, avec le logo qui se confond avec l'éditeur de texte sous mac os x). Il faudrait soit reprendre toutes les couleurs des différents modules (ou des principaux), mais ça risque de faire un peu indigeste, soit reprendre un jeu de couleur différent du reste, pour trancher.

    • [^] # Re: icône sur le bureau

      Posté par . Évalué à -3 (+4/-9).

      Euh… Quand j'utilise LO/Office/autre, c'est parce que j'en ai besoin.

      Pas parce que l'icône est joli.

      "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

      • [^] # Re: icône sur le bureau

        Posté par . Évalué à 7 (+5/-0).

        je l'attendais celle-ci.
        Moi je n'en ai rien à faire. Je démarre LO en tapant dans mon terminal "libr+tab". C'est juste pour proposer quelque chose de plus attractifs à des utilisateurs en entreprise qui chouinent parce qu'ils veulent du word excel (même s'il n'y ont pas touché depuis 10 ans), si on plus l'apparence de LO donne l'impression d'avoir un logiciel de seconde zone, ça ne facilite pas le travail.

        • [^] # Re: icône sur le bureau

          Posté par . Évalué à 8 (+7/-0).

          Pareil.
          Pour moi le design est secondaire, mais pour un utilisateur standard, ça pose souvent problème, ils disent que c'est moche et veulent pas l'utiliser. En plus de ça les thèmes par défaut dans le logiciels n'aident pas, trop sombres ou vieillots. Ce qui serait nickel ce serait d'avoir les icônes de Faenza pour les applications et le thème Galaxy par défaut.

          • [^] # Re: icône sur le bureau

            Posté par . Évalué à 10 (+10/-0).

            Pour le thème Galaxy, j’ai insisté pour qu’il soit le thème par défaut sur Windows. Mais pour eux, le thème Gnome est un thème «universel», même s’il ne colle pas à l’esthétique de Windows. On était plusieurs à le demander, mais ce fut peine perdue. Bref… c’est Gnome pour tout le monde.

            Les icônes d’applications actuelles me semblent bien, sauf celle dont parle justement zurvan.

            Pour ma part, je suis assez sensible à l’esthétique d’un logiciel, même si ce n’est pas forcément l’aspect principal que je recherche. Ça témoigne à mes yeux d’un certain souci de la qualité de ce qu’on produit.

          • [^] # Re: icône sur le bureau

            Posté par . Évalué à 1 (+1/-1).

            Tu trouves le thème par défaut vieillot et tu proposes Galaxy par défaut ? C'est intéressant sur la perception de ce qui est vieillot parce que Galaxy est le thème historique de OpenOffice.org depuis une quinzaine d'années. Donc s'il y a un vieux jeu d'icônes dans LibreOffice, c'est bien celui-ci. :-)

            Plusieurs thèmes d'icônes son disponibles et on peut choisir ici : menu Outils > Options > LibreOffice > Affichage.
            Je vous suggère d'essayer les thèmes Breeze et Sifr.

            • [^] # Re: icône sur le bureau

              Posté par . Évalué à 3 (+2/-0).

              Oui. Mais Tango est à peine plus jeune et ne paraît pas spécialement moins vieillot. Du reste, on pourrait faire un thème aujourd’hui qui paraîtrait aussi vieillot. L’âge ne détermine pas la qualité d’un jeu d’icônes. Ce n’est pas le problème.

              • [^] # Re: icône sur le bureau

                Posté par . Évalué à 1 (+0/-1).

                Je déteste Tango. :(

                "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

    • [^] # Re: icône sur le bureau

      Posté par . Évalué à 7 (+6/-1).

      Les icônes pour writer, calc etc sont correctes, parce que plus colorées (d'ailleurs ça serait pas mal de traduire ça par "traitement de texte, tableur", plus parlant que des mots anglais).

      Dans mes souvenirs, ça n'a pas empêché des logiciels de la suite office d'une grosse boite de dominer le marché.

  • # Détail

    Posté par . Évalué à 5 (+5/-0).

    Toujours pas trouvé le moyen d'utiliser en français le point du pavé numérique. Je sais, c'est pas grammaticalement correct en français, mais…

    • [^] # Re: Détail

      Posté par . Évalué à 3 (+1/-0).

      options > paramètres linguistiques > langues > "touche séparateur de décimales" : décocher "identique au paramètre de la locale (,)"

      • [^] # Re: Détail

        Posté par . Évalué à 4 (+3/-0).

        Si on fait ça, les chiffres passent avec des points au lieu de virgule ce qu'on ne veux pas non plus.

        • [^] # Re: Détail

          Posté par . Évalué à 4 (+2/-0).

          j'ai supposé qu'il voulait cela le module writer. Il y a cela aussi, une fois la virgule du pavé numérique désactivée : https://framasoft.org/article1832.html
          C'est sous windows, mais s'il veut pouvoir avoir la virgule dans le pavé numérique pour calc et le point dans writer, ça devrait pouvoir le faire, si jamais LO a des noms différents pour les titres de fenêtre.
          Peut-être que l'on peut faire encore autrement, je ne sais pas.

          Sous linux/unix on peut utiliser ce genre de petit script pour passer rapidement d'un mode à l'autre :

          (avec xmodmap -pke | grep "keycode 91 = KP_Delete KP_Decimal" entouré par des ` ça ne passe pas à cause des limitations de markdown)

          #!/bin/bash
          val=xmodmap -pke | grep "keycode 91 = KP_Delete KP_Decimal"
          echo $val
          if [ -n "$val" ]
          then
          xmodmap -e 'keycode 91 = KP_Delete comma'
          else
          xmodmap -e 'keycode 91 = KP_Delete KP_Decimal'
          fi

    • [^] # Re: Détail

      Posté par . Évalué à 0 (+1/-1).

      Dans tes paramètres systèmes, donc pas dans LO, passe ton clavier en "français" et pas "français variante".

  • # Mise à jour

    Posté par . Évalué à 1 (+0/-0).

    Comme pour la famille Mozilla (principalement Firefox et Thunderbird), le jour où une mise à jour simplifiée sera proposée –autre que le téléchargement manuel du logiciel– LibreOffice récupèrera encore plus d'utilisateurs·trices : avec les faits évoqués des icônes un peu trop discrètes et / ou des noms à l'angliche, ce sera une souplesse d'utilisation pour pas mal de monde.

    En attendant cela, re-félicitons tout ce travail pour un ensemble d'outils vraiment efficaces !

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.