LibreOffice 4.4 a été publié le 29 janvier 2015. Cette nouvelle version est destinée aux utilisateurs expérimentés — les autres, comme les entreprises et les administrations, sont invités à rester sous LibreOffice 4.3.5.
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 qui a eu lieu sous le capot lors de ce cycle de développement menant à la version 4.4 de LibreOffice. Cette dépêche est une traduction de son article, initialement publié dans le domaine public ou licence CC0.
Sommaire
- Refonte complète de l’interface utilisateur
- Backend initial de rendu OpenGL
- Visualisateur Mobile / LibreOfficeKit
- Améliorations du build / de la plateforme
- Travail autour de la qualité du code
- Nettoyage de code
- Amélioration des performances
- Performance de Calc
- S’impliquer
- Conclusion
Aujourd’hui, nous publions LibreOffice 4.4.0, avec plein de nouvelles fonctionnalités pour tous les goûts. Lisez et admirez les nouveautés apportées aux utilisateurs. Tout cela est réalisé par beaucoup de programmeurs talentueux. Mais, il y a, comme toujours, nombre de contributeurs dont le travail réside dans les coulisses sur bien des points qui ne sont guère connus. Ce travail est, bien sûr, primordial pour la santé du projet. Il peut être difficile de savoir ce qui ce passe sur plus de 11000 commits faits depuis LibreOffice 4.3. Alors, en voici le détail.
Refonte complète de l’interface utilisateur
La migration des boîtes de dialogue VCL vers Glade est désormais pratiquement terminée (après avoir pensé que nous avions fini, Caolan découvrit beaucoup de fenêtres qui nécessitent la poursuite du travail, mais toutes ont été migrées, à part deux). Il y eut également beaucoup de travail pour les nettoyer et les peaufiner. Un grand merci à Caolán McNamara (Red Hat) pour son incroyable travail et son leadership et à Adolfo Jayme Barrientos, Palenik Mihály (GSoC 2014), Olivier Hallot (EDX), Szymon Kłos (GSoc 2014), Rachit Gupta (GSoC 2014), Tor Lillqvist (Collabora), Jan Holesovsky (Collabora), Maxim Monastirsky, Efe Gürkan YALAMAN, Yousuf Philips et beaucoup d'autres. Merci aussi à nos traducteurs qui devraient désormais moins souffrir des modifications intempestives des chaînes de caractères.
Je rajoute que resource-compiler a subi un beau régime.
Backend initial de rendu OpenGL
Le passage à OpenGL dans VCL pour le rendu est une de ces choses qui devraient, idéalement, se dérouler de manière invisible, mais qui, au final, a un impact important sur le rendu visuel. Tout le travail a été réalisé ici par des ingénieurs Collabora, avec un gros ré-usinage et la gestion initiale de OpenGLContext par Markus Mohrhard, une grande partie de l'implémentation du rendu avec anti-crénelage par Louis-Francis Ratté-Boulianne et le travail de redimensionnement d'image par Lubos Lunak, divers correctifs liés aux fenêtres et du travail de portage de Jan Holesovsky et un peu de Chris Sherlock. Pendant ce temps, nous avons aussi implémenté une application VCL, une démonstration à peu près décente et de plus en plus complète pour s’exercer à faire du rendu. Des explications de ce travail avec des images : https://people.gnome.org/~michael/blog/2014-11-10-opengl.html
En passant à un modèle de rendu en pur OpenGL, nous pouvons accélérer les opérations qui ont grandement besoin de tirer parti de la puissance et du parallélisme de tous les transistors consacrés à l'APU sur les GPU modernes. Être capable d'interagir beaucoup plus directement avec le matériel graphique sous-jacent nous aide à la fois à rendre nos aperçus d'image en haute qualité et de ne pas sacrifier les performances de défilement et de zoom : on a, à la fois, le beurre et l'argent du beurre. Nous avons également utilisé une partie de cette puissance pour accélérer non seulement notre rendu d'image considérablement, mais aussi pour améliorer sa qualité par rapport à avant…
… et maintenant (si votre navigateur redimensionne les images, ça perd tout son sens : remettez le zoom à 1:1 et regardez le haut de la rosace, et d'autres parties en hautes fréquences) :
Il y a encore du travail pour que OpenGL soit dans un état acceptable, notamment à cause de quelques bugs bizarres du cycle de vie des fenêtres ; il faut paramétrer une variable d'environnement via un export SAL_FORCEGL=1 pour passer outre la liste noire, mais nous espérons résoudre ceci pendant le cycle de la 4.4.x. Certaines fonctionnalités sont encore en attente et devraient arriver pour la version 4.5. Par exemple un véritable gestionnaire de boucle d'attente par Jennifer Liebel et Tobias Madl ainsi qu'un travail en cours sur le canvas OpenGL (Michael Jaumann) et sur les transitions OpenGL (Stefan Weiberg). Ces travaux sont encadrés par Thorsten Behrens (SUSE).
Visualisateur Mobile / LibreOfficeKit
Le récemment annoncé Android Viewer (Beta) inclut un certain nombre d'éléments invisibles, en particulier l'amélioration de LibreOfficeKit : une façon simple de réutiliser les bienfaits du rendu et du format de fichier de LibreOffice, conçus par Andrzej Hunt et Kohei Yoshida (Collabora) pour créer le rendu par tuiles pour Impress et Calc au moins en version bêta (NdT: le rendu par tuiles consiste à segmenter l’affichage plutôt que de tout faire d’un coup). Vous pouvez en lire plus à propos du travail débuté sur le mode édition pour TDF. LibreOfficeKit est également devenu plus puissant dans l'extraction des méta-données des documents de la base, toujours plus vaste, de formats de fichier que LibreOffice gère, ce qui est important pour l’indexation des données non structurées.
Améliorations du build / de la plateforme
Compilations sous Windows 30% plus rapides
Avec le nouveau système de compilation terminé, nous avons examiné son principal problème : le temps de compilation plutôt élevé sous Windows. Un examen et quelques benchmarks ont révélé que l'usage de Cygwin était la cause principale de lenteur et Michael Stahl (Red Hat) a fait en sorte de pouvoir construire LibO 4.4 avec une version native Win32 de GNU make, réduisant le temps total de compilation de près d'un tiers par rapport à un Cygwin de base et accélérant encore plus les re-compilations incrémentales.
Port vers Win64
Une autre amélioration majeure vient de David Ostrovsky (CIB), qui a réalisé un travail important pour terminer le portage Win64. Nous espérons une disponibilité pour la version 4.5 et cela devrait aider significativement, notamment, les utilisateurs Java et ceux ayant de très grosses feuilles de calcul. Jetez un œil à la page wiki Windows 64 bits pour plus de détails. Merci également à Mark Williams pour les travaux délicats de correction sur UNO et à Tor Lillqvist (Collabora) qui a posé les fondations de ce travail.
Travail autour de la qualité du code
Il y a eu beaucoup de travail sur la qualité, l'amélioration de la maintenabilité et la propreté du code. Merci aux quelques 59 commits de corrections d'erreurs cppcheck de Thomas Arnhold, Julien Nabet et Simon Dannner, parmi les commits quotidiens pour compiler sans aucun avertissement -Werror -Wall -Wextra sur beaucoup de plateformes avec des remerciements à Tor Lillqvist (Collabora), Caolán McNamara (Red Hat) et Thomas Arnhold.
Impressionnant Coverity
Nous avons parcouru l’énorme quantité de données analysée avec le "Coverity Scan". En particulier, Caolán McNamara (Red Hat) a réalisé un superbe boulot. Son blog à ce sujet est, comme à l’accoutumée, modeste.
Nous avons désormais une densité de défauts qui approche 0, bien que Coverity introduise de nouvelles vérifications et que le nouveau code commité fasse varier ce chiffre. Nous sommes actuellement à 0,02 c'est à dire, 2 avertissements de vérification statique pour 100 000 lignes. C'est extrêmement bien comparé à la moyenne des projets open source qui se situe à environ 65.
Les commits mentionnant Coverity sont au nombre de 1530 depuis LibreOffice 4.3 avec dans le top 3 des contributeurs après Caolán (1378 commits) : Norbert Thiebaud, David Tardon (Red Hat), Miklos Vajna (Collabora).
Augmentation de l'utilisation d'« asserts »
Dans la version 3.5, nous sommes passés d'un système maison de macros à des appels normaux d'« assert » pour assainir les vérifications d'invariants. Leur nombre augmente au fur et à mesure :
Tests de l'import et maintenant de l'export
Les tests de crash d'importation / exportation de Markus Mohrhard (Collabora) ont été élargis pour couvrir plus de 76 000 documents problématiques contre 55 000 à la dernière version, avec désormais une sélection d'images irrégulières (?) aussi incluse. Une autre grande victoire était la mise à disposition par TDF (merci à nos donateurs) d'une nouvelle machine 64 cœurs pour exécuter le chargement/l'enregistrement/la validation des tests ci-dessus. Ceci, combiné avec quelques retouches et un meilleur parallélisme des scripts Python qui dirige cela, a accéléré l’exécution de tests, réduisant le temps de cinq jours à moins de un, permettant une détection rapide de nouvelles régressions de façon beaucoup plus précise. Nous avons également été en mesure de lancer AddressSanitizer sur une série de documents, ce qui a conduit à plusieurs corrections, merci à Caolán McNamara (Red Hat) pour l'excellent travail effectué.
Greffons / outils d'analyse pour Clang
Nous avons continué à compléter notre collection de greffons Clang : un rapide "git grep" sur Registration dans le dossier "compilerplugins" montre que nous sommes passés de 27 à 38 greffons dans les six derniers mois. Ceux-ci vérifient de tout un tas de façons pleins de trucs piégeux dans notre code dans lesquels les gens peuvent tomber. Certains de ces greffons sont utilisés manuellement, mais beaucoup sont lancés automatiquement sur le Tinderbox et par certains utilisateurs pour trouver les erreurs rapidement. Merci à : Stephan Bergmann (Red Hat) et Noel Grandin (Peralex) pour le dur travail fourni sur ces outils d'analyse.
Les greffons font plein de choses, par exemple, Bjoern Michaelsen (Canonical) en a écrit un qui détecte les imbrications profondes de clauses conditionnelles comme ces monstres. Ils sont difficiles à lire et une plaie à débugguer. Certains des pires cas dans sw/ (NdT: Writer) ont été réécrits et le greffon peut facilement être utilisé ailleurs dans les sources.
Tests unitaires
Nous construisons et exécutons aussi plus de tests unitaires pour éviter les régressions lorsque nous changeons le code. Une recherche grep sur les macros TEST et ASSERT montre que le nombre de tests continue d'augmenter.
L'idéal est d'ajouter un test unitaire à chaque bug corrigé pour l'empêcher de revenir à jamais. Avec environ 1000 commits pour plus de 70 auteurs sur les tests unitaires dans la 4.4, il est difficile de lister toutes les personnes impliquées dans ce travail, mes excuses pour cela. Voici une liste triée des auteurs de plus de dix commits dans les répertoires qa/ : Miklos Vajna (Collabora), Caolán McNamara (Red Hat), Kohei Yoshida (Collabora), Michael Stahl (Red Hat), Stephan Bergmann (Red Hat), Zolnai Tamás (Collabora), David Tardon (Red Hat), Noel Grandin (Peralex), Matúš Kukan (Collabora), Luboš Luňák (Collabora), Markus Mohrhard (Collabora), Tor Lillqvist (Collabora), Thomas Arnhold, Andrzej Hunt (Collabora), Eike Rathke (Red Hat), Jan Holesovsky (Collabora).
Assurance Qualité / Bugzilla
Sur les six derniers mois, l'équipe QA [NDR : pour "quality assurance", assurance qualité] a grandi en taille et en efficacité. Réalisant un travail fantastique pour réduire le nombre de bugs non triés de mille (ce que nous pensions déjà bien) vers à peine plus de trois cents. Le tri de certains de ces bugs étant particulièrement difficiles car assez techniques ou très difficiles à reproduire, c'est un excellent travail. C'est assez difficile d'extraire la liste de ceux qui confirment les bogues, mais la liste des héros se chevauche avec la liste non-développeurs/top clôtureurs donnée ci-dessous.
L'une des métriques que nous regardons dans l'appel ESC est l'appartenance au top dix dans la liste récapitulative hebdomadaire freedesktop. Voici une liste des personnes qui sont apparues plus de cinq fois dans cette liste de ceux qui ont clôturé le plus de bogues (dans l'ordre de fréquence de d'apparence) : Caolán McNamara (Red Hat), Adolfo Jayme, tommy27, Julien Nabet, Jean-Baptiste Faure, Jay Philips, Urmas, Maxim Monastirsky, Beluga, raal, Michael Stahl (Red Hat), Joel Madero, ign_christian, Cor Nouws, V Stuart Foote, Eike Rathke (Red Hat), Robinson Tryon (TDF), Miklos Vajna (Collabora), Matthew Francis, foss, Sophie (TDF), Samuel Mehrbrodt, Markus Mohrhard (Collabora). Et merci à tous les autres d'avoir aidé à fermer autant de bogues pour cette version.
Bjoern Michaelsen (Canonical) a également écrit une « Assurance Qualité du nouvel an » qui vaut le coup d’être lue.
Un autre succès qui devrait nous aider à rendre notre bugzilla plus convivial et mieux structuré est la migration de l'infrastructure FreeDesktop vers TDF, en remerciant FreeDesktop pour avoir pris en charge notre gros bugzilla pendant toutes ces années. Le travail a été récemment terminé, donc désormais les bugs sont à déposer à http://bugs.documentfoundation.org/. Merci à Robinson 'colonelqubit' Tryon (TDF), Tollef Fog Heen et notre équipe d'administrateurs système pour ce travail. Même si cela est peut-être évident, Robinson travaille pour TDF (financé par nos généreux donateurs) à mi-temps pour aider à améliorer la situation côté QA.
Nettoyage de code
Le code sale doit être nettoyé - donc nous avons beaucoup nettoyé.
Nettoyage des commentaires en allemand
Nous avons continué a progresser, mais malheureusement peu, dans la traduction des commentaires allemands persistant dans le code en bon anglais technique précis. C'est un bon moyen de s'investir dans le développement de LibreOffice. Mille mercis à : Philipp Weissenbacher, Christian M. Heller, Jennifer Liebel (Munich), Chris Sherlock (Collabora), Michael Jaumann (Munich), Luc Castermans, Jeroen Nijhof, Florian Reisinger et de nombreux autres avec un seul changement à leur actif. De plus, la diminution des faux positifs signalés par bin/find-german-comments suggère qu'il ne reste que dix modules de premier niveau contenant de l'allemand, parmi eux, neuf méritant des efforts de traduction : i18npool, include, reportdesign, sc, scaddins, sfx2, stoc, svx, sw.
Une des contributions particulièrement encourageante à notre effort de traduction des commentaires allemand a été celle de Lennart Poettering qui semble avoir quelque chose de drôle en préparation.
Mise à jour vers (un peu de) sous-ensemble de C++11
Avec le temps, C++ s'améliore, et avec la mise à jour de Visual Studio, nous avons pu passer à un sous ensemble de C++11 (celui offert par VS2012) en tant que base. Nous avons aussi retiré plusieurs contournements (empêchant des optimisations) de bug présents sur des vieilles versions de GCC (qui de toute façon ne prennent pas en charge C++11), et donc GCC et MSVC peuvent tous les deux désormais compiler l'ensemble de LO avec toutes les optimisations. Merci à Stephan Bergmann (Red Hat) pour la recherche et la gestion de ce travail.
Nettoyage du tokenizer OOXML
Ce nettoyage s'appuie sur le travail de Miklos Vajna (Collabora) dans la dernière version. Un gros morceau de notre tokenizer OOXML était du code généré, ce qui est raisonnable, mais il a été généré en utilisant XSLT (qui a tendance à être en-dessous de cobol). Les 4200 lignes de XLST ont été réécrites en 1300 lignes de Python - pour produire le même résultat avec une forte augmentation de la hackabilité. Puis certaines optimisations ont été réalisées par Jan Holesovsky (Collabora pour CloudOn), pour réduire des parties inefficaces de la sortie générée par writerfilter DSO, faisant ainsi 2,2Mo d'économie sur 8Mo (dépouillé). C'est génial de voir ce genre de nettoyage de code, la taille du code et du binaire se réduisant en même temps. Vous pouvez en lire plus à ce sujet sur le blog de Miklos.
std:: containers
Un ensemble systématique d'améliorations à notre utilisation des conteneurs std:: est en cours dans le code. Des choses comme éviter l'héritage de std::vector, changer std::deque en std::vector et commencer à utiliser les nouvelles constructions C++ pour l'itération comme for (auto& it : aTheContainer) { ... }. Il y a beaucoup de gens à féliciter ici, merci à Stephan Bergmann (Red Hat), Takeshi Abe, Tor Lillqvist (Collabora), Caolan McNamara (Red Hat), Michaël Lefèvre, et bien d'autres.
Amélioration des performances
Les performances font partie de ces éléments assez difficiles à voir, néanmoins on les ressent viscéralement de cette manière : « pourquoi est-ce que je dois encore attendre ? ». Il y a un nombre encourageant d’améliorations de performances faites par différentes personnes dans LibreOffice 4.4 qui valent la peine d'être notées.
Performance de l'auto-correction
Pour des raisons qui me dépassent, certaines personnes aiment avoir d'énormes listes d'auto-correction. Elles sont stockées au format XML zippé. Daniel Sikeler (Munich) a amélioré de façon sympathique le chargement de celles-ci. Il a découvert en particulier que nous réanalysions notre BlockList.xml un grand nombre de fois, et résoudre ce bug a fait une grosse différence. Si on combine cela avec le passage à FastParser qui a été threadé et amélioré, on gagne encore plus. La liste d'auto-correction est chargée après la première touche appuyée, donc descendre de 4,3 secondes à 1,5 secondes (pour des listes énormes de correction) est une belle victoire.
Gestion des images
Tout en profilant la sauvegarde de différents types de fichiers, il a été découvert que nous échangeons fréquemment (i.e. rechargeons et re-décompressons) les images. Cela prend bien évidemment beaucoup de temps CPU, en particulier puisqu'ensuite on continue tout de suite à préserver les données (originales) dans le fichier. Dans certains cas cela prenait une grosse portion du temps de sauvegarde pour des présentations ayant beaucoup d'images. Merci à Tamaz Zolnai (Collabora) pour le nettoyage et la résolution de ce problème, et ainsi que la chasse à ces soucis récurrents de perte d'image.
Fast Serializer
En règle générale, toute classe nommée « Fast » dans le code hérité d'OpenOffice est atrocement mal nommée. Un grand merci à Matus Kukan (Collabora) pour avoir résolu cela. Nous avons découvert que 25% du temps d'enregistrement d'un fichier XLSX composé de grandes feuilles était consommé dans le « FastSerializer », qui, à notre grande stupeur, lance 9.900.000 appels système, chacun écrivant à chaque fois de minuscules fragments d'un attribut XML. Il sépare par exemple les écritures pour les ouvertures des balises, les noms d'éléments, les noms d'attributs, les espaces de noms, etc. Matus a réduit cela à 76.000 appels pour produire le même résultat, soit une baisse de 99%. Abstraction faite de la surcharge d'appels systèmes, nous avons réduit le nombre de cycles CPU cachegrind pour « SaveXML » de plus de douze milliards à moins de trois milliards pour un cas simple.
Empaquetage de libjpeg-turbo
On sait depuis plusieurs années que JPEG-turbo fournit des performances de décompression supérieures - « In the most general terms, libjpeg-turbo is 2.1 - 5.3x as fast as libjpeg v6b and 2.0 - 5.8x as fast as libjpeg v8d ». Naturellement les éditeurs Linux utilisent la ligpjpeg packagée dans leur système, mais quand on distribue pour Windows… Nous fournissons maintenant une accélération x2 sous la forme de libjpeg-turbo. Merci à Matúš Kukan (Collabora) avec quelques nettoyages de Stephan Bergmann (Red Hat). Des volontaires pour intégrer proprement jpeg-turbo sur Mac seraient fortement appréciés.
Performance du publipostage
Le publipostage fonctionne en construisant un énorme document contenant le résultat de tous les courriers à imprimer / fusionner vers un ficher unique. La pertinence est très discutable, mais merci cependant à Lubos Lunak & Miklos Vajna (tous deux Collabora pour Munich) qui ont fait un effort significatif pour accélérer substantiellement les fusions de gros documents, selon les cas de plusieurs ordres de grandeur. Malheureusement OpenOffice.org avait subi une grosse régression à ce propos dans la version 3.3, et ceci est globalement corrigé. On passe de plusieurs heures à quelques minutes pour 2000 enregistrements.
Performance de Calc
Il y a eu un certain nombre de gains de performance sympathiques dans cette version de LibreOffice, qui, une fois cumulés ont un effet assez bénéfique.
Améliorations des dépendances de plages (Range dependency re-work)
Pour les précédentes versions de LibreOffice Kohei Yoshida (Collabora) a passé beaucoup de temps à unifier l'exécution de formules similaires dans FormulaGroups - qui s'étendent tout le long d'une colonne - puisque c'est un cas courant des grands ensembles de données. Cela a permis une réduction importante de l'utilisation mémoire et beaucoup de partage de données. Cependant, la gestion de dépendance était découplée de cette opération et était encore effectuée cellule par cellule.
C'est particulièrement coûteux si vous envisagez une référence de plage qui est commune à tout le groupe de formules : cela aboutit à beaucoup de travail pour pas grand chose, essentiellement pour notifier tout le groupe de formules. Calc 4.4 ajoute un type de Listener qui est adapté pour ces groupes de formules - pouvant potentiellement transformer des dizaines de milliers d'entrées de structure de données complexes en une seule entrée. Cela permet d'économiser des gros bouts de mémoire et beaucoup de temps CPU sur les parcours des listes, il permet aussi d'économiser énormément de temps lors de la diffusion des changements. Il y a encore beaucoup de travail à réaliser pour développer toutes les possibilités de ce changement et, idéalement à l'avenir, nous devrions utiliser la même approche pour les références de cellule. Merci aussi à Eike Rathke (Red Hat) et Markus Mohrhard (Collabora) pour certains correctifs associés.
Détection du type d'écriture d'une cellule
Pour plusieurs raisons, la détection du type d'écriture d'une cellule est une opération coûteuse; est-ce un texte asiatique, un texte simple ou complexe (qui a un effet sur la police, sa taille et différentes métriques). Kohei Yoshida (Collabora) a trouvé que lors de différentes opérations courantes (ex: copier/coller de gros blocs de données) cette détection était répétée inutilement. De même, pour des types de donnée simple avec formatage standard (ex: de grands blocs de nombres à virgules), il était possible de simplifier significativement la détection du type d'écriture.
Différer la régénération des diagrammes
Un autre domaine qui cause (encore) quelques douleurs est qu'à chaque fois qu'une plage de données dont dépend un diagramme change, le diagramme entier est généré à nouveau. Cela implique de détruire de nombreuses formes graphiques et de les recréer, ce qui dans le cas d'un texte coûte particulièrement cher. Kohei Yoshida (Collabora) a implémenté une belle optimisation pour différer ce travail jusqu'à ce que le diagramme soit visible. Cela devrait avoir un effet agréable sur le temps d'édition d'un grand ensemble de données converti en diagrammes dans beaucoup d'autres feuilles comme sur l'exploitation de macros dans beaucoup de diagrammes.
S’impliquer
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 orange au milieu.])
Et en ce qui concerne la diversité des correctifs, nous adorons voir le volume des contributions apportées par les indépendants, même si clairement ce volume et les équilibres changent selon les saisons, les cycles de publication, le temps libre / de travail des volontaires.
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. Il 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’en installer une et vous êtes prêt pour contribuer avec l’équipe de développement.
Conclusion
LibreOffice 4.4 est la prochaine d’une série de versions qui vont améliorer progressivement non seulement les fonctionnalités, mais aussi les fondations de la suite bureautique libre. Ce n’est bien sûr pas encore parfait, c’est juste la première d'une longue série de versions 4.4.x mensuelles, qui apporteront chacune leur lot de correctifs et d’améliorations qualitatives dans les mois à venir, tandis que nous commençons à travailler sur LibreOffice 4.5.
J’espère que LibreOffice 4.4.0 vous plaira. Merci de m’avoir lu, et merci de soutenir LibreOffice. N’oubliez pas de consulter la page des nouveautés visibles.
Les données brutes de la plupart des graphiques ci‐dessus sont disponibles.
Aller plus loin
- Article original (297 clics)
- Notes de version (387 clics)
- Dépêche sur la version précédente (4.3) (314 clics)
- Téléchargement (339 clics)
# Vous êtes formidables
Posté par antistress (site web personnel) . Évalué à 10.
Les gars qui traduisaient ici les billets de Michael Meeks, ainsi que Michael Meeks, vous êtes incroyables. Merci :)
[^] # Re: Vous êtes formidables
Posté par Renault (site web personnel) . Évalué à 10.
Ce qui est encore plus formidable c'est le travail abattu depuis le début de LibreOffice.
Je veux dire, les évolutions ne sont pas toujours très visibles (bien qu'en performances il y a eu un net progrès par exemple), mais on voit qu'ils se donnent les moyens pour faciliter les travaux futurs par le nettoyage et la mise en place de procédures adéquats et attirer ainsi de nouveaux contributeurs.
Pour un projet de cette taille, stopper l'inertie débutée aux débuts de Sun c'est difficile et ils y arrivent peu à peu et c'est admirable. LibreOffice se donne clairement les moyens de régler ses défauts. On ne peut pas dire autant à priori de OpenOffice.org par exemple…
En tout cas c'est sympa que le projet communique sur les changements importants d'arrière plan.
[^] # Re: Vous êtes formidables
Posté par Thomas Debesse (site web personnel) . Évalué à 6.
stopper l’inertie, ou ébranler l’inertie ? :-)
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Vous êtes formidables
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 0.
Qu'est ce qui vous fait croire qu'ils mentent ?
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Vous êtes formidables
Posté par rogo . Évalué à 2.
Incroyable, dans le Littré
Donc au XVIIe siècle, Racine utilisait déjà incroyable au sens d'extraordinaire.
[^] # Re: Vous êtes formidables
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 5.
Incroyable…
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Vous êtes formidables
Posté par reynum (site web personnel) . Évalué à 3. Dernière modification le 12 février 2015 à 16:55.
Toi par contre tu es croyable :-D
kentoc'h mervel eget bezan saotred
# Qt
Posté par collinm (site web personnel) . Évalué à 3.
il y a certe amélioration de leur système graphique, est-ce que quelqu'un sait si l'usage de Qt est envisagé?
même si ça demanderait un travail immense
www.solutions-norenda.com
[^] # Re: Qt
Posté par coid . Évalué à 7. Dernière modification le 11 février 2015 à 14:41.
Pour l’instant, rien de tel n’est envisagé. En ce moment, ça semble plutôt parti pour améliorer le toolkit interne (VCL) que pour en changer. Beaucoup de patchs sur ça en ce moment. J’ai l’impression qu’il est surtout prévu d’utiliser OpenGL pour accélérer le rendu, mais je ne sais pas ce que ça implique.
Pour Qt, ça me semble peu probable que ça arrive, certains des dévs de LO bossaient autrefois sur Gnome et GTK+. Cela dit, je ne perçois aucun mouvement pour migrer vers GTK+ non plus.
[^] # Re: Qt
Posté par Atem18 (site web personnel) . Évalué à 10.
https://wiki.documentfoundation.org/Development/Crazy_Ideas#Replace_all_interface_code_with_an_interface_using_the_Qt_widgets
En gros, cela dit que dans le futur (c'est à dire maintenant), les boites de dialogues de LibreOffice seront converties au format .ui de GTK3/Glade. L'ancien format étant un truc obscur et le nouveau, un truc basé sur de l'XML, il est techniquement plus facile de passer à Qt, si le besoin se fait un jour ressentir. Maintenant, à savoir s'il est prévu de remplacer le reste par du GTK, du Qt ou rester sur VCL, personne ne le sait encore.
[^] # Re: Qt
Posté par arnaudus . Évalué à 3.
Je ne suis pas familier du tout avec des histoires de toolkit graphiques, mais il n'y a aucun moyen de programmer génériquement, et de choisir le toolkit à la compilation? La plupart du temps, il s'agit d'afficher des boites toutes con avec des menus tous cons, je ne vois pas ce qui justifie d'avoir du code GTK ou QT spécifique dans LibreOffice, en tout cas pas pour la plupart des boites graphiques.
[^] # Re: Qt
Posté par freeze . Évalué à 4.
malheureusement non … grosso modo, il y a moyen de faire le boulot de la même façon, mais en utilisant des technos différentes…
Qt utilise des fichiers XML .ui, ou du QML maintenant
GTK Builder part d'autres fichiers XML .ui .. mais différents
Et puis, à l'ancienne on peut coder l'ui à la main, mais je ne pas que ça soit vraiment répandu
[^] # Re: Qt
Posté par whity . Évalué à 10.
Le problème, ce n’est pas que les .ui. C’est beaucoup plus profond que ça.
Bref, pouvoir faire une couche qui permette de choisir, à la compilation, quelle bibliothèque utiliser, c’est un boulot titanesque, pour un résultat qui serait sous-optimal. J’ai dans mon souvenir une tentative de projet faite en ce sens il y a une dizaine d’années environ, mais impossible d’en retrouver trace --> je pense que c’est mort avant d’avoir fonctionné correctement pour autre chose qu’un hello world.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Qt
Posté par freem . Évalué à 7.
Le seul toolkit que je connaisse qui s'approche, de loin, de l'idée d'abstraire les autres framework est WxWidgets. Il est possible de faire se reposer wx sur l'API win32, sur Xorg, sur Gtk (le défaut sous linux) et il me semble qu'il y à eu à un moment des efforts pour du support Qt.
Ça marche plutôt bien, c'est portable, ça supporte les fonctionnalités classiques (système évènementiel dynamique, conteneurs, toute la flopée de contrôles habituels, persistance pour la config). Il y à bien de petites choses qui pourraient être améliorées, mais bon, rien de bien méchant.
Pour en revenir à la question de "pourquoi on peut pas choisir à la compilation"… si on prend le cas de Qt, il commence par modifier la chaîne de compilation: c'est du C++ «amélioré». Dans le cas de GTK, on à du C brut. Et si on devait prendre le cas de wx, c'est du C++ brut.
Du coup on à des bibliothèques qui sont basées sur des technologies de niveau différent. J'ai «entendu dire» que gtk faisait de l'objet. Dans un langage qui n'est pas fait pour. Ce genre de choses risquerai d'amener pas mal de problèmes en cas de passage à du C++ réel. Même si ces langages ont un fort taux de compatibilité, c'est très glissant.
Je ne parlerai pas du fait que les toolkit graphiques sont anciens. Du coup ils ont souvent implémenté leurs propres versions des même conteneurs (bien qu'il me semble que dans le cas de Qt un travail ait été fait pour se baser sur le standard. Dans le cas de Wx, j'en suis sûr). Du coup, risque d'incompatibilité entre ces conteneurs.
Pire, en C, il n'y à aucun conteneur en standard, donc GTK réinvente la roue concernant la gestion des chaînes de caractères.
Et ce ne sont que quelques problèmes que je peux voir alors que ça fait bien longtemps que je n'ai pas touché un toolkit graphique.
[^] # Re: Qt
Posté par xcomcmdr . Évalué à 2.
Qt 5 le fait en mieux, plus joli, plus à jour, et bien plus intégré.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Qt
Posté par freem . Évalué à 4. Dernière modification le 12 février 2015 à 12:23.
Qt n'abstrait pas les autres, il les émules. Ou alors ça à bien changé.
[^] # Re: Qt
Posté par Zenitram (site web personnel) . Évalué à 6.
Qt 5 ne le fait pas. Il a des "styles" pour s'approcher du style natif, mais dès que tu creuse un peu tu vois que ce n'est pas de l'abstraction de natif.
Qt c'est cool quand tu veux faire un GUI qui ressemble un peu au natif, mais si tu veux toucher les utilisateurs qui sont pointilleux, tu te retrouve vite mort --> Recoder en natif.
Surtout sous Mac, ils sont pointilleux…
[^] # Re: Qt
Posté par whity . Évalué à 3.
Disons que Qt fait un mix des deux.
Par exemple, Qt utilise les boîtes de dialogue natives pour l’ouverture de fichiers. Mais à côté de ça, oui, Qt fournit ses propres boutons, listes, etc, qui « miment » le comportement des composants « natifs » (sachant que « composants natifs », sous windows, c’est un concept discutable, entre les winforms, les forms .net, le xaml, etc).
Je connais très mal le cas du mac, je sais que c’est pas tout à fait un citoyen de 1ère classe chez qt (dans le sens où la plupart des dev sont soit sous linux, soit sous windows). Tu pourrais citer des exemples de trucs qui rendent mal ?
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Qt
Posté par Zenitram (site web personnel) . Évalué à 5.
Sous Mac, 2 bugs que j'ai en cours :
- la boite native pour l'ouverture de fichier ne permet pas bien d'ajouter les filtres (c'est ignoré, alors que sous windows/Linux c'est OK).
- Qt 5.0 a carrément viré setUnifiedTitleAndToolBarOnMac(), pour le remettre dans Qt 5.4 de tête. Problème : toujours pas le comportement natif (=le drag n drop de la toolbar qui doit déplacer la fenêtre ne marche pas)
Sans compter que le look des buttons de toolbar est loin de ressembler au style Mac (par exemplesles bontones ne peuvent pas êtres "collés" et avec lesbords extérieurs arondis), et quelques autres remarques que j'ai eu.
Bref comme tu dis : c’est pas tout à fait un citoyen de 1ère classe chez qt.
Hic : les Mac, c'est important.
Je pense à repasser en natif pour Mac.
[^] # Re: Qt
Posté par freem . Évalué à 2.
Perso, sous win, je considère que le natif c'est l'API C, vu que c'est celle sur laquelle tout le reste se base :)
Pas que chez Qt: j'ai remarqué que la plupart des framework, voire des projets, galèrent à trouver des gens pour ne serait-ce que tester sous mac… ne parlons même pas de développeurs.
[^] # Re: Qt
Posté par flan (site web personnel) . Évalué à 6.
En tant qu'utilisateur de Mac, j'attends qu'une appli correctement intégrée utilise les possibilités de l'OS, qui vont bien au-delà d'un simple aspect graphique. En vrac, quelques exemples :
Et il y a sûrement plein d'autres trucs de ce genre. Après, tout peut être corrigé, évidemment, mais il faut le refaire à la main, et s'il faut tout refaire à la main, autant partir directement sur Cocoa.
[^] # Re: Qt
Posté par Thomas Debesse (site web personnel) . Évalué à 3.
En fait ce qui m’étonne avec une telle exigence, c’est que ce soit aux développeurs de payer pour avoir les moyens d’y répondre ! :p
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Qt
Posté par flan (site web personnel) . Évalué à -1.
Que doivent payer les développeurs ? À ma connaissance, développer des applis sur Mac OS X est totalement gratuit (en revanche, la publication — facultative — sur l'AppStore doit être payante).
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Qt
Posté par flan (site web personnel) . Évalué à 2.
Correction : pour développer avec Xcode et le framework Cocoa (qui n'existent que sur OS X), il faut OS X.
Si tu veux, tu peux très bien développer pour Mac sans avoir de Mac avec d'autres techno (je le fais sans souci avec du Python + Qt, par exemple).
C'est toujours moins pratique, au même titre que c'est moins pratique de développer pour Linux sans avoir de Linux, ou de développer pour Windows sans avoir de Windows. Mais ça reste possible.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3. Dernière modification le 17 février 2015 à 09:26.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Qt
Posté par Thomas Debesse (site web personnel) . Évalué à 5. Dernière modification le 17 février 2015 à 15:21.
Tout à fait, les exigences que listent flan< sont justement celles qu’une technologie comme Qt et d’autres technos transversales de ce type ne satisfont pas.
Quand un utilisateur exige d’un développeur qu’il prenne soin de tous ces points, cela revient à dire au développeur :
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Qt
Posté par Zenitram (site web personnel) . Évalué à 1.
Ben non, et c'est ce qu'il fait qu'il est de moins en moins choisi.
Ils n'ont pas su créer un éco-système viable.
A mon grand regret.
[^] # Re: Qt
Posté par freem . Évalué à 2.
Hum. Des exemples? Je m'en suis servi, je n'y ai pas trouvé de problèmes particulier. En y réfléchissant, si, je vois un souci: de mémoire, les mobiles ne sont pas supportés. À part ça?
[^] # Re: Qt
Posté par gnumdk (site web personnel) . Évalué à 2.
Ca fait des IHM moches qui rament? J'ai pas beaucoup vu de projet utilisant ce truc mais que ce soit VLC 0.x ou encore audacity, tu le vois direct au lancement que c'est une application wx…
[^] # Re: Qt
Posté par freem . Évalué à 1.
Code::blocks ne rame pas (en tout cas sûrement pas à cause de son IHM!). VLC utilise Qt depuis bien des années maintenant (de mémoire c'était déjà qt en version 0.86 et quelques).
Pour l'esthétique, je n'en sais rien: j'ai toujours désactivé sous windows les thèmes. Justement, je trouve l'interface playschool d'XP et aero des windows plus récents bien plus moche. Il faut dire que je préfère la sobriété.
Du coup, ton commentaire révèle que, non, vraiment, on ne voit pas la différence entre wx et Qt, puisque VLC n'utilise plus, depuis longtemps, wx.
Audacity maintenant… voyons voyons… zut impossible de trouver des screen sous un windows plus récent qu'XP ou sous KDE… mais sinon je ne trouve pas ça si moche que ça, et du peu que je connais de mac OS, ça à bien l'air d'être une appli mac là.
Par contre avec C::B, je peux trouver un screen unity pour comparer avec mac et windows aero ou sans thème.
De mémoire C::B avait quelques glitch encore, il y à 4-5 ans dans les nightly, mais vu qu'ils ont fait pas mal de modif au niveau des thèmes et des contrôles un peu bizarre, ce n'est pas si surprenant.
En fait, le but de wx, c'est qu'on ne puisse pas savoir que c'est wx. Ça utilise par défaut Gtk sous linux, et sous win et mac le truc natif, avec quelques exceptions quand une api native ne fournit pas quelque chose: dans ce cas c'est implémenté par wx.
[^] # Re: Qt
Posté par Frank-N-Furter . Évalué à 5.
Non, pas du tout.
Depending on the time of day, the French go either way.
[^] # Re: Qt
Posté par gnumdk (site web personnel) . Évalué à 6.
En gros, pour toi, si ça utilise le thème de près ou de loin (surtout de loin à priori) de l'OS cible, alors c'est intégré…
Pourtant, tous les exemples que tu donnes montre que wxwidgets est encore moins capable d'avoir un look natif que Qt… (et c'est déjà pas gagné avec Qt…)
[^] # Re: Qt
Posté par freem . Évalué à 1.
Je vais faire une réponse pour les 3, et comme c'est toi qui… argumente… le plus… et si, au lieu de dire juste «tu as tort», on m'expliquait enfin, en quoi wx ne s'intègre pas? Ce serait plus efficace pour me convaincre non?
[^] # Re: Qt
Posté par Zenitram (site web personnel) . Évalué à 1.
Simple : prend un app Mac et regarde.
En fait, tu montres que tu ne connais pas les Mac, et n'a pas trop envie de connaitre.
Si tu ne prends pas le temps de regarder ce qu'est une app Mac, je ne pense pas que tu souhaites être convaincu, donc quoiqu'on fasse, tu ne seras pas convaincu.
Ouvre un Mac, regarde le design, et compare.
Si tu n'as pas de Mac, bon ben regarde quelques exemples d'apps Mac.
Si tu ne vois pas la différence avec tes captures, on ne peut pas y faire grand chose.
Convaincu?
Je te retourne l'argument : si au lieu de dire "ça s'intégre, si si même si j'y connais rien", tu nous expliquait enfin en quoi wx s'intégre? Parce que bon, pour le moment tu dis que le ciel est jaune, on te répond "non, arrête ton délire merci", et c'est à nous de démontrer qu'il est bleu.
[^] # Re: Qt
Posté par freem . Évalué à 2.
Effectivement, je constate que les icônes standard utilisées ne sont pas les mêmes. Je suppose que pour voir le reste il me faudrait comparer en live deux applications, une faite avec wx et l'autre faite spécifiquement avec les outils mac.
[^] # Re: Qt
Posté par Zenitram (site web personnel) . Évalué à 2. Dernière modification le 13 février 2015 à 11:28.
C'est une plaisanterie?
Il n'y a pas que les icones qui ne sont pas les mêmes, quasi tous les widgets sont différents.
J'ai l'impression qu'en fait, tu ne t'interesses pas à l'intégration, et pour toi si ça compile c'est intégré. Ce n'est pas le cas, loin de la.
Mais si en fait tu es doué que que tu sais faire les mêmes widgets en wx, fait moi signe, ça m'interesse.
[^] # Re: Qt
Posté par dinomasque . Évalué à 4.
L'intégration c'est plein de petites choses subtiles.
C'est dur à faire parcequ'un utilisateur normal va juste ressentir qu'un truc cloche mais aura du mal à mettre le doigt dessus, ou en tout cas pas de manière exhaustive.
BeOS le faisait il y a 20 ans !
[^] # Re: Qt
Posté par Zenitram (site web personnel) . Évalué à 1. Dernière modification le 13 février 2015 à 10:40.
Pas compris : quoi à bien l'air d'être une appli mac là?
Parce que dans tous tes lien, rien ne s'approche d'une appli Mac.
Des exemples d'appli Wx ayant l'air d'être une appli mac, s'il te plait.
Le soucis vient peut-être de la
[^] # Re: Qt
Posté par NanoTech . Évalué à 3.
On pourrait rapprocher ça du problème d'AWT vs Swing.
AWT laisse le système faire la plus grande partie du boulot, alors que Swing refait tout à partir des bases.
Défauts d'AWT :
- Quelques incompatibilités entre plateformes qui obligent à bien tout tester partout
- On est réduit au dénominateur commun des plateformes
Avantages d'AWT :
- Meilleure intégration système (par exemple avec les outils d'accessibilité)
J'imagine que ce sont les mêmes arguments pour wxWidgets versus Qt/GTK.
[^] # Re: Qt
Posté par freem . Évalué à 1.
Pas versus Gtk+Linux, puisque c'est le défaut utilisé sous linux, mais sinon j'imagine que c'est ça oui.
[^] # Re: Qt
Posté par Albert_ . Évalué à 3.
Toi tu as jamais du changer de version de WxWidget. C'est un concept amusant on va dire. Generalement on se fait avoir une fois mais pas deux.
[^] # Re: Qt
Posté par freem . Évalué à 2.
Non en effet. Enfin, si, j'ai utilisé la 2.8, suis passé sur une 2.9 à un moment puis à la fin en 3.0. Rien de bien choquant, surtout pour qui lis les release notes.
Pour Qt 3 vers 4, c'était facile? On m'a dit que non…
[^] # Re: Qt
Posté par Albert_ . Évalué à 2.
Tant mieux pour toi, je n'ai pas eu (et mes collegues non plus) la meme experience.
De tout de facon WxWidget sous KDE c'est aussi moche qu'une application Gnome enfin si j'utilise pas Qt-GTK c'est a dire les technos Qt…
J'adore leur wiki:
"There has been a bunch of work done with the goal of a Qt-based port of wxWidgets (see the wxWidgets SVN wxQt branch), so wxWidgets applications aren't required to use GTK-Qt (which hasn't been known to work too well) to build applications that look and feel native for KDE users."
Voyons je choisis quoi? Un truc inexistant ou un truc qui fonctionne (et contrairement a ce qui est dit je n'ai que tres peu de probleme avec, le probleme que j'ai fait cracher eclipse mais bon c'est du a un bug de gtk2…)
[^] # Re: Qt
Posté par freem . Évalué à 1.
Ah ça, le vécu…
Merci cap'tain obvious. Vu que, comme je l'ai dit, wx se base par défaut sur gtk sous Linux… bref. Le sujet est parti du fait qu'il n'existe aucune API qui abstraie les autres, ce à quoi j'ai suggéré que wx semble pourtant répondre à ce critère.
À l'époque ou j'avais choisi ce framework, il me semble que le port Qt était pas vraiment fini. Ça à peut-être changé, je ne sais pas. Ça remonte.
[^] # Re: Qt
Posté par gnumdk (site web personnel) . Évalué à 5.
Moi je me souviens aussi de débats ici même ou le consensus était: "wxwidget a une API de merde"
[^] # Re: Qt
Posté par freem . Évalué à 1.
Je trouve cet argument très… convainquant. Ou pas.
[^] # Re: Qt
Posté par whity . Évalué à 4.
Sauf si je fais une confusion, wxWidget suit grosso modo l’api des MFCs.
Et c’est clairement pas un compliment, tant cette api est décriée (elle a des excuses, elle a été conçue à une époque où on avait beaucoup moins de recul là-dessus, mais ça reste une api pourrie).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Qt
Posté par BAud (site web personnel) . Évalué à 5.
je te trouve encore trop conciliant pour les MFC :/
# Nuances sur le nettoyage XSLT
Posté par benoar . Évalué à 10.
Alors, faisant actuellement de la génération de code à base de XSLT pour un projet, ce refactoring m'a intrigué : me serais-je trompé d'avoir utilisé un langage déclaratif alors que j'aime pourtant bien Python ? Je suis donc allé voir de plus près.
J'ai pris un exemple de complexité moyenne, mais regardons par exemple le code original en XSLT :
http://cgit.freedesktop.org/libreoffice/core/tree/writerfilter/source/ooxml/factoryimpl_ns.xsl?id=21977778168af134e7f72afcc07ff5062324a19d#n183
avec la version convertie en Python :
http://cgit.freedesktop.org/libreoffice/core/tree/writerfilter/source/ooxml/factoryimpl_ns.py?id=6c4de449094048465b81abf93139bb5950fa12c9#n128
Franchement, la différence de lisibilité et la soi-disant facilité de « hackage » ne sautent pas aux yeux. Certes il faut connaître XSLT pour mieux le « parser » visuellement, et passer outre sa verbosité, qui doit être son plus gros défaut, mais sinon je trouve la matching des balises avec DOM est vraiment horrible à lire. Tellement que ça doit amener des bugs : le getElementsByTagName() ligne 147 me semble faux, le XSLT ne va chercher que les enfants directs. De plus, tous les anciens cas ne sont pas gérés : rien pour un "refdefine" nul (c'est peut-être une hypothèse assumée, mais pas précisée). Et au passage on perd complètement la notion d'espace de nommage pour les tags ! La verbosité de l'API du DOM pour ça vis à vis de XPath ne doit pas y être pour rien…
En parlant d'API, Miklos les mélange d'ailleurs allègrement ; on passe à SAX pour un autre fichier (qui fait encore une fois des hypothèses plus stricte sur les entrées, les "fastoken" hors d'un "model" étant potentiellement traités, de manière erronée) :
http://cgit.freedesktop.org/libreoffice/core/commit/writerfilter/source/ooxml?id=dd5dfc8e2a0fc3c0307c0a782ae563b79ba8a84e
Ce qui fait qu'on peut potentiellement avoir des documents qui ne valident pas, vu que ce genre de parser ne permet plus d'assurer la bonne forme du document…
Ah mais en fait, la conversion précédente amène un bug, qui complique le code python encore plus, corrigeons-le :
http://cgit.freedesktop.org/libreoffice/core/commit/?id=63cd667ccb35325a973cf4f98c5e1bf9db92b9b4
Voilà les joies de la conversion. Là où la nouvelle de linuxfr se fourvoie par contre — même si ça vient certes du blog de l'auteur, et qu'on ne vérifie pas forcément la véracité de sources aussi proches — c'est que la réduction du code XSLT ne vient pas de la supposée concision de Python pour ce genre de travail, mais juste de simples suppressions de code ! Le code précédent a par exemple simplement été retiré :
http://cgit.freedesktop.org/libreoffice/core/commit/writerfilter/source/ooxml?id=2046fcd907fe8c0217c5cd43be8420859a0ad435
Et de même pour un paquet d'autres. Et la réduction du gros paquet de code généré vient principalement parce qu'on a implémenté moins de choses dans la version python que dans la version XSLT.
Bref, je peux très bien comprendre l'argument de la non-popularité de XSLT pour passer à un langage comme Python, mais d'un côté, ça s'apprend très vite (il y a deux semaines, je n'en avait jamais fait), et c'est un langage très adapté quand on tripote du XML, avec toutes les contraintes que ça amène, et toutes les facilités qu'offre un langage fait pour. En tous cas, les réductions en taille de code présentées n'ont rien à voir avec le fait que ça soit du XSLT. Je suppose que Miklos n'aimait pas, et en a profité pour cracher dessus, de manière fallacieuse.
Mangez du XSLT (mais seulement si vous faites du XML, hein, il ne faut pas être maso non plus), c'est bon.
[^] # Re: Nuances sur le nettoyage XSLT
Posté par xcomcmdr . Évalué à 7.
Dans le post originel, l'auteur comparait la popularité de XSLT à celle de COBOL, j'imagine que "hackabilité" est pour lui la possibilité d'avoir une base de code qui bouge facilement, et ça veut dire avoir des contributeurs qui connaissent le langage. Donc exit XSLT, bonjour Python…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Nuances sur le nettoyage XSLT
Posté par benoar . Évalué à 9.
Ça tombe bien, il se trouve que j'ai déjà fait du COBOL : peut-être que niveau employabilité, ça le fait mieux (et encore, vu les usines à gaz Java qui touchent du XML, ça ne m'étonnerait pas que le XSLT soit populaire en entreprise bien que peu visible dans le libre, tout comme le COBOL), mais niveau « facilité » du langage, ça n'a rien à voir. Le XSLT est bien plus accessible et moderne (un langage plutôt déclaratif, quand même !) et, comme je le disais, apprenable assez facilement. Alors on peut mettre en face le fait que peu de monde le connaisse à priori, mais y mettre du Python et tous les risques associés que j'ai cité, ça ne me semble pas une très bonne idée.
Le code supprimé aurait très bien pu l'être dans sa forme XSLT, ça serait revenu au même, tout en gardant un langage fait pour ce travail. J'adore le Python, vraiment, mais pour certaines utilisations, il n'est vraiment pas adapté.
Après, tout ça c'est pour importer du OOXML, alors je pourrais m'en foutre aussi, mais bon, le XSLT m'a un peu appris le masochisme /o\
[^] # Re: Nuances sur le nettoyage XSLT
Posté par G.bleu (site web personnel) . Évalué à 3.
Pour en avoir fait pas mal dans un précédent projet, le XLST (en plus de son illisibilité chronique dû à XML) prend vite en complexité dès qu'on utilise des fonctionnalités un peu avancé
- deux versions (v1 et v2) plus ou moins incompatibles et en concurrence
- peu de documentation sur internet et surtout divisé entre v1 et v2 ce qui induit souvent en erreur si la version n'est pas précisé
- la création de fonctions n'est pas intuitive du tout (le fait que ce soit du fonctionnel n'aidant bien sûr pas les gens qui n'y sont pas habitué, soit un bon paquet de programmeurs !)
Bref pour contribuer à du XLST il faut déjà bien le connaître sous peine de passer beaucoup de temps à faire des choses assez triviales, là où Python (qui n'est certes pas très à son avantage ici) est bien plus simple à modifier, même pour un néophyte
Personnellement je me demande pourquoi ils ne sont pas partit sur un moteur de template comme il existe pléthore dans le monde web (au hasard, léger et puissant : http://jinja.pocoo.org/docs/dev/)
[^] # Re: Nuances sur le nettoyage XSLT
Posté par benoar . Évalué à 2.
Je n'ai pas trop eu le problème, je me suis limité à XSLT v1, la v2 étant peu supportée par des outils libres. J'ai ressenti certains manques des fois, mais rien de trop important.
Moi je la trouve intuitive… Et du coup, c'est l'occasion de se mettre au fonctionnel !
Oui, mais on aborde le classique problème : doit-on utiliser des outils de merde (dans ce contexte) pour être accessible, ou doit-on demander à avoir un minimum d'initiation afin de pouvoir utiliser des choses plus adaptées, et sur le long terme, beaucoup plus efficaces ? Sur linuxfr, je pensais qu'on hésitait moins sur l'investissement dans des outils « complexes » si le jeu en vaut la chandelle…
Pour la génération de texte, effectivement, ça aiderait (c'est un handicap de XSLT aussi : il est plus à l'aise dans la génération de XML que de texte brut) ; j'aime beaucoup Jinja2. Par contre, pour le parsing de XML d'entrée, ça n'aidera en rien, et c'est surtout là-dessus que Python pêche, je trouve.
[^] # Re: Nuances sur le nettoyage XSLT
Posté par coid . Évalué à 9.
Pour LibreOffice, le choix a été fait. Tout a été fait pour attirer les contributeurs et faciliter l’entrée dans le code. Pour ça :
— simplification et épuration drastiques du code (on parle de millions de lignes de code, là),
— modernisation du code,
— abandon et remplacement des vieux outils,
— mise en place d’outils pour faciliter la traduction et simplification des procédures pour intégrer de nouveaux langages,
— réorganisation des dossiers des sources pour faire moins peur,
— traduction des commentaires en allemand,
— simplification et accélération de la compilation,
— mise en place d’un système de “easy hacks” pour aider les nouveaux à mettre le pied à l’étrier,
— Python est considéré comme un langage phare susceptible d’attirer du monde, (hormis Base, tout le code Java a été remplacé par du Python, et même le Java de Base finira par disparaître),
— transcription de l’UI codée en dur par du XML,
et j’en oublie sûrement, réduire la difficulté d’entrée a toujours fait partie de leur stratégie.
Malgré tout ça, LibreOffice reste encore un gros morceau pas facile à digérer.
Virer le code XSLT fait indubitablement partie de cette stratégie globale visant à attirer les contributeurs.
[^] # Re: Nuances sur le nettoyage XSLT
Posté par whity . Évalué à 10.
Bon, tu défends une techno que tu viens d’apprendre il y a deux semaines. Ce qui veut dire que pour l’instant, tu as découvert les avantages de la techno, mais que tu n’as pas encore suffisamment de recul pour t’être pris dans la tête les inconvénients.
Je pense que tes arguments vis à vis du cas de la migration xslt -> python sont pertinents, cela dit : s’il n’y a pas iso-fonctionnalité, la comparaison est intrinsèquement biaisée.
En revanche, xslt a quand même pas mal de défauts, qui font que la plupart des projets que je connaisse qui ont décidé de se baser dessus se disent qu’ils auraient peut-être mieux fait de faire une moulinette en pour faire les opérations (je suis dans ce cas, j’ai bossé sur un projet avec des feuilles de style xlst > 10k lignes, plus jamais ça).
Parmi les défauts les plus souvent remontés :
- le manque d’opérations triviales (formatage de dates par exemple)
- la très mauvaise lisibilité --> il est difficile, en lisant une grosse feuille de style xlst, de comprendre ce qu’elle fait, dans quel ordre sont faits les traitements, etc.
Ces deux points sont un gros point noir :
- le premier fait que tu dois « réécrire » un certain nombre de fonctionnalités de base, d’où surcoût.
- le deuxième point fait que chaque bug / évolution coûte beaucoup plus cher, parce qu’il faut le temps de « rentrer dedans ».
Et il faut ajouter à ça :
- la grosse galère à débugger (à fortiori quand il y a des inclusions multiples)
- les perfs désastreuses
Bref, personnellement, j’ai essayé, maintenant, j’évite autant que possible. À nombre de lignes égal, un programme est nettement plus lisible qu’une feuille xslt. Et xslt a tendance a être plus verbeux… :/
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Nuances sur le nettoyage XSLT
Posté par rogo . Évalué à 6. Dernière modification le 12 février 2015 à 09:22.
En XSLT1, rien n'est prévu pour gérer les dates. Mais ce n'est pas le cas en XSLT2. Ceci dit, c'est extrêmement pénible à utiliser. Par exemple, s'il faut convertir "02-23-2015" en "23 février 2015", il faut commencer par bricoler en découpant la chaîne par position avant d'appliquer les fonctions de date : plusieurs dizaines de lignes de code en tout, soit un facteur 10 par rapport à un langage généraliste.
À mes yeux, le principal défaut de XSLT est que c'est un carcan plutôt étroit. Pour un besoin simple, tout va bien. Quand on commence à manipuler le texte des attributs, on commence à suer. Mais le jour où l'on décide de normaliser certaines valeurs XML en croisant avec une base de données, alors la feuille XSL devient un boulet. On peut paraît-il y greffer des modules pour lancer des requêtes SQL en cours de transformation, mais ça semble aussi productif que de remplacer systemd par emacs.
[^] # Re: Nuances sur le nettoyage XSLT
Posté par benoar . Évalué à 2.
Oui enfin dans ce cas, la bonne solution est d'en faire une bonne bibliothèque, comme pour les autres langages… mais c'est vrai qu'à ce niveau (ressources externes en extensions XSLT), le langage est malheureusement peu pourvu.
C'est vrai que dans ce genre de cas, je comprends que XSLT ne soit plus adapté.
Par contre, n'existe-t-il pas un « mode de traitement » des données arborescentes à la XSLT dans d'autres langage ? Je le trouve tellement efficace que je me vois mal m'en passer maintenant dans les autres langages…
[^] # Re: Nuances sur le nettoyage XSLT
Posté par benoar . Évalué à 2.
Tiens, je viens de penser qu'on pourrait utiliser des décorateurs avec des expressions XPath pour faire comme du XSLT… marrant comme idée.
[^] # Re: Nuances sur le nettoyage XSLT
Posté par benoar . Évalué à 4.
Si tu parles du fait que le code Python fait moins de choses dans le cas qui nous concerne, et est donc naturellement plus court, c'est le point principal que je voulais montrer, effectivement.
Ouch, ça fait mal, oui.
Bon, ça c'est vrai que ça semble un petit peu limité, et que je n'ai pas rencontré ce besoin encore, mais que ça serait handicapant.
Mmmhh… dans les exemples que j'ai vu, je ne vois pas en quoi un code procédural serait plus lisible.
Ça c'est clair que ça doit être rédhibitoire quand tu en as besoin.
Encore une fois, je ne vois pas trop la différence. À moins que ça soit pour quelqu'un qui connaît mal XSLT, mais la critique peut alors valoir pour n'importe quel langage.
J'ai effectivement un petit peu vécu ça,
xsltprocque j'utilise pourrait être plus explicite sur certaines erreurs (comme quand tu appelles une template qui n'existe pas quand tu t'es trompé dans le nom).J'avoue ne pas avoir eu de problème avec ça, vu que mes fichiers sont de taille raisonnable.
Oui, la verbosité n'aide vraiment pas. Mais ce qui me plaît vraiment et qu'on ne retrouve pas ailleurs, c'est la logique de parsing du langage : c'est hyper-bien adapté à du parcours d'arbre, et le matching est super pratique pour spécialiser certains cas. Ce genre de chose serait horrible à faire avec un autre langage. Tout ça se rapproche du fonctionnel, qui n'est pas facile à comprendre quand on est pas habitué, mais une fois que tu l'as saisi, ça simplifie tellement de choses…
En fait, il faudrait juste une version moins verbeuse. J'ai pensé à du YAML pour décrire les XSLT, je ne sais pas si ça pourrait le faire.
Merci pour ces remarques en tous cas, assez justes.
[^] # Re: Nuances sur le nettoyage XSLT
Posté par pepp . Évalué à 2.
Tu es sûr de ça ? LibreOffice a quand même pas mal de tests autour de l'import des doc/docx et ça m'étonnerait que Miklos ait accepté une solution qui introduise des régressions.
[^] # Re: Nuances sur le nettoyage XSLT
Posté par benoar . Évalué à 2.
Le code qu'il a enlevé n'a à priori pas introduit de régression, c'est seulement du code qui a été jugé « inutile » parce que les fonctionnalités n'étaient (apparemment) que peu utilisées dans les documents créées par MS Office, ou alors pas implémentées par MS, d'après ce que j'ai compris.
[^] # Re: Nuances sur le nettoyage XSLT
Posté par whity . Évalué à 1.
En fait le problème que j’avais eu à l’époque avec Xslt, c’est que le découpage fonctionnel est beaucoup moins évident à voir et à faire que dans un langage impératif. Or, le découpage fonctionnel, c’est un des critères principaux de lisibilité.
L’autre gros soucis, c’est qu’il est facile d’avoir des effets de bord globaux sans le faire exprès --> ça, c’est terrible pour la maintenance. À chaque modification de la feuille, tu pries (et en plus, on n’avait pas TUs corrects derrière).
Après, tout ça est assez vieux en ce qui me concerne (> 6 ans), et des choses ont pu évoluer depuis.
On retrouve le même genre de choses chez prolog, erlang (je crois), ou dans une certaine mesure les templates c++. C’est très pratique pour certaines choses, très puissant, mais quand on en abuse, c’est facile d’arriver à des choses totalement illisibles.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Nuances sur le nettoyage XSLT
Posté par benoar . Évalué à 3.
C'est le but des templates nommées. Après, c'est vrai qu'en XSLT on privilégie un maximum les templates « matchées », dont le découpage est alors imposé par la structure du document, c'est vrai.
Mmhh… je n'ai pas vraiment eu le cas, mais je crois imaginer le danger que tu évoques. Ça me paraît quand même d'une probabilité assez faible à moins d'avoir des documents à traiter ayant une structure vraiment casse-gueule. Mais j'avoue ne pas avoir assez de pratique pour savoir si c'est courant ou pas.
En tous cas, c'est clair qu'avec du XSLT, tu lies pas mal la structure du « code » avec celle du document que tu as à traiter. Ça fait partie de ses forces, dans le sens où sa méthode de parsing devient « claire » quand tu imagines bien la structure du document, mais aussi de ses faiblesses dans le sens où il est difficile de faire quelque-chose d'arbitrairement différent, je pense.
Whoua, des langages tout aussi populaires que XSLT ! Si c'est ça les alternatives… je vais peut-être rester sur XSLT :-)
Plus sérieusement par contre, ce que j'évoque c'est le pattern matching + récursion « automatique » façon arbre. Je ne les vois pas trop dans ceux que tu cites (le prolog pour la récursion en arbre, si, mais les autres… bon, je les connais moins aussi).
Oui enfin XSLT ayant un périmètre d'utilité assez déterminé, je trouve qu'il est plus simple et moins « abusable » que ces langages à tout faire. Je le vois comme une sorte de “Domain Specific Language” pour le traitement d'arbres.
[^] # Re: Nuances sur le nettoyage XSLT
Posté par Antoine . Évalué à 2.
C'est vrai que le Python tel qu'écrit n'est pas franchement joli. Déjà ce n'est pas PEP 8, mais surtout ça utilise l'API minidom qui est lourde et peu maintenue. Je me demande pourquoi ils ne se basent pas sur ElementTree (ou lxml.etree, qui propose la même philosophie d'API avec des fonctionnalités en plus).
(par contre, de là à dire que XSLT est lisible…)
[^] # Re: Nuances sur le nettoyage XSLT
Posté par djano . Évalué à 3.
Un facteur qui puisse expliquer ce choix: est ce que l'on peut debugguer du XSLT?
C'est une vraie question car je ne sais pas comment faire.
[^] # Re: Nuances sur le nettoyage XSLT
Posté par benoar . Évalué à 1.
Pas super facilement en effet. Je comprends que ça joue un peu contre lui. Perso, je le fais avec les messages la plupart du temps assez clair de l'interpréteur (xsltproc) et des <xsl:message> placés aux endroits stratégiques. Mais ça n'est clairement pas idéal.
[^] # Re: Nuances sur le nettoyage XSLT
Posté par djano . Évalué à 5.
Je suis vacciné du debugging à base de print/echo depuis l'université :)
# Impress
Posté par pamputt . Évalué à 9. Dernière modification le 11 février 2015 à 21:24.
Quand je lis ça
j'ai énormément d'espoir de voir Impress enfin utilisable. Car vu le nombre de fois où j'ai rencontré ce problème de disparitions d'images, j'ai peur à chaque ouverture d'une présentation. Donc vraiment hâte de tester ce LO 4.4 pour voir si ce problème a vraiment disparu.
# "Refonte complète de l'interface utilisateur"
Posté par François Nautré . Évalué à -5.
N'exagérons rien…
[^] # Re: "Refonte complète de l'interface utilisateur"
Posté par coid . Évalué à 5.
Le titre du billet précise bien qu’on parle de ce qui est sous le capot. Et de ce point de vue, si, l’UI a bien été refondue complètement.
# Orthographe
Posté par rpnpif . Évalué à 8.
Écrire plutôt :
OpenOffice.org avait subi une grosse régression…
Écrire plutôt :
9 000 000 appels-systèmes.
Idem pour tous les points décimaux à la place de virgules, points qui traînent dans les nombres comme 0.02.
[^] # Re: Orthographe
Posté par reynum (site web personnel) . Évalué à 4.
Une autre au passage :
GCC et MSVC peuvent tou t les deux
kentoc'h mervel eget bezan saotred
[^] # Re: Orthographe
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci.
# Un peu comme les dépêches noyau
Posté par antistress (site web personnel) . Évalué à 6.
Un peu comme les dépêches noyau, ça serait bien d'avoir un tag ad hoc ou une page de recensement pour retrouver rapidement les dépêches précédentes (http://linuxfr.org/news/libreoffice-4-3-est-sorti, http://linuxfr.org/news/libreoffice-4-2-0-est-disponible, http://linuxfr.org/news/sous-le-capot-de-la-beta-libreoffice-4-1)
# bravo
Posté par Selso (site web personnel) . Évalué à 4.
Ça fait plaisir de voir qu'il y a un vrai travail de fond sur ce logiciel libre pour le rendre plus facile d'utilisation mais aussi pour sa mise en œuvre, plutôt qu'un "bricolage" du design pour le faire ressembler aux alternatives payantes. Je suis sûr que ça paiera à terme.
J'imagine à peine tous les efforts fournit, rien avec le temps que m'a pris la lecture de ce billet.
Et en plus, ils nous mâchent le travail pour les rejoindre…
Merci pour la traduction au passage.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.