LibreOffice 5.0 : sous le capot

121
25
août
2015
Bureautique

La suite bureautique multiplateforme LibreOffice 5.0 a été publiée le 5 août 2015. Cette nouvelle version non finalisée est destinée aux utilisateurs expérimentés — les autres, tel que les entreprises et les administrations sont invités à rester sous LibreOffice version 4.4.5.

Logo LibreOffice

Nous vous proposons la traduction d'un billet du blog d'un meneur dans le développement de LibreOffice. Il s'agit de Michael Meeks vice-président de l'éditeur Collabora spécialisé dans l'intégration de la suite LibreOffice.

Ce billet décrit l'ensemble des actions réalisées en profondeur durant tout le cycle de développement menant à cette version 5.0 de LibreOffice.

Son billet est publié sous licence CC0, et également dans le domaine public.

Sommaire

Le 5 août 2015, nous avons publié LibreOffice 5.0.0, une nouvelle base pour le travail des prochains mois et années. Elle inclut beaucoup de nouvelles fonctionnalités que les utilisateurs apprécieront. Vous pouvez prendre connaissance de toutes ces nouveautés visibles par les utilisateurs codées par tant d'excellents développeurs, mais il y a, comme toujours, de nombreux contributeurs dont le travail se situe principalement sous le capot, et beaucoup de travail qui est plus technique que ce qui est visible par l'utilisateur. Ce travail a, bien sûr, une importance vitale pour le projet. Il peut être difficile d'extraire tout ceci des quelque onze mille contributions ajoutées depuis la version 4.4 de LibreOffice, donc je vais essayer de développer :

VCL - Améliorations de la boîte à outils VCL

L’un des plus grands travaux dans LibreOffice 5.0 concerne VCL, la boîte à outils graphiques que LibreOffice utilise pour le rendu et tous ses objets graphiques. La version 5.0 modernise et améliore différents aspects de celle-ci, et les met au niveau des autres boîtes à outils graphiques multi-plateformes.

Boucle principale / gestion du temps d'attente

C'est un changement radical majeur qui est arrivé dans la 5.0, et qui est un fondement essentiel pour les futures tentatives de rendre VCL et LibreOffice plus efficaces et performants, grâce à Jennifer Liebel et Tobias Madl (entretien). Le souci essentiel avec la précédente approche était que le choix de la prochaine tâche à effectuer dans LibreOffice (doit-on compter plus de mots, ou bien traiter du travail de redimensionnement de fenêtre différé, ou alors redessiner le contenu d'une fenêtre ?) était déterminé par un ensemble assez arbitraire de valeurs de délais d'attentes maximaux, par exemple : 30 ms pour redessiner, 50 ms redimensionner. Cela posait non seulement des problèmes de concurrence, mais était aussi terriblement inefficace. Il n'y avait aucune base solide pour ces valeurs choisies un peu au hasard.

Heureusement dans LibreOffice 5.0 nous avons un nouveau concept de « boucle d'attente » qui priorise les tâches que nous voulons terminer, permettant de les exécuter dans l'ordre, à la vitesse maximale. Ceci, combiné avec le travail de Jan Holesovsky (Collabora), destiné à permettre l'enchaînement des délais d'attente inférieurs à 10 ms sous Windows, signifie que nous avons enfin une boucle principale utile.

Cela nous a aussi aidés à trouver quelques mauvais comportements fortement consommateurs d'énergie qui auparavant étaient moins visibles. Ces tâches, généralement courtes, pouvaient s’exécuter selon une fréquence de l'ordre de 30 ms. Elles réveillaient trop discrètement et inutilement le processeur pour un faible bénéfice. Désormais, ce type de tâches provoque un pic d'activité processeur à 100 %, ce qui facilite sa détection et son traitement. Merci à Ashod Nakashian de s'être attaqué à plusieurs de ces problèmes.

Réfection du cycle de vie (VclPtr)

Pendant une grande partie de son existence, le cycle de vie d'un widget VCL (NdT: la boîte à outils graphiques Visual Components Library) est resté un poil mystérieux, même pour VCL. Les widgets pouvaient être alloués sur le tas, sur la pile, ou être membres d'autres widgets. S'ils étaient alloués sur le tas, ils pouvaient être enveloppés dans différents types de pointeurs partagés (shared pointers). Ainsi, prédire quand un widget pouvait être détruit et/ou suivre son cycle de vie dans le code était loin d'être évident. Dans VCL, nous utilisions des identifiants : des écouteurs spécifiques qui passaient à null quand un objet était détruit pour essayer d'éviter de référencer un objet impliqué dans plusieurs fonctions de rappel (callbacks). Malheureusement, ce système était plutôt incomplet, et beaucoup de code se résignait à retarder la suppression d'un widget alloué sur le tas jusqu'au retour à la boucle d'attente, dans le but d'éviter des problèmes.

Pour essayer de résoudre tout ce bazar, nous avons maintenant un seul type de pointeur intelligent : le type VclPtr qui compte les références à toutes les sous-classes de Window (et OutputDevice), et elles sont dorénavant toutes allouées sur le tas. Ceci donne un mécanisme de cycle de vie cohérent, et qui est même documenté. Nous sommes passés à un mécanisme de type 'dispose' pour casser les références cycliques, remplaçant le précédent mécanisme explicite ou implicite de type 'delete', nous avons aussi rendu beaucoup de méthodes sûres à appeler même sur les widgets libérés. Ceci devrait finalement fournir un cycle de vie prédictible et des chemins de destruction de code beaucoup moins fragiles, facilitant le ré-usinage de code. Pendant ce temps nous continuons à aplanir les problèmes, grâce à l'aide inestimable de Noel Grandin (Peralex), et de Caolan McNamara (RedHat) et Julien Nabet entre autres pour résoudre les conséquences de ces changements. Il faut espérer que (finalement) à peu près tous les types VCL à longue durée de vie utiliseront un mécanisme de cycle de vie similaire. Ce travail a été rendu possible grâce à l'énorme réusinage de Caolan pour utiliser VclBuilder pour tous les dialogues.

Un mode de rendu moderne : RenderContext

Une tentative audacieuse pour passer les fondements du code d’un rendu immédiat à un rendu différé a été lancée. Jusqu’à présent, LibreOffice générait le rendu de ce que l’on voit sur l’écran de deux façons : soit immédiatement, c’est-à-dire lorsque vous appuyez sur un « A », il essaie aussitôt d'afficher les pixels pour « A » à l'écran ; soit par un rendu très différé (délai : 30 ms et plus) sans priorité d’exécution (les callbacks).

Cette situation n’est vraiment pas idéale pour les API et le matériel modernes - où nous voulons nous assurer que l’image est totalement et parfaitement peinte dans son ensemble avant de la montrer à l'écran. Heureusement avec les nouveaux travaux sur la gestion des tâches, il n’y a plus de délai codé en dur avant que le rendu différé puisse avoir lieu. Nous avons donc commencé à supprimer le mode de rendu immédiat et à le remplacer par le rendu différé. Cela signifie remplacer les appels de rendu explicites avec invalidation de zone pour les placer dans une file d’attente destinée à un rendu différé. Dans de nombreux cas, cela peut enlever le scintillement visible et les artefacts de rendu intermédiaires lors du rafraîchissement de l’interface graphique.
Mille mercis à Tomaž Vajngerl (Collabora), Miklos Vajna (Collabora), avec l’aide et les corrections de Krisztian Pinter, Noel Grandin (Peralex), Jan Holesovsky (Collabora), Caolán McNamara (RedHat) et Laszlo Nemeth (Collabora).

Le backend Gtk3 : Wayland

Le port initial grossier de gtk3 a été codé il y a longtemps par votre serviteur pour prototyper LibreOffice en ligne via gdk-broadway. Cependant, merci à Caolan McNamara (RedHat) d'avoir fait 80 % du travail pour terminer cela, nous donnant un backend VCL poli et complet pour gtk3. Son entrée de blog se concentre sur l'importance de cette opération pour mener LibreOffice nativement sous Wayland - le précédent backend GTK2 était fortement lié au rendu X11 natif, tandis que le nouveau backend gtk3 utilise le rendu CPU via le backend headless (sans affichage) VCL, voir plus ci-dessous.

Améliorations du rendu OpenGL

Avec un grand nombre de bogues corrigés et d'améliorations, le rendu OpenGL a bien mûri dans cette version, nous permettant d'utiliser le matériel directement pour améliorer nos rendus. Merci à Louis-Francis Ratté-Boulianne (Collabora), Markus Mohrhard, Luboš Luňák (Collabora), Tomaž Vajngerl (Collabora), Jan Holesovsky (Collabora), Tor Lillqvist (Collabora), Chris Sherlock et les autres. Avec toutes les réparations de bogues en cours dans cette partie, nous espérons que le rendu OpenGL pourra être activé par défaut, comme fonctionnalité de dernière minute, après les tests adéquats, dans LibreOffice 5.0.1 ou, plus tard, dans 5.0.2.

Améliorations de LibreOfficeKit

LibreOfficeKit procure une méthode simple pour réutiliser le rendu et le formatage des fichiers de LibreOffice, mais à présent aussi le noyau de l’éditeur. Dans les six derniers mois, son utilité est passée de la conversion des fichiers principalement, à constituer aujourd’hui les fondations de LibreOffice sur Android, et c’est la base de la version en-ligne.

Amélioration du rendu sans affichage

LibreOfficeKit réutilise notre moteur de rendu sans affichage, ce qui nous permet de rendre les documents sans utiliser l'assistance du système d'exploitation, c'est-à-dire sans X11, Windows, OS/X, etc. Un certain nombre d'améliorations de performances et des corrections sur le rendu ont été implémentés au titre du travail sur le moteur gtk3 et l'utilisation en ligne (le rendu sans affichage est également utilisé sur Android jusqu'à ce que notre moteur de rendu GL puisse arriver à maturité sur cette plateforme). Merci à Caolán McNamara (RedHat) et Michael Meeks (Collabora).

Extensions de l'édition Android

L'édition Android est construite au-dessus des fonctions d'édition de LibreOfficeKit, et offre à l'utilisateur l'équivalent Android de la liste des fonctionnalités de gtktiledviewer, comme le curseur natif, la sélection de texte et graphique, le redimensionnement et plus encore. Merci à The Document Foundation et à leurs généreux donateurs. Ces importantes extensions d'API et le travail sur le cœur ont été réalisés grâce à Miklos Vajna, Tor Lillqvist, Andrzej Hunt, Siqi Liu, Mihai Varga, Tomaž Vajngerl et Jan Holesovsky tous de Collabora, ainsi que grâce aux travaux de Pranav Kant (GSOC), et aux nettoyages de Stephan Bergmann (RedHat).

Des bouts de LibreOffice en ligne

LibreOfficeKit (accompagné d'un dépliant adapté) est à la base du nouveau travail ciblant LibreOffice sur le Cloud. Regardez le code et une présentation. D'énormes quantités d'allègements et de simplifications ont été réalisés ici grâce à : Tor Lillqvist, Mihai Varga, Jan Holesovsky, Henry Castro et Miklos Vajna, tous de Collabora. Avec nos remerciements à IceWarp pour le financement de ces travaux.

Améliorations des performances de conversion

LibreOfficeKit offre une belle API, simple et propre pour charger et sauvegarder (convertir) des documents. Grâce à Laszlo Nemeth (Collabora) et Mihai Varga (Collabora), nous avons maintenant un nouvel attribut de filtre, SkipImages, qui permet une accélération significative pour le cas de conversion de n'importe quel fichier en HTML. C'est vraiment utile pour la réutilisation de la vaste gamme de filtres de LibreOffice pour faire de l'indexation de documents texte, en étant beaucoup plus rapide pour les documents gros et complexes. Un autre gain vital a été d'éviter de compter les mots avec précision (pour les statistiques du document) avant l'export. La conversion de document en texte avec cette option devrait être significativement plus rapide pour certains documents.

Amélioration de la compilation et de la gestion des plateformes

Réduction du temps de compilation

Avec l’augmentation de l’utilisation des templates dans les entêtes, la compilation a peu à peu pris de plus en plus de temps. Mais Michael Stahl (RedHat) a créé un script bin/includebloat pour localiser les entêtes les plus larges et les plus problématiques à supprimer. À titre d’exemple, supprimer boost/utility.hpp de plusieurs endroits nous épargne ~830 Mo de prétraitement de boost/preprocessor/SEQ/fold_left.hpp.

Port vers Win64

La version 5.0 arrive avec des compilations 64 bits pour Windows. Un grand merci à David Ostrovsky (CIB), ainsi qu’à Thorsten Behrens (CIB), Norbert Thiebaud, Stephan Bergmann (RedHat) et d’autres pour avoir aidé à corriger les bugs et nettoyé dans toute l’application un bon nombre de problèmes ardus spécifiques à la plateforme. Nous avons de nombreuses versions 64 bits pour différentes plateformes depuis des années, mais le modèle LLP64 de Windows peut créer des problèmes.

Travail sur la qualité du code

Le travail se poursuit autour de la qualité du code dans de nombreux domaines, avec environ 120 corrections cppcheck. Merci à Caolán McNamara (RedHat), Michael Weghorn, Julien Nabet, Noel Grandin (Peralex) et aux autres. Pareillement, il y a les commits quotidiens pour compiler sans aucun avertissement du compilateur -Werror -Wall -Wextra, etc. sur de nombreuses plateformes. Merci principalement à Tor Lillqvist (Collabora) et à Caolán McNamara (RedHat). Cette catégorie de problèmes diminue néanmoins grâce à l’utilisation croissante d'intégration continue.

Coverity presque à zéro

L’exécution du vérificateur de code source Coverity donne un résultat proche de zéro à présent. Chaque semaine, Caolán McNamara (RedHat) (avec l’aide de quelques autres) a accompli un travail formidable en conservant le compte à zéro (ou presque) avec environ 360 commits pour ce cycle. De nouveaux rapports de bogues apparaissent automatiquement à chaque build et nous en corrigeons quelques autres. Actuellement, le total des rapports est de deux (sur plus de 6 millions de lignes analysées). Heureusement, conserver ce nombre à zéro est un but raisonnablement accessible :
Graph of coverity static checking issues

PVS-Studio

La compagnie OOO « Program Verification Systems » développe l’outil d’analyse statique PVS-Studio et a publié les résultats d’une analyse unique rendue disponible pour les développeurs de LibreOffice. Des douzaines de problèmes rapportés ont été corrigés par Caolán McNamara (RedHat), Michael Stahl (RedHat), David Tardon (RedHat) et Markus Mohrhard. Vous pouvez en apprendre plus sur ce point ici (illustrations incluses).

Tests de l’importation et de l’exportation

Grâce au nouveau matériel de crash-tests payé par les donateurs et aux efforts significatifs de Caolán McNamara (RedHat), Michael Stahl (RedHat), Markus Mohrhard et plusieurs autres, nous avons réduit à pratiquement zéro un nombre d’assertions (paranoïaques) et de crashs d’importation sur notre imposant corpus de documents de tests (plus de 75 000 documents douteux et bogués). C’est merveilleux de pouvoir saisir au vol les commits qui provoquent des régressions et les corriger en quelques jours seulement sur master, avant qu’ils aient une chance d’atteindre les utilisateurs.
Graph of import crash-testing results
Graph of export crash-testing results

Le travail en cours est de compiler les binaires des crash-tests avec Adress Sanitizer et aussi de commencer à tester différents types de documents et d'étendre l'ensemble des types de fichiers en entrée.

Greffons Clang / vérificateurs

Nous avons continué à ajouter des greffons à notre compilateur clang ; un rapide git grep avec le motif « Registration » dans les greffons du compilateur montre que nous sommes passés de 38 à 59 au cours des six derniers mois (croissance doublée depuis la dernière version). Ceux-ci sont utilisés pour vérifier toutes sortes de vilains pièges, et aussi pour ré-écrire automatiquement différents bouts de codes problématiques. Beaucoup sont exploités automatiquement par tinderboxes pour attraper des erreurs. Merci à : Stephan Bergmann (Red Hat) et Noel Grandin (Peralex) pour leur travail acharné sur ces vérificateurs lors de ce cycle.

Les nouvelles extensions font toutes sortes de choses, et viennent généralement avec un ensemble de correctifs pertinents pour le code sous-jacent ; Voici quelques exemples :

  • loplugin:loopvartoosmall - vérifie que la variable d'index de boucle est d'au moins la taille de ce qu'elle indexe. Dans le cas de valeurs non signées, cela peut protéger de boucles infinies. Dans les autres cas, cela évite simplement de tronquer les données.
  • loplugin:staticmethods - cherche les méthodes qui peuvent être déclarées static. C'est à la fois plus efficace et rend le code plus compréhensible, puisque cela indique clairement que la méthode ne dépend de l'état d'aucun objet.
  • loplugin:vclwidget - met en application différentes règles sur l'usage de notre nouveau pointeur intelligent à compteur de référence VclPtr pour les objets VCL. Les classes à compteur de référence peuvent être délicates à utiliser dans les cas limites, donc avoir un vérificateur qui valide à la compilation autant de règles autrement implicites est vraiment très utile.
  • loplugin:constantfunction - cherche les fonctions qui devraient être supprimées ou avoir le mot clé inline, puisqu'elles retournent toujours la même valeur. C'est utile pour trouver du vieux code devenu redondant du fait du ré-usinage.
  • simplifybool - il détecte et démêle des expressions booléennes particulièrement alambiquées pour les simplifier. Par exemple en convertissant a ? false : true en !a.
  • cstylecast et redundantcast - ceux-ci détectent et préviennent les casts en style langage C, par exemple class Foo; Foo *pFoo = (Foo *)pBaa;, donc quand le type est incomplet. On devrait utiliser le beaucoup plus sûr static_cast. Ils détectent et suppriment également les casts inutiles pour que le code soit plus facile à comprendre.
  • de-virtualization - il détecte les méthodes virtuelles qui ne sont jamais surchargées pour les remplacer par des méthodes non virtuelles qui sont plus rapides.
  • lopluign:deletedspecial - trouve les déclarations de membres de fonctions spéciales qui restent indéfinies, et qui en réalité, devraient être marquées comme supprimées pour apporter des optimisations de compilation et des warnings.

D'autres séries de nettoyages ont également été assistées par Clang telles que l'action de Noel sur le nettoyage, rendant nos énumérations cohérentes et améliorant leur portée. Le lecteur de Stephan pour détecter et supprimer la conversion de bool implicite, le passage de nombreuses méthodes inline de sal_Bool (vraiment en unsigned char) à un véritable bool chaque fois que possible, et plusieurs autres extensions utiles.

Tests unitaires

Nous avons également construit et exécuté plus de tests unitaires avec LibreOffice 5.0 pour éviter les régressions lorsque nous modifions le code. Une recherche (grep) sur les macros TEST et ASSERT nous indique une augmentation du nombre de tests unitaires :

Graph of number of unit tests and assertions

Notre idéal est que chaque bogue qui est corrigé ait un test unitaire pour éviter qu'il revienne. Avec près de 800 changements, et plus de soixante-dix auteurs pour les tests unitaires de la version 5.0, il est difficile d'énumérer ici toutes les personnes impliquées, nous nous en excusons ; ce qui suit est une liste triée de ceux qui ont 10 fois plus de changements par répertoires concernés de Q&A : Miklos Vajna (Collabora), Markus Mohrhard, Caolan McNamara (RedHat) Stephan Bergmann (RedHat), Noel Grandin (Peralex), Michael Meeks (Collabora), Michael Stahl (RedHat), Zolnai Tamás, Tor Lillqvist (Collabora), Bjoern Michaelsen (Canonical), Eike Rathke (RedHat), Takeshi Abe, Andras Timar (Collabora), PriyankaGaikwad (Synerzip).

Tests de Windows

Alors que nous avions un sous-ensemble de tests unitaires que l'on lançait au moment de la compilation sous Windows, notre batterie de tests plus large était entravée par des problèmes étranges de comportement de tâches, liés à la gestion de plusieurs fenêtres et d'événements. Grâce à divers verrous et messages inter-tâches de Michael Stahl (RedHat) et de Stephan Bergmann (Redhat), nous avons maintenant des tests unitaires beaucoup plus robustes et fiables sous Windows.

QA / bugzilla

Une mesure que nous regardons lors des réunions du ESC (Engineering Steering Committee) est de savoir qui est dans le top dix du résumé hebdomadaire de bogues de freedesktop. Voici une liste des personnes qui ont figuré plus de cinq fois dans la liste hebdomadaire des meilleurs résolveurs de bogues par ordre de fréquence d'apparition : Adolfo Jayme, Beluga, Caolán McNamara (RedHat), raal, Julien Nabet, Jean-Baptiste Faure, Markus Mohrhard, m.a.riosv, Gordo, V Stuart Foote, Eike Rathke (RedHat), Andras Timar (Collabora), Alex Thurgood, Yousuf (Jay) Philips, Miklos Vajna (Collabora), Joel Madero, Cor Nouws, Michael Stahl (RedHat), Michael Meeks (Collabora), Matthew Francis, David Tardon (Redhat), tommy27, Timur, Robinson Tryon (qubit) (TDF). Et merci aux nombreux autres qui ont aidé à trier et fermer de si nombreux bogues pour cette version.

Jenkins / CI

Grâce à Norbert Thiebaud nous avons maintenant une excellente intégration continue via Jenkins/gerrit, ce qui permet de tester la compilation de tous les correctifs qui arrivent sur les trois plateformes principales. Utiliser l'intégration continue pour tester les correctifs avant de les envoyer sur le dépôt principal est devenu un autre outil sans pareil pour augmenter la qualité dudit dépôt (et ainsi son accessibilité aux utilisateurs occasionnels), tout en testant le code pour Windows et Mac sans qu'ils n'aient besoin de vérifier leur code sur ces plateformes par eux-mêmes. Grâce à ByteMark et à nos donateurs, nous espérons obtenir plus de matériel plus rapide pour notre ferme d'intégration continue afin de rendre celle-ci encore plus attractive. Avec plus de 25 000 compilations de 13 unités d'intégration depuis le début de l'année (ce qui se compare raisonnablement bien aux quelques 11 000 changements intégrés), nous espérons pouvoir lancer les compilations et les tests sur tous les changements soumis sans introduire de retard significatif.

Aussi pour le prochain cycle de développement, nous avons ajouté des tests outre ceux exécutés lors de la compilation. Nous activons un tas de propositions supplémentaires dans une version dbgutil, l'exécutons et faisons vérifier au moins sur Linux en appliquant un ensemble beaucoup plus vaste de tests supplémentaires à chaque apport individuel.

Bibisect étendu

Dans ce cycle, nous avons étendu les remarquables dépôts de Bi(nary)Bisect(ion) - qui contiennent des milliers de binaires pré-compilés compressés pour permettre aux utilisateurs de déterminer rapidement quel est le changement susceptible d’avoir introduit une régression longtemps après - jusqu'à inclure les réalisations Windows et Mac de la période 5.0 (c’est-à-dire de la branche 4.4 à la branche 5.0). La période 5.1 est compilée et rafraîchie régulièrement à un rythme raisonnable. Mille mercis à Norbert Thiebaud, Matthew Jay Francis & Robinson Tryon (qubit) (TDF).

Nettoyage de code

Le code sale devrait être nettoyé — et c'est ce que l'on a fait de-ci, de-là :

Mise à jour vers (un) sous-ensemble de C++11

Dans la version 5.0, nous avons commencé à migrer agressivement vers un sous-ensemble de C++11 que l'on peut maintenant utiliser avec notre compilateur mis-à-jour, et ainsi utiliser les modèles variadiques, l'initialisation plus simple, et bien d'autres. Du travail visant à enlever des bouts obsolètes de la std tels que les std::ptr_fun utilisant std::any_of et std::none_of. Les lauriers reviennent aux nettoyeurs de code dont Stephan Bergmann (RedHat), Takeshi Abe, Nathan Yee, Bjoern Michaelsen (Canonical) et bien d'autres.

Nettoyage du cadriciel

Grâce à Maxim Monastirsky, nous avons éliminé du cadriciel plusieurs centaines de lignes de code redondant, en créant des contrôleurs génériques configurés par de petits fichiers XML. C'est agréable de voir de tels nettoyages.

Expansion des types d'index entiers

Un certain nombre d'anciennes structures dans LibreOffice ont utilisé des index de 16 bits, et stocké/sérialisé ceux-ci dans diverses structures pendant de nombreuses années. Cela peut causer des problèmes lors de la fusion de très gros messages de courrier - tels que ceux utilisés dans la ville de Munich. Grâce à Katarina Behrens (CIB), Writer 5.0 permet plus de 64k de descriptions de page, de sections et de noms de style.

Réduction des commentaires allemands

Nous avons continué de progresser, mais d’une manière ou d’une autre les dernières ~5000 lignes de commentaires semblent défier toute tentative de traduction. Toute aide des germanophones via courriel est grandement appréciée. Mille mercis à Michael Weghorn, Michael Jaumann (Munich), Daniel Sikeler (Munich), Albert Thuswaldner, Christian M. Heller et Philipp Weissenbacher. Il ne reste à présent que huit modules à traduire : include, reportdesign, rsc, sc, sfx2, stoc, svx, sw.
Graph of remaining lines of German comment to translate

Conteneurs std::

Nous avons continuellement amélioré notre utilisation des conteneurs std:: à travers notre code. Des choses comme éviter l’héritage de std::vector, changer std::deque pour std::vector et commencer à utiliser les nouveaux constructeurs C++ pour des itérations comme for (auto& it : aTheContainer) { ... }. Il y a beaucoup de gens à remercier ici. Merci à Stephan Bergmann (RedHat), Takeshi Abe, Tor Lillqvist (Collabora), Caolan McNamara (RedHat), Michaël Lefèvre, et beaucoup d’autres.

Writer

Grâce à Bjoern Michaelsen (Canonical), dans la version 5.0, Writer a reçu un nettoyage longtemps désiré sur nombre de points-clés :

  • Amélioration et factorisation de plusieurs implémentations UNO du noyau de Writer concernant les tables, réduisant la taille du code d’environ 20 % et éliminant du code redondant. Des tests unitaires ont été ajoutés et il devrait maintenant être plus facile d’en ajouter d’autres, y compris pour vérifier le noyau de Writer.
  • Nettoyage de certaines classes très anciennes implémentant le modèle observateur d’une manière maladroite (SwClient/SwModify). Ajout d’un atelier de tests afin de clarifier son interface. En fin de compte, l’objectif est de s’éloigner de cette implémentation vers une des implémentations plus modernes que nous utilisons ailleurs. Ce travail devrait aider à trouver une voie de migration plus tard.
  • Plusieurs implémentations ad hoc de listes doublement chaînées intrusives ont été consolidées et fondues en une seule : sw::Ring. Ajout de tests pour clarifier son interface.
  • Utilisation de greffons du compilateur pour chasser à la fois les expressions conditionnelles en cascade les plus profondes et les affectations survenant au cours de l’évaluation des instructions conditionnelles, qui sont source d’erreurs, et transformer les pires contrevenants en quelque chose de plus lisible et de plus facilement maintenable.

Le resourcemodel de writerfilter

Le bloc de construction de resourcemodel de writerfilter (qui gère l'importation des DOCX et RTF de Writer dans LibreOffice) était essentiellement un tas de vieux trucs inutilisés. Les quelques morceaux encore nécessaires de celui-ci sont maintenant déplacés dans les parties utiles de mapper / tokenizer / filter, et le reste est maintenant supprimé. Vous pouvez lire plus de détails grâce à Miklos Vajna (Collabora).

Autres gains

Nous avons eu un certain nombre d'autres victoires qui sont un peu difficiles à classer, mais voici ce qui mérite d'être noté :

OOXML contre MS Office 2007

MS Office 2007 dispose d'un ensemble inutile de différentes valeurs par défaut pour beaucoup de ses attributs - par exemple, le même XML (avec un attribut manquant) peut produire des résultats différents dans Office 2007 et dans les versions suivantes. Il est clair que c'est assez irritant. Merci à Markus Mohrhard d'avoir ajouté certaines infrastructures (et un ensemble de correctifs) pour les attributs problématiques connus à cet égard. Cela devrait améliorer notre interopérabilité avec ce bazar de documents.

Abstraction du système de fichiers Android

Grâce aux donateurs de TDF et à Jacobo Aragunde Pérez (Igalia), nous avons mis en place une API d'abstraction de système de fichiers pour Android - pour permettre aux backends des systèmes de fichiers arbitraires d'être connectés (dans un processus séparé). Un exemple de backend OwnCloud a été mis en œuvre pour montrer ce cas.

Trucs de base

Grâce à Matthew Nicholls nous avons supprimé deux mille lignes de code de glue redondant dans la partie dbtoolsclient de svx, qui était dupliqué ailleurs dans connectivity. C'est génial de voir autant de cochonneries quitter le code.

S'impliquer

J'espère que vous admettez l'idée que de plus en plus de développeurs se sentent chez eux sur LibreOffice et travaillent ensemble à l’achèvement de certains travaux significatifs aussi bien sous le capot qu'en surface. Si vous voulez vous impliquer, il y a beaucoup de gens formidables à rencontrer et avec qui travailler. Comme vous pouvez le voir, les individus ont un impact énorme sur la diversité de LibreOffice (les légendes de couleur à droite doivent être lues de gauche à droite, de haut en bas, et vues de haut en bas sur le graphique) :
Graph showing individual code committers per month

Également en termes de diversité des changements apportés dans le code, nous aimons voir le volume des contributions spontanées des bénévoles, bien que clairement, volume et équilibre changent avec les saisons, le cycle de sorties, et les projets de vacances / affaires des bénévoles :
Graph of number of commits per month by affiliation

Naturellement, nous maintenons une liste de tâches de petites tailles, que vous pouvez consulter pour participer, avec des instructions simples de compilation / configuration. Il est extrêmement facile de compiler LibreOffice, chaque easy-hack ayant des liens vers le code et incluant une tâche facile à résoudre. En outre, certains d'entre eux sont des fonctionnalités vraiment sympas à avoir ou des améliorations de performance. Merci de ne pas vous considérer limité par quoi que ce soit.

Autre chose qui aide vraiment est d'exécuter des pré-versions et faire des rapports de bogues. Il faut juste récupérer et installer une pré-version et vous êtes prêt à contribuer aux côtés du reste de l'équipe de développement.

Conclusion

LibreOffice 5.0 est une excellente base pour construire les prochaines versions qui seront améliorées peu à peu, non seulement en fonctionnalités, mais également la base d’un intégré bureautique libre. Ce n’est bien sûr pas encore parfait, c’est la première publication d’une longue série de sorties mensuelles pour le cycle 5.0.x, et de sorties biannuelles pour le cycle 5.x, qui apporteront un flux de corrections et d’améliorations de la qualité pour les mois et années à venir.

J'espère que vous aimerez LibreOffice 5.0.0. Merci pour la lecture de ce billet, et n'oubliez pas de jeter un œil sur les nouveautés visibles par les utilisateurs et merci de soutenir LibreOffice.

La plupart des données brutes pour les graphiques ci-dessus sont disponibles.

  • # Xamarin et LibreOffice ?

    Posté par . Évalué à 5.

    Dans la rubrique "S'impliquer", je suis très surpris de voir que Xamarin s'implique autant dans LibreOffice. Autant je peux comprendre qu'ils s'impliquent dans Mono ou dans LLVM, mais dans LibreOffice ? Je ne vois pas le rapport ?

    Peut-être que je lis mal ces deux graphiques, mais ils ne sont pas dans les données brutes téléchargeables en fin d'article.

    • [^] # Re: Xamarin et LibreOffice ?

      Posté par . Évalué à 10. Dernière modification le 25/08/15 à 17:02.

      Le gros morceau en jaune, c’est “Assigned”, qui représente, je crois, les non-affiliés.
      Les couleurs du haut représente les labels en haut, et vice versa.
      Ces graphiques sont très peu lisibles, parce que nombre de contributions sont insignifiantes (en nombre), si bien qu’on ne les voit pas sur les volumes représentés.

      Pour le commits per month, en gros le graphique montre qu’il n’y a guère que RedHat, Collabora, Suse et les indépendants qui font une contribution significative en volume. Et un peu Canonical.

    • [^] # Re: Xamarin et LibreOffice ?

      Posté par . Évalué à -7.

      Il s'agit de la ligne "Assigned" et non pas de Xamarin.
      Lire la légende de bas en haut.

      Et c'est une bonne illustration de la raison principale de ma non utilisation de LibreOffice. La palette de couleur des graphiques est hideuse et illisible comparativement à Microsoft Office.

      • [^] # Re: Xamarin et LibreOffice ?

        Posté par . Évalué à 5.

        Je suis vraiment curieux de voir comment Excel pourrait être plus lisible avec autant de données.

        • [^] # Re: Xamarin et LibreOffice ?

          Posté par (page perso) . Évalué à 7.

          J’espère qu’Excel n’est pas la référence qualité.

          ce commentaire est sous licence cc by 4 et précédentes

          • [^] # Re: Xamarin et LibreOffice ?

            Posté par . Évalué à 10.

            Qu'importe le logiciel, il n'est pas possible de représenter une vingtaine de classes avec un code couleur et l'associer au terme qualité, que ce soit avec Calc, Excel, R, etc.

            • [^] # Re: Xamarin et LibreOffice ?

              Posté par . Évalué à 7.

              À condition d'accepter que le graphe ne soit pas équivalent aux données brutes, je ne vois pas pourquoi ce serait impossible de tracer un graphique de qualité. Il suffit d'accepter de perdre de l'information pour gagner en clarté.

              Par exemple, extraire les X affiliations ayant le plus de commits, puis grouper les autres en Y catégories (critère : moins de N commits par mois en moyenne), et tracer les X+Y courbes induites, avec une légende mentionnant toutes les affiliations dans chaque catégorie.

              On peut même imaginer que le logiciel propose par défaut des valeurs de X et Y optimales selon des contraintes visuelles (X + Y < 8 ?) et de représentativité (maximiser la séparation entre les ensembles dans X et Y ?).

            • [^] # Re: Xamarin et LibreOffice ?

              Posté par . Évalué à 5.

              Même avec 3 classes les graphiques LibreOffice sont hideux, ces couleurs par défaut sont juste horrible ! C'est cela que je voulais mettre en avant.

            • [^] # Re: Xamarin et LibreOffice ?

              Posté par . Évalué à 10.

              Les choix de couleur dans les représentations sont souvent ignobles d'un point de vue artistique. Je ne comprends pas que des solutions comme celle-ci ne soit pas utilisé :

              http://paletton.com/

              Il doit bien exister un moyen d'automatiser le choix des couleurs sans doublon, sans ambiguïté, et qui soit une minimum joli.

              "La première sécurité est la liberté"

              • [^] # Re: Xamarin et LibreOffice ?

                Posté par (page perso) . Évalué à 2.

                Je ne comprends pas que des solutions comme celle-ci ne soit pas utilisé :
                http://paletton.com/

                Oh c’est super ça, merci pour le lien ! Je m’en servirai quand j’aurai besoin d’avoir une palette propre sans réutiliser une qui soit déjà trop vue. :-)

                ce commentaire est sous licence cc by 4 et précédentes

              • [^] # Re: Xamarin et LibreOffice ?

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

                moyen d'automatiser le choix des couleurs sans doublon, sans ambiguïté, et qui soit une minimum joli

                Au moins avec ton exemple de site on a exemple moche et illisible. Il doit suffire de faire le contraire. Sérieusement, je ne tiens pas discuter de nos goûts, mais l’interface du site comme les palettes qu’il propose sont inutilisables pour une personne qui a la moindre difficulté visuelle ou qui l’observe dans des conditions non idéales. Et pour le coup, les camemberts Impress projetés avec un vieux projo terne dans une salle de réunion éclairée, c’est pas idéal et ça doit se lire quand même, alors ne remplaçons pas trop vite une palette moche par une proposition de palette illisible.

                • [^] # Re: Xamarin et LibreOffice ?

                  Posté par . Évalué à 2.

                  Vu tes commentaires, tu n'as du rien comprendre à leur interface, qui est pourtant clair. Elle gère même les daltoniens. Ils proposent des exemples de palettes mais c'est surtout un outil pour en fabriquer.

                  "La première sécurité est la liberté"

                  • [^] # Re: Xamarin et LibreOffice ?

                    Posté par (page perso) . Évalué à 1.

                    Merci mais j’ai bien compris à quoi cela sert (même si effectivement pas au premier coup d’œil) et je ne pourrai pas juger pour le daltonisme car je n’ai pas de daltonien sous la main pour valider. Par contre, il faut batailler pendant 10 ans pour obtenir un contraste satisfaisant (eh oui, ça aussi c’est important), et le coup de « on a pensé à tout » est vite mis en défaut quand tu tentes de projeter une palette pour voir (je n’ai pas tenté d’imprimer, mais concernant les palettes des graphiques LibreOffice, j’ai tendance à penser que projeter est un usage courant). Je suis toujours sceptique quand on présente des outils « magiques » mais là tu postes 3 liens vers le même site en 12 minutes, et je suis désolé si cela te déçois que ton élixir ne guérisse pas toutes les maladies.

      • [^] # Re: Xamarin et LibreOffice ?

        Posté par . Évalué à 7.

        Pourquoi ne pas proposer un changement de palette par défaut au projet, si cela est selon vous si abominable ?

        • [^] # Re: Xamarin et LibreOffice ?

          Posté par . Évalué à 2.

          • [^] # Re: Xamarin et LibreOffice ?

            Posté par . Évalué à 10.

            comme au minimum deux personnes n'ont pas aime que je ne mette que un lien voici l'explication de texte:

            The default colourmap in Matplotlib is the colourful rainbow-map called Jet, which is deficient in many ways: small changes in the data sometimes produce large perceptual differences and vice-versa; its lightness gradient is non-monotonic; and, it is not particularly robust against color-blind viewing. Thus, a new default colormap is needed—but no obvious candidate has been found. Here, we present our proposed new default colormap for Matplotlib, and expose the theory, tools, data exploration and motivations behind its design.

            C'est donc une video qui explique la creation d'une nouvelle carte de couleur pour matplotlib qui se base sur les dernieres recherches sur le sujet.

            • [^] # Re: Xamarin et LibreOffice ?

              Posté par (page perso) . Évalué à 5.

              La vidéo n'est pas pratique à consulter, mais ton commentaire m'a donné envie de comprendre la raison du changement.

              J'ai trouvé un article comparant les différentes solutions proposées et celles-retenues.

              Je ne pensais pas que le choix d'une palette était aussi travaillée. Mais l'usage de matplotlib dépasse le simple rendu de résultats d'activités…

      • [^] # Re: Xamarin et LibreOffice ?

        Posté par . Évalué à 4.

        Je suppose que tu parles uniquement des couleurs utilisées par défaut lors de la création d'un graphique. Sur ce point je te rejoins : les couleurs proposées par défaut dans Excel sont agréable à l'oeil et sélectionnées de manière à ne pas trop jurer avec les autres couleurs. Dans LibreOffice ces couleurs ne sont pas proposées par défaut, il faut créer sa palette sois-même.
        Je pense que c'est comme partout: il faut investir un peu de temps jusqu'à avoir quelque chose qui convient.

        Dans le cas de la présentation des données avec autant de couleur, je trouve qu'Excel ne fait pas mieux…

        • [^] # Re: Xamarin et LibreOffice ?

          Posté par . Évalué à 10.

          Sauf que le paramétrage par défaut d'un soft est celui utilisé par 90% des gens (chiffre certifié par l'Institut National de Pifométrie). Donc si tes valeurs par défaut sont pourries, les gens vont voir ailleurs. LibreOfffice a plein de fonctionnalités géniales et tient la comparaison sur plein de points mais plein de gens s'arrêtent à la première impression: c'est vieillot et les valeurs par défaut (styles, etc) ne permettent pas de sortir un truc sympa sans une grosse étape de personnalisation (et ne parlons pas de Draw :-p)

          • [^] # Re: Xamarin et LibreOffice ?

            Posté par . Évalué à 5.

            La gestion des palettes d'OpenOffice/LibreOffice a toujours été supérieure à celle de Microsoft Office.

            On peut depuis toujours ajouter des couleurs personnalisées à la palette, sans retaper les codes RGB tous les deux jours parce que l'applicatif l'a oublié (MSO). Avec les versions récentes LO peut même lire les formats de palettes graphiques tiers, on peut donc partager la même palette avec d'autres outils de la chaîne de publication (OO.o avait le fétichisme de ses propres formats, et refusait de s'intégrer avec autre chose).

            Ce qui permet d'importer les couleurs officielles définies par les communicants de la boîte dans tous les documents.

            Après il est vrai que MSO a compensé la nullité profonde de sa gestion des couleurs par de bons défauts. Le monde du logiciel libre a encore du travail à faire pour attirer de bons graphistes/designers dans un rôle de contributeur (inkscape & co ont résolu la partie utilisateur ces dernières années).

            • [^] # Re: Xamarin et LibreOffice ?

              Posté par (page perso) . Évalué à 8.

              À propos des couleurs, il serait très facile de récupérer une palette déjà faite par d’autres, comme la palette Tango.

              OK, le problème de palette c’est que tout le monde ressemble à tout le monde et que ça réduit la diversité, mais tu fournis ça à un utilisateur, il sera dur pour lui de se planter. Ce sont des palettes bien choisie pour conserver un minimum d’harmonie quand tu composes avec.

              Quand j’ai besoin de faire un document rapido sans faute de goût, j’utilise ce type de palette, ok il n’y a aucune originalité, mais ça ne pique pas les yeux.

              Même si tu n’as aucune connaissance des théories des couleurs, ou que tu ne veux pas te prendre la tête, se limiter à une palette de ce type sauve la vie et gagne énormément de temps.

              Ah, aussi, règle très facile à suivre, ne pas utiliser les couleurs VGA, qui ne se trouvent quasiment jamais visible en diffusion dans la nature. Ça agresse l’œil. C’est cool sur une démo 8bit qui flashouille et tournicote sur un écran cathodique, mais pas dans un document.

              ce commentaire est sous licence cc by 4 et précédentes

              • [^] # Re: Xamarin et LibreOffice ?

                Posté par . Évalué à 4.

                J'ai regardé cette palette et, en voulant trouver comment elle pourrait être intégrée à LibreOffice, je me rends compte qu'il y a une palette déjà installée qui s'appelle tango…

                Donc c'est déjà présent d'office (sans jeu de mot).

                • [^] # Re: Xamarin et LibreOffice ?

                  Posté par (page perso) . Évalué à 10.

                  C’est un type de palette qui devrait être par défaut.

                  Moi même je ne sais pas comment ajouter des couleurs dans LibreOffice ni même s’il y a plusieurs palettes et comment la choisir.

                  Une palette par défaut doit être tolérante aux erreurs. Faire de l’insupportable doit être un comportement avancé, et faire de l’agréable doit être par défaut. Libreoffice donne à l’utilisateur de faire par défaut de l’insupportable, et faire de l’agréable est à sa charge, s’il sait faire.

                  Changer de palette ou ajouter des couleurs, c’est comme le hors piste : tu es libre de le faire mais tu sais que tu prends des risques sous ta seule responsabilité. Sous LibreOffice, l’agréable est uniquement accessible en hors-piste. Ce devrait être l’inverse.

                  ce commentaire est sous licence cc by 4 et précédentes

                  • [^] # Re: Xamarin et LibreOffice ?

                    Posté par . Évalué à 6.

                    Palette de couleurs

                    Les palettes de couleurs sont des fichiers d'extension .soc qui sont en fait des fichiers xml.
                    Pour LibreOffice 5.0 les palettes fournies par défaut sont dans /opt/libreoffice5.0/presets/config/ (si LibreOffice a été installé en utilisant les paquets téléchargés sur le site LibreOffice, sinon un locate *.soc vous renseignera).
                    On y trouve par exemple la palette scribus.
                    Pour changer la palette utilisateur on peut procéder de la façon suivante :
                    - menu Outils > Options > LibreOffice > Couleurs
                    - Bouton en bas à droite "Charger la liste des couleurs"
                    - choisir le fichier .soc de votre choix
                    - Bouton Enregistrer la liste des couleurs -> donner le nom "standard.soc" (on peut utiliser la même procédure pour enregistrer une copie du standard.soc actuel)
                    - valider, fermer et relancer LibreOffice

                    Autre méthode : fermer LO et copier un fichier .soc sous le nom standard.soc dans ~/.config/libreoffice/4/user/config/
                    (Oui le nom du dossier utilisateur est resté 4 pour LO 5 pour éviter une opération de migration car il n'y a rien à migrer, les 2 profils sont compatibles).

                    Liste de couleurs pour les graphiques

                    La liste des couleurs pour les graphiques est à choisir dans la palette courante. Cela se fait ici :
                    - menu Outils > Options > Diagrammes > Couleurs par défaut
                    Il y a 12 couleurs au départ mais on peut en ajouter ou en enlever.

                    • [^] # Re: Xamarin et LibreOffice ?

                      Posté par (page perso) . Évalué à 3.

                      Ah merci, mais ça c'est la méthode pour faire des choses inattendues.

                      ce commentaire est sous licence cc by 4 et précédentes

                      • [^] # Re: Xamarin et LibreOffice ?

                        Posté par (page perso) . Évalué à 3.

                        inattendues

                        bin, grâce à jbf< tu peux les faire par toi-même !?

                        tu nous donneras ce que ça donne sur extensions.libreoffice.org ? (moi j'en suis bien incapable, même si je connais la PAO, je ne suis pas graphiste).

                    • [^] # Re: Xamarin et LibreOffice ?

                      Posté par (page perso) . Évalué à 6.

                      Cela vaudrait le coup de préciser le wiki de doc' et les PDF :-) (histoire d'être un peu plus précis).

                      Je n'ai pas forcément retrouvé les dernières versions ni toutes les pages qui seraient concernées :/ Ce n'est pas toujours clair à première lecture ce qui concerne Writer / Calc / Impress…

                      Pour des palettes supplémentaires, j'imagine que ce serait à proposer dans les extensions et non en tant que template ? sur http://extensions.libreoffice.org/?set_language=fr

                      Maintenant, ne reste qu'à trouver quelqu'un pour proposer :

                      • des couleurs pastel, déclinées selon les tons rouge / vert / bleu / violet / jaune ou arc-en-ciel
                      • des couleurs plus franches mais plus agréables que ce qu'il y a actuellement (qui tranche un peu trop, je ne sais pas trop comment le décrire…)
                      • des couleurs adaptées pour les daltoniens et aussi l'impression en nuances de gris

                      Note : en v4.4.2 sur Mageia 5, il n'y a pas de bouton « charger la liste des couleurs » lorsque tu passes par Menu > options > LibreOffice > Couleurs, il faut passer par Format > Image > Remplissage… > Couleurs comme indiqué sur https://help.libreoffice.org/Draw/Defining_Custom_Colors/fr

                      Merci de ton retour, reste à trouver la même chose pour avoir un ensemble de styles de texte par défaut pour Writer :-) (là ça irait dans les templates je pense).

                    • [^] # Re: Xamarin et LibreOffice ?

                      Posté par (page perso) . Évalué à 10.

                      Pour changer la palette utilisateur (…)

                      La question n'est pas de changer, mais d'avoir quelque chose par défaut de correct en 2015 (nous ne sommes plus en 1995 avec des palettes CGA de 16 couleurs)
                      Test avec LO5 (la dernière, 2015 et même pas jugé stable) et Excel 2010 (il y a 5 ans!):
                      LO vs MSO

                      Il y en a un que je peux présenter à des gens, pas l'autre sans faire 36 bidouilles à coup de .soc (ben non, je ne ferai pas de .soc car ce n'est pas le but et je ne sais pas faire en fait)

                      LO est un super projet car MSO coûte un bras, mais pour que ça marche il ne faut pas seulement faire de la technique, mais aussi du "design". Ici, je comprend que les gens hurlent sur LO et installent un MSO en pirate au taf car ils ne regarderont pas LinuxFr pour savoir comment changer ses couleurs horribles. La réponse "pour changer (…)" n'est pas pertinente (les gens ne savent pas changer les couleurs sous Excel, mais en fait… Ils s'en foutent, ils n'en éprouvent pas le besoin).

                      Et oui, je sais, je pourrai proposer une .soc plus moins bien, mais comme l'ont déjà d'autres je ne suis pas doué en ça (je sais juste voir que c'est "plus joli" ailleurs) et je ne suis pas une entreprise qui a besoin de ne pas payer MSO.

                      Désolé, mais la réponse est une réponse de technicien à des techniciens, alors que de nos jours les utilisateurs ne sont pas des techniciens.

                      • [^] # Re: Xamarin et LibreOffice ?

                        Posté par (page perso) . Évalué à 0. Dernière modification le 27/08/15 à 00:14.

                        Tu viens de montrer que les 2 sont moches àmha :-) outre que celui à gauche perd plein de place avec un ruban de merde, incompréhensible pour ceux ayant été habitués aux versions précédentes.

                        Tu aurais pu au moins prendre PowerPoint vs Impress qui apporte quelques améliorations notables (mais reste toujours une plaie à utiliser quand on fait un copier/coller de Word à l'outil de présentation, styles non partagés, contrairement à la cohérence apportée par LibreOffice).

                        Je suis assez d'accord sur l'EGA pour les deux tout de même :D (non, ce n'est pas du CGA, mais pas du VGA non plus, il est vrai).

                        Une vraie comparaison serait avec un outil professionnel comme R, là ce que tu présentes est du niveau de matplot :-)

                        • [^] # Re: Xamarin et LibreOffice ?

                          Posté par (page perso) . Évalué à 2.

                          oups, j'ai été mauvaise langue :

                          matplot camenbert

                          Matplot est bien plus joli que tes exemples : http://matplotlib.org/examples/pie_and_polar_charts/pie_demo_features.html

                          Pour R, il y a http://3.bp.blogspot.com/_FsLa1cMTCWU/TFHJVgmxV2I/AAAAAAAAATk/2-hAhNNk7ns/s1600/pie_chart3.png qui est pas mal, je laisse à titre d'exercice trouver des représentations en 3D encore plus jolies :-)

                          • [^] # Re: Xamarin et LibreOffice ?

                            Posté par . Évalué à 3.

                            Pour R, il y a http://3.bp.blogspot.com/_FsLa1cMTCWU/TFHJVgmxV2I/AAAAAAAAATk/2-hAhNNk7ns/s1600/pie_chart3.png qui est pas mal, je laisse à titre d'exercice trouver des représentations en 3D encore plus jolies :-)

                            Le violet et le rose et le vert et le bleu sont trop proches et peuvent être difficiles à distinguer.

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

                            • [^] # Re: Xamarin et LibreOffice ?

                              Posté par (page perso) . Évalué à 2.

                              Le violet et le rose et le vert et le bleu sont trop proches et peuvent être difficiles à distinguer.

                              franchement, pas pour moi, mais pour ceux ayant une vision différente, c'est bien possible.

                              Je ne parle pas de vision déficiente : la vision des couleurs est complexe (à l'impression en nuances de gris notamment)

                              Tu aurais de meilleurs exemples ?

                        • [^] # Re: Xamarin et LibreOffice ?

                          Posté par (page perso) . Évalué à 8. Dernière modification le 27/08/15 à 08:41.

                          outre que celui à gauche perd plein de place

                          Pour info, le ruban se ferme.

                          un ruban de merde

                          Ce n'est pas parce qu'il ne te plait pas que c'est de la merde.

                          incompréhensible pour ceux ayant été habitués aux versions précédentes.

                          et?
                          En gros, tu dis qu'il ne faut pas changer les habitudes… Euh… Tu aimes SysV aussi alors que systemd est incompréhensible pour ceux ayant été habitués aux versions précédentes des système d'init Linux? (oui, tentative de troll)

                          Une fois passé l’adaptation, le ruban est un bonheur, et perso j'ai toujours du mal à me remettre à LO car je ne suis plus habitué à ces "menus à l'ancienne".
                          LO est donc de la merde (ce sont tes mots) car les gens habitué à MSO 2010+ trouvent incompréhensibles les menus de LO. Comme quoi, ça marche dans les deux sens…

                          Tu viens de montrer que les 2 sont moches àmha :-)

                          Les gouts et les couleurs, sans doute, mais en pratique LO rebute à cause de ces couleurs. Libre à toi de penser que c'est équivalent, mais en pratique l'un est plus utilisé que l'autre (surtout quand ce n'est pas les informaticiens qui imposent le choix).

                          Une vraie comparaison serait avec un outil professionnel comme R, là ce que tu présentes est du niveau de matplot :-)

                          Tes graphiques sont, comment dire… Non rien, ça doit être la subjectivité.
                          (surtout que tu ne compares pas la même chose, j'ai pris le truc basique sans partie éclatée)

                          Mais après, je suis étonné qu'on s'étonne que Linux pour le Desktop ne prenne pas avec de telles subjectivités… (c'est dans le même style de subjectivité pour d'autres composants visibles, bien que je remarque quand même une nette évolution dans les dernières versions de distro Linux du moins sur la partie DM)

                          • [^] # Re: Xamarin et LibreOffice ?

                            Posté par . Évalué à 2.

                            (c'est dans le même style de subjectivité pour d'autres composants visibles, bien que je remarque quand même une nette évolution dans les dernières versions de distro Linux du moins sur la partie DM)

                            Je crois qu'on peut remercier en partie systemd-logind pour cela. :)

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

                          • [^] # Re: Xamarin et LibreOffice ?

                            Posté par . Évalué à 10.

                            Une fois passé l’adaptation

                            c'est amusant comme les utilisateurs sont capables de faire cet effort pour certains logiciels mais pas pour d'autre…

                        • [^] # Re: Xamarin et LibreOffice ?

                          Posté par . Évalué à 6.

                          celui à gauche perd plein de place avec un ruban

                          Non en fait il en gagne. Avoir une barre toute petite ne sers à rien si c'est pour devoir ouvrir une boite de dialogue dès que tu veux t'en servir. C'est le cas de LibO avec les styles par exemple. Donc se donner un peu plus de place pour avoir des accès direct aux fonctionnalités dont tu as besoin (tel que voir ce que donne un style donné), ce n'est pas perdre de la place.

                          Une vraie comparaison serait avec un outil professionnel comme R, là ce que tu présentes est du niveau de matplot :-)

                          R est moche de base. Je n'ai jamais trop essayé d'en faire quelque chose de magnifique, mais de base, les graphiques sont pixelisés.

                          Peut être que la solution serait d'avoir une notion de thème et que ce soit vraiment mis en avant (par exemple avoir un thème xkcd : http://matplotlib.org/xkcd/examples/showcase/xkcd.html)
                          De même pour les styles de documents.

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

                          • [^] # Re: Xamarin et LibreOffice ?

                            Posté par (page perso) . Évalué à 7.

                            C'est le cas de LibO avec les styles par exemple.

                            Tout comme c'est le cas de MSO : dans Word, tu ne vois que 6 styles : Normal, sans interligne (o_O), Titre 1, Titre 2, Titre, Sous-titre. Pour avoir accès à plus de styles, soit tu cliques sur l'ascenseur (ce qui affiche 18 possibilités), soit tu colles la liste des styles en fenêtre ou adhérente au bord droit (comme sous LibO donc, très pratique sur les écrans 16/9 où il y plein de place de part et d'autre).

                            Concernant le ruban, oui, je sais qu'il se cache, en cliquant tu ne le fais réapparaître que ponctuellement et il redisparaît, il faut double-cliquer pour le faire revenir…

                            • la sélection Accueil est tout aussi incohérente qu'auparavant quand il fallait aller sur Fichier pour changer les marges de la page
                            • la sélection Mise en page est bien faite : elle apporte enfin la cohérence sur choix des marges (graphiquement en plus, ce qui convient la plupart du temps) et sur les autres options qui sont homogènes, contrairement à Accueil qui présente un peu de tout (pourquoi Coller n'est pas dans Insertion ?)
                            • la sélection Insertion est un peu un fourre-tout…
                            • avoir au même niveau Publipostage et révision m'a toujours paru bizarre…

                            bref, pas convaincu…

                            • [^] # Re: Xamarin et LibreOffice ?

                              Posté par . Évalué à 7.

                              Tout comme c'est le cas de MSO : dans Word, tu ne vois que 6 styles : Normal, sans interligne (o_O), Titre 1, Titre 2, Titre, Sous-titre.

                              Si ça suffit pourquoi en montrer plus ? L'idée ce n'est pas d'avoir le maximum de fonction, c'est d'avoir les fonctions utiles à l'utilisateur. Je pense que la prévisualisation est plus importante que d'avoir accès à 11 millions de styles.

                              bref, pas convaincu…

                              Il n'est pas parfait, c'est clair, mais de là à le considérer comme un mal absolu comme on le vois souvent ici.

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

                              • [^] # Re: Xamarin et LibreOffice ?

                                Posté par . Évalué à 4.

                                Si ça suffit pourquoi en montrer plus ?

                                En fait il n'en montre pas 6 (enfin, dans Word 2010).
                                Ça dépend de la largeur de l'écran. Ici j'en ai 13 en full screen en 1900x1200.

                          • [^] # Re: Xamarin et LibreOffice ?

                            Posté par . Évalué à 5.

                            Dans le cadre d'un traitement de texte, le ruban en haut est une hérésie actuellement. Les écrans sont de plus en plus larges et un document texte est bien souvent vertical. Donc consommer de l'espace en haut est un non sens. Avec LO les boites tu peux les mettre sur le côté là ou il y a de l'espace libre et garder le max de hauteur pour le doc.
                            Après on peut peut-être mettre le ruban de MSO sur les côtés ?

                            • [^] # Re: Xamarin et LibreOffice ?

                              Posté par (page perso) . Évalué à 3.

                              Après on peut peut-être mettre le ruban de MSO sur les côtés ?

                              Pas à ma connaissance (je dirai donc : pas facilement, du moins).
                              Après, l'hérésie est aussi pareille sur les navigateurs web : LinuxFr (par exemple) a maintenant une largeur maximale, donc du vide sur le côté, et donc la barre d'onglet et icônes devrait être sur le côté, mais c'est une extension (peu utilisée) pour FF et impossible maintenant avec Chrome.
                              Pareil d'ailleurs pour la barre de tâche, je suis le seul que je connaisse qui met la barre de tâche (Windows dans mon cas) sur le côté alors que c'est facile à faire. Sur ce point, l'habillage par défaut d'Ubuntu me plait pas mal (c'est sur le côté, en plus d'être assez joli) mais ça semble une exception.

                              bref, il faut croire que quasi tout le monde se fout complet et veut juste une "écran plus grand pour pouvoir voir plus de choses", snif.

                              • [^] # Re: Xamarin et LibreOffice ?

                                Posté par . Évalué à 7.

                                Pareil d'ailleurs pour la barre de tâche, je suis le seul que je connaisse qui met la barre de tâche (Windows dans mon cas) sur le côté alors que c'est facile à faire.

                                Je fait ça depuis plus de 10 ans et j'ai converti facilement pas mal de monde tellement c'est mieux. Je la met à droite vu que je suis droitier, je pense que pour un gaucher ce sera plus naturel de la mettre à gauche. Avec Gnome 2 c'était possible mais totalement inutilisable en pratique.

                                J'ai pris cette habitude avec WindowMaker qui a repompé ça sur NeXTSTEP. J'avais un prof d'histoire géo qui nous faisait retourner les feuilles pour avoir la marge à droite, parce qu'il disait que c'était bien plus pratique de noter des choses quand la marge est à droite plutôt qu'à gauche. Plus de 20 ans après je m'en souviens encore.

                                • [^] # Re: Xamarin et LibreOffice ?

                                  Posté par (page perso) . Évalué à 3.

                                  Pareil, ou en haut, comme sous Gnome (où j'ai souvent un gkrellm sur tous les bureaux, sur la droite).

                                  Pour la marge à gauche, je m'étais aussi fait la réflexion lorsqu'un prof nous avait demandé de laisser 1 cm sur la droite pour marquer les lignes à revoir (avec la marge gardée à gauche pour ses annotations… la force de l'habitude sans doute), ça nous obligeait à avoir une règle pour tracer cette marge supplémentaire :/.

                              • [^] # Commentaire supprimé

                                Posté par . Évalué à -10.

                                Ce commentaire a été supprimé par l'équipe de modération.

                            • [^] # Re: Xamarin et LibreOffice ?

                              Posté par . Évalué à 10.

                              Dans le cadre d'un traitement de texte, le ruban en haut est une hérésie actuellement.

                              Rien que ça… Le fait d'avoir une palette de couleur que tout le monde s'accorde à considérer comme moche avec comme seul réponse qu'il est possible de créer un fichier XML qui fait largement mieux. C'est aussi une hérésie, non ? Un document étant plus lus qu'édité, avoir un résultat beau est plus important.

                              Il y a une manière simple de voir, en écoutant les utilisateurs on trouve les hérésies plus hérétiques que les autres ;)

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

                              • [^] # Re: Xamarin et LibreOffice ?

                                Posté par (page perso) . Évalué à 1.

                                Il y a une manière simple de voir

                                en proposant des palettes plus sympathiques ;-)
                                Il n'y a même pas de XML à écrire, il est généré automatiquement grâce aux liens donnés précédemment.

                  • [^] # Re: Xamarin et LibreOffice ?

                    Posté par (page perso) . Évalué à 4.

                    N'étant absolument pas utilisateur régulier des suites bureautiques, je ne sais pas si c'est bien ce dont on parle, mais avec LibreOffice 5, quand je lance Writer ou Calc, à droite de Couleur de police, Surligner, Arrière-plan… il y a une petite flèche qui va vers le bas. En cliquant dessus, on peut choisir la couleur de notre choix, mais également la palette. Et il se trouve que juste après celle par défaut, Tango est la première à être proposée.

                    De choisir les couleurs issues de Tango se fait donc en deux clics de souris, sans être expert et sans avoir eu besoin d'une formation. Par contre, ça serait effectivement sympa d'avoir une option tout aussi accessible pour pouvoir définir un autre choix comme palette par défaut.

                    • [^] # Re: Xamarin et LibreOffice ?

                      Posté par . Évalué à 4.

                      Je viens de tester, c'est vrai que c'est simple mais le choix sur une autre palette que celle par défaut n'est pas conservé à l'ouverture suivante. Je pensais que mon choix aller être conservé.

        • [^] # Re: Xamarin et LibreOffice ?

          Posté par . Évalué à 10.

          Créer sa palette est effectivement une possibilité, mais je ne suis pas qualifié pour en faire une meilleure.

          Je m'explique : je suis capable de voir que la palette par défaut est horrible visuellement. Je n'ose pas faire une présentation ou un rapport avec de telles couleurs, ça fait années 90. Par contre je ne m'y connais pas assez en design ou colorimétrie pour en faire une meilleure. Tout mes essais en la matière se sont soldés par un échec, à part peut-être quand il n'y a que 3 ou 4 couleurs, et encore. De la même façon que je sais dire si un tableau d'un peintre me plait ou pas mais je suis bien incapable de faire mieux.

          C'est là que la personnalisation atteints ses limites. Certes je peux modifier les couleurs techniquement, mais sans être un expert en design je ne peux pas le faire de façon satisfaisante.

          De plus, même si j'arrivais à faire une meilleure palette, dès que j'installe LO quelque part je me retrouve avec la vielle palette et je n'ai pas toujours des sauvegardes sous la main pour récupérer une autre palette.

          LibreOffice devraient embaucher un expert et changer la palette par défaut. Je suis sûr que LO gagnerait en image, et que ce n'est certainement pas si cher à faire ! Mais j'ai toujours pensé qu'ils ne le faisaient pas pour des questions de rétrocompatibilité.

  • # Crashs tests

    Posté par . Évalué à 10.

    notre imposant corpus de documents de tests (plus de 75 000 documents douteux et bogués)

    C'est super intéressant, ça. On peut vous soumettre des documents pour ce corpus (ou en tous cas vérifier qu'ils n'y sont pas déjà)? J'ai quelques souvenirs cuisants de fichiers .rtf issus du Ministère des Finances (français), qui rendaient super mal sous Wordpad, mais qui surtout plantaient purement et simplement de nombreuses versions de LibreOffice (et d'OOo avant).

    J'avais soumis des rapports de bug à ce sujet, je crois en liant les fichiers, donc peut-être que ça a suffi à ce qu'ils se retrouvent dans le corpus de tests, non?

    • [^] # Re: Crashs tests

      Posté par . Évalué à 10.

      C'est bien possible, il y a plus de 200 fichiers RTF dans la branche 5.0 du dépôt git de LibreOffice, la plupart nommés en référence à un rapport de bug.

    • [^] # Re: Crashs tests

      Posté par . Évalué à 3.

      Tous les documents attachés à un bogue dans le bugzilla LO sont ensuite réutilisés dans ces tests (de mémoire).

  • # 14 ans

    Posté par . Évalué à 10. Dernière modification le 26/08/15 à 00:29.

    Cela fait 14 ans maintenant que j'utilise exclusivement LibreOffice (et OpenOffice.org auparavant), et ce pour toutes les tâches de bureautique qui le nécessitent, depuis le CV à la mise en page très (trop ?) complexe aux différents courriers et feuilles de calcul.

    J'ai en effet complètement lâché Microsoft Office après la version 2000 (dont je disposais via un abonnement MSDN), donc courant 2001, lorsque Office XP est sorti. Depuis je n'ai plus jamais utilisé cette suite à titre personnel.

    Hé bien franchement, tout au long de cette période, j'ai râlé sur pas mal de choses concernant cette suite libre, notamment sa lenteur (au point que Microsoft Office se lançait plus vite via wine que OpenOffice.org), et aussi le fait que certaines choses me paraissaient plus simples avec Microsoft Office (notamment les graphiques).

    N'empêche que malgré tout, je l'ai utilisée exclusivement, car c'était la seule suite bureautique qui répondait à mes contraintes (autant de budget que de licence et surtout de pérénité des données), et c'est avec plaisir que de version en version, j'ai vu ce logiciel continuellement s'améliorer, et que j'ai vu la plupart de mes reproches disparaître.

    Et aujourd'hui, je peux ouvrir et exploiter sans aucun problème des documents d'il y a plus d'une décennie, alors que je me souviens des nombreuses galères que j'ai pu avoir à gérer entre les différentes versions de Microsoft Office.

    Alors merci à tous ceux qui ont participé et participent à rendre ce logiciel libre toujours meilleur, c'est comme cela que j'apprécie voir le logiciel libre se développer.

    • [^] # Re: 14 ans

      Posté par (page perso) . Évalué à 10.

      Une expérience assez similaire, professionnellement aussi, en ajoutant que je n'utilise MS Office que pour un document envoyé par un client et qui est bourré de macro pour adapter la mise en page aux différents cas (alors qu'il y a plein de suite d'espaces à la place des tabulations…).

      Les lenteurs au démarrage sont assez vieilles et je ne le ressens plus depuis plusieurs années. Ce qui me posait problème c'était la perte d'images de temps en temps sur des documents avec beaucoup de photos d'insérées. Mais c'est réglé aussi.

      Le passage de OO à LO a été vraiment bénéfique, car c'est vraiment à partir de ce moment que les changements ont été rapides.

      Merci donc, et je vais de ce pas tester la version 5 pour signaler les cas de régressions. Mais ça fait de nombreuses release que ça ne m'est pas arrivé.

    • [^] # Commentaire supprimé

      Posté par . Évalué à -10.

      Ce commentaire a été supprimé par l'équipe de modération.

  • # Styles et formatage

    Posté par (page perso) . Évalué à 10. Dernière modification le 26/08/15 à 01:27.

    Depuis Office 97 si je me souviens bien, les styles sont devenus le "bread and butter" pour avoir des beaux documents faciles à modifier. Tout comme l'arrivée des CSS a rendu les pages web plus belles et facile à écrire.

    Je pense qu'Office 2007 (celui où le bandeau à nettoyé l'interface d'Office) a fait un grand pas en avant en venant avec une belle police par défaut (Calibri de mémoire), une palette de couleur adéquate (variante de tons sur quelques couleurs) et un accès aux styles plus évident (apercu du style dans l'interface et changement à vue du style de la sélection dans la page quand on parcourt les styles)

    Sous libre office, c'est toujours les outils de formattage (gras, souligné, police, etc…) qui sont mis en avant dans l'interface et le néophyte n'est pas du tout encouragé à utiliser les styles. Pourquoi?

    La palette de couleur de base tout comme les styles par défaut sont horribles
    Qui écrit en police serif et en couleur Bordeaux? (tout en ayant les titres en sans serif, beaurk)

    • [^] # Re: Styles et formatage

      Posté par . Évalué à 5. Dernière modification le 26/08/15 à 08:57.

      La première chose que présente writer dans ses boîtes d'outils de formatage concerne le style.
      Je ne vois pas comment les mettre plus en avant en restant cohérent dans le design (donc sans créer un bandeau de 10cm en haut du document, ceci sans tenir compte du fait que les écrans ont perdu en hauteur ces derniers temps : 4/3 -> 16/10 -> 16/9)

      Par ailleurs, 90% des utilisateurs d'un traitement de texte ne savent pas ce que c'est qu'un style et ne veulent pas le savoir. De part la maigre couche d'abstraction nécessaire à leur usage, ces styles finissent par poser plus de problèmes qu'ils n'en résolvent pour ces personnes qui refusent tout apprentissage, en critiquant le soi disant manque d'ergonomie pour justifier leurs échecs…
      Je n'ai d'ailleurs pas l'impression que MS Office soit plus efficace pour ces utilisateurs, simplement ils sont moins enclins à critiquer le produit vu sa réputation (contrairement à loffice)

      • [^] # Re: Styles et formatage

        Posté par . Évalué à 10.

        donc sans créer un bandeau de 10cm en haut du document, ceci sans tenir compte du fait que les écrans ont perdu en hauteur ces derniers temps : 4/3 -> 16/10 -> 16/9

        En créant une barre sur le coté ? En modifiant le style du document à la volé (et sans le caché par une boite de dialogue ?

        Par ailleurs, 90% des utilisateurs d'un traitement de texte ne savent pas ce que c'est qu'un style et ne veulent pas le savoir. De part la maigre couche d'abstraction nécessaire à leur usage, ces styles finissent par poser plus de problèmes qu'ils n'en résolvent pour ces personnes qui refusent tout apprentissage, en critiquant le soi disant manque d'ergonomie pour justifier leurs échecs…

        C'est avec ce genre de résonnement qu'on fait de la merde : en prenant pour acquis que l'utilisateur est un bourrin et que rien y ferra. C'est un chalenge, ça donne du travail mais c'est comme ça qu'on passe d'un logiciel techniquement pas mauvais à un très bon logiciel.

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

      • [^] # Re: Styles et formatage

        Posté par . Évalué à 7.

        Je ne vois pas comment les mettre plus en avant en restant cohérent dans le design (donc sans créer un bandeau de 10cm en haut du document, ceci sans tenir compte du fait que les écrans ont perdu en hauteur ces derniers temps : 4/3 -> 16/10 -> 16/9)

        Il serait peut-être temps de songer à mettre un bandeau à gauche de l’écran, non ? Toute cette place perdue, c’est quand même ballot (et autant utiliser un 4/3 en portrait était agréable, un 16/9, c’est insupportablement trop étroit).

        Sinon, au centre, juste au-dessus du document (donc là où c’est le plus visible), on a bien le formatage direct… Quant aux styles de caractères, il faut activer la barre d’outil style pour y avoir accès.

        Je n'ai d'ailleurs pas l'impression que MS Office soit plus efficace pour ces utilisateurs, simplement ils sont moins enclins à critiquer le produit vu sa réputation (contrairement à loffice)

        Tous les gens que je connais qui utilisent les deux (par exemple, l’un professionnellement et l’autre à la maison, parce que ce ne sont pas des vilains pirates) se plaignent de LO. Le bandeau est globalement bien apprécié, et ensuite, ce sont plein de petits détails qui fonctionnent bien sous MSO et mal sous LO (comme, copier-coller de la mise en forme, le placement des images qui sous LO est une vaste blague, le rendu par défaut qui est plus joli, etc)

        Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0

        • [^] # Re: Styles et formatage

          Posté par . Évalué à 1.

          Il serait peut-être temps de songer à mettre un bandeau à gauche de l’écran, non ?

          Déjà fait en partie avec LO 5 mais à droite. De plus, rien n'empêche depuis longtemps de déplacer le bandeau actuel en vertical à gauche ou à droite avec un simple cliquer-glisser. Je l'ai fait depuis plusieurs années. C'est trop simple ?

          copier-coller de la mise en forme, le placement des images qui sous LO est une vaste blague, le rendu par défaut qui est plus joli

          Les problèmes ont été pour la plupart corrigés depuis la version 4.4 ou les dernières 4.3 des distributions Linux. J'ai aussi des problèmes de placement d'images sous MS Office au boulot. C'est souvent dû à l'utilisation d'espaces pour caler les images par les utilisateurs, si si je le vois assez souvent ! :(.

          Seul grosse différence qui agace : un affichage différent des dimensions des polices ou des interlignes ou paragraphes ou entre les images, je ne sais pas, qui fait un décalage de la pagination. Mais je ne suis pas sûr que ce ne soit LO le fautif.

          Quand à l'esthétique, c'est très subjectif. C'est vrai que MSO fait des documents par défaut parfois plus clinquant, mais je n'aime pas.

          En résumé, match nul sur ces aspects-là à mon avis.
          J'utilise OO puis LO depuis une dizaine d'années.

          • [^] # Re: Styles et formatage

            Posté par . Évalué à 6.

            C'est trop simple ?

            Beaucoup trop compliqué. Sortir de vi c'est :q, c'est hyper basique, mais ça n'en fait pas quelque chose de simple. Si rien ne montre que c'est possible alors c'est impossible. Tu a peu d'utilisateurs qui vont tenter d'aller faire des glisser/déposer dans tous les sens pour voir ce qui est possible ou non.

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

            • [^] # Re: Styles et formatage

              Posté par . Évalué à 2.

              C'est pourtant une méthode utilisable depuis plus de 10 ans dans les logiciels dits les plus ergonomiques et remis au goût du jour par Android sur les tablettes.

            • [^] # Re: Styles et formatage

              Posté par . Évalué à 6.

              Accessoirement ce n’est pas robuste, dans le sens ou un utilisateur peut péter sa configuration sans le faire exprès (un glisser malencontreux et hop, plus de barre d’outil) et qu’il n’y a pas de moyen simple de revenir à la configuration par défaut.

              Et non, ce n’est pas d’accuser l’utilisateur d’être trop con qui règle le problème.

              Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0

              • [^] # Re: Styles et formatage

                Posté par (page perso) . Évalué à 1.

                Clic droit --> Lock Toolbar Position

                Ca me semble plutôt intuitif.

                La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas sentis la différence.

                • [^] # Re: Styles et formatage

                  Posté par . Évalué à 9.

                  Tellement intuitif que c’est mal traduit dans la version française (« Bloquer la position des barres d’outils », alors que ça n’en bloque qu’une seule à la fois).

                  Si même le traducteur ne comprend pas ce que ça fait, comment espères-tu que l’utilisateur le fasse ?

                  Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0

          • [^] # Re: Styles et formatage

            Posté par . Évalué à 2.

            Dans pagemaker, la gestion du placement d'image et de placement du texte se faisait en 3 clics. C'était absolument fabuleux (il y a 15 ans). En gros, le texte est un ruban qui se contorsionne autour des images qui sont placé par rapport au page et non au texte. En utilisant une image réduite de 64Ko, l'affichage était hyper fluide.

            "La première sécurité est la liberté"

            • [^] # Re: Styles et formatage

              Posté par . Évalué à 5.

              C’est comme dans scribus, non ?

              Le soucis, c’est que ça va bien pour de la mise en page finale, mais pas pour des figures au sein d’un document, qui doivent « suivre » le paragraphe qu’elles illustrent quand on rajoute du contenu avant.

              Bref, pas le même outil pour pas le même usage. Mais scribus est un outil utilisable et bien adapté à son cas d’utilisation, recommandable sans soucis.

              Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0

              • [^] # Re: Styles et formatage

                Posté par (page perso) . Évalué à 3.

                C’est comme dans scribus, non ?

                Et comme dans LibreOffice si tu ancres les figures à la page. Ce n’est juste pas le comportement par défaut (ancré au paragraphe par défaut) pour la raison que tu évoques.

      • [^] # Re: Styles et formatage

        Posté par (page perso) . Évalué à 10.

        Les styles c'est bcp plus simple à utiliser que le formattage classique.
        Mais créer les styles est compliqué. Donc ce qu'il faudrait c'est comme pour les blog wordpress, tu importes un "thème" qui comporte des styles qui vont ensemble et tu ravales la facade de ton document.
        ex : http://winsupersite.com/site-files/winsupersite.com/files/archive/winsupersite.com/content/content/127309/reviews/office2007_beta2tr_11.jpg

        C'est marrant mais moi, je vois direct quand un powerpoint ou graphique est fait avec MSOffice ou OpenOffice. Dans les 2 cas l'utilisateur est le même et ne sait pas créer son thème.
        Mais sur MSOffice, le thème (fond, couleur, police) est par défaut classe, alors que sous OpenOffice, on se tape les couleurs de Win95.

        Si on me dit qu'Office ne met pas en avant les style, regardez office 2007 : http://www.microsoft.com/library/media/1033/office/images/preview/programs/excel/65494_800x577_charting2.jpg
        On peut changer de thème en 1 clic et ceux par défaut ont déja de la gueule.

        Si on pense que l'utilisateur ne comprend rien aux styles et qu'on ne veut pas lui pourrir l'interface, permettez au moins de switcher l'interface d'Openoffice entre 2 layout de l'interface. Une optimisée pour les adorateurs des styles avec juste de quoi changer de style le paragraphe en cours et l'autre comme aujourd'hui avec un trillion de boutons de formatage.

        Quand on insère une image dans Writer, la marge par rapport au texte vaut 0 dans le thème par défaut. Donc c'est inutilisable par défaut et il faut customizer.
        Dans Apple Page 9 , tu insères une image dans le texte, et en faisant un clic dessus, tu peux l'insérer "à droite" ou "à gauche" avec la marge qui s'applique dynamiquement pour n'exister que entre l'image et le texte et non tout autour de l'image afin de garder l'image alignée verticalement avec le texte sur le bord de la page.

    • [^] # Re: Styles et formatage

      Posté par . Évalué à 4.

      Le corps en sérif + les titres en sans sérif est une convention typographique américaine (d'avant l'informatisation des publications).

      Ça choque beaucoup en Europe il est vrai.

      C'est le genre de défaut insipide choisi par un informaticien comme bouche trou en attendant que quelqu'un dont c'est le métier corrige.

      Malheureusement il y a peu de graphistes pro dans le développement libre, et ce type d'applicatif a tellement de valeurs par défaut (souvent en dur, essayez de changer la police par défaut dans les styles) qu'il est difficile de les modifier à postériori.

      • [^] # Re: Styles et formatage

        Posté par . Évalué à 2.

        Calibri est sans serif hein. Pas sûr que ça résolve le problème de tout mettre en sans serif. C'est même plutôt l'inverse mais bon, personne n'en a rien à faire de la typographie en dehors du monde de l'édition. Les gens utilisent des polices avec et sans empattement d'une manière interchangeable, réduisent les marges au minimum gèrent la mise en forme arbitrairement à la main titre par titre, etc.

    • [^] # Re: Styles et formatage

      Posté par (page perso) . Évalué à 4. Dernière modification le 26/08/15 à 14:49.

      À propos des styles, je voulais juste mettre ça ici : la page de wiki de la Design Team de LibreOffice à propos de l'élaboration du (futur ?) modèle par défaut de document.

      Je constate que cette page cite l'excellent site de Matthew Butterick (du moins, l'ai-je trouvé très intéressant de mon point de vue de néophyte de la typographie), ce qui a tendance à me rassurer pour la suite :)

      (je constate également que les liens pour télécharger les modèles de la concurrence sont tous morts :( )

      • [^] # Re: Styles et formatage

        Posté par (page perso) . Évalué à 3.

        Je constate que cette page cite l'excellent site de Matthew Butterick

        Il l'est, mais à l'application il faut se rappeler que les typographies françaises et étatsuniennes sont différentes sur pas mal de points.

        La connaissance libre : https://zestedesavoir.com

        • [^] # Re: Styles et formatage

          Posté par . Évalué à 5.

          sur pas mal de points.

          Notamment sur les points-virgule et les points d'exclamation, n'est-ce pas ?

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

          • [^] # Re: Styles et formatage

            Posté par . Évalué à 0.

            Je ne résiste pas à la tentation, au risque de passer pour un pédant maniaque…

            Notamment sur les points-virgule et les points d'exclamation, n'est-ce pas ?
            Notamment sur les points-virgule et les points d'exclamation, n'est-ce pas ?

            Pourtant, linuxfr cherche visiblement à maintenir un bon niveau de typographie. La ligne citée a été corrigée grâce au bloc Caractères spéciaux à copier-coller, placé sous la zone de saisie.

            • [^] # Re: Styles et formatage

              Posté par (page perso) . Évalué à 1. Dernière modification le 26/08/15 à 20:11.

              Laisse-moi deviner : ta "correction", c'est l'insécable fine devant le point d'interrogation ?

              Sous LibreOffice, c'est Grammalecte qui m'aide à corriger ça sans devoir chercher une combinaison de touches que je ne retiens jamais. Mais sous Firefox, je me contente de l'espace ordinaire. Et à un ancien taf, on me demandait même de ne pas mettre d'espace du tout là où il était supposé avoir un insécable, sous prétexte que le backoffice ne saurait pas le gérer correctement…

            • [^] # Re: Styles et formatage

              Posté par (page perso) . Évalué à 0.

              Notamment sur les points-virgule et les points d'exclamation, n'est-ce pas ?

              Notamment sur les points-virgule et les points d’exclamation, n’est-ce pas ?

              Voilà ça pique moins les yeux (c’est encore plus flagrant en italique).

              ce commentaire est sous licence cc by 4 et précédentes

            • [^] # Re: Styles et formatage

              Posté par . Évalué à 3.

              Je ne résiste pas à la tentation, au risque de passer pour un pédant maniaque…

              Idem https://linuxfr.org/suivi

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

            • [^] # Re: Styles et formatage

              Posté par . Évalué à 2.

              Pourtant, linuxfr cherche visiblement à maintenir un bon niveau de typographie.

              Si Linuxfr cherchait vraiment à maintenir un bon niveau de typographie, il proposerait ces corrections automatiquement. Comme SPIP depuis seulement, heu… 15 ans, hein.

              • [^] # Re: Styles et formatage

                Posté par (page perso) . Évalué à 6.

                il proposerait ces corrections automatiquement

                C'est compliqué à mettre en place, par exemple, si l'utilisateur utilise une autre langue que le français (pour une citation par exemple) ou du code. En plus, certaines règles posent problème pour plusieurs support. Par exemple, sous Android (du moins quand la question s'est posée, c'est peut-être corrigée), l'espace fine insécable s'affichait avec un beau carré Unicode car le symbole n'était pas dans la police. Cela rendait la lecture compliquée.

                « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                • [^] # Re: Styles et formatage

                  Posté par . Évalué à 4.

                  sous Android (du moins quand la question s'est posée, c'est peut-être corrigée), l'espace fine insécable s'affichait avec un beau carré Unicode car le symbole n'était pas dans la police.

                  J’avais remarqué cela, en effet. Ce n’est pourtant pas un caractère très difficile à dessiner. :D

  • # LibreOffice Online c'est du SIG web !

    Posté par (page perso) . Évalué à 10.

    Hello,

    en lisant le diaporama de Collabora sur LibreOffice Online, je suis tombé de ma chaise en lisant que LibreOffice Online utilise la bibliothèque Javascript Leaflet (cf diapo 12).

    Pour votre information, Leaflet est très utilisée dans le monde de la cartographie en ligne pour afficher des cartes dynamiques. Par exemple, c'est cette bibliothèque qui est utilisée pour l'interface de navigation de la carte dynamique d'OpenStreetMap.

    Il est donc très curieux de retrouver ça dans la version Online de LibreOffice. Si j'ai bien compris le schéma d'architecture, le serveur LibreOffice génère des rendus sous forme de tuiles (comme dans un SIG quoi), à partir des documents ODF. Le navigateur du client utilise ensuite Leaflet pour afficher ces tuiles sauf qu'au lieu d'une carte, on a un document bureautique…

    C'est assez surprenant comme approche et je suis bien surpris du détournement d'une bibliothèque SIG pour une suite bureautique en ligne. Ma foi, si ça marche, pourquoi pas ?

    • [^] # Re: LibreOffice Online c'est du SIG web !

      Posté par (page perso) . Évalué à 10. Dernière modification le 26/08/15 à 12:50.

      Le rendu par tuile est en fait plus courant que tu ne le crois.

      Par exemple Firefox pour Android utilisait à ces débuts un système de tuilage pour afficher les pages web, à cause du manque de perf (pendant le scrolling entre autre). La page web était donc rendue dans une fenêtre non affichée (genre dans un element iframe), et un element html canvas était utilisé pour le rendu à l'utilisateur, en utilisant un système de tuiles générée à partir du rendu de la fenêtre cachée. Et donc tout ça fait en JS :-). (On pouvait parfois se rendre compte de ce système de tuiles, quand Gecko mettait trop de temps à afficher les tuiles : on voyait alors brièvement un damier à la place des tuiles retardataires)

      Maintenant, Gecko a un système de rendu par tuile en natif. Et malgré que le moteur de rendu de Gecko soit plus performant qu'à l'époque, le tuilage est toujours utilisé dans Firefox pour Android, et dans FirefoxOS pour afficher les pages web. (dans le about:config, preférence layers.enable-tiles). Toujours pour des questions de perfs.

      • [^] # Re: LibreOffice Online c'est du SIG web !

        Posté par (page perso) . Évalué à 8.

        Toujours pour des questions de perfs.

        Et j'ai oublié : aussi pour des questions de zooming. C'est rapide et simple. Sur les petits écrans, avoir un bon zooming est critique, et un système à tuile est très bien pour ça.

  • # Pb de LibreOffice

    Posté par . Évalué à -2.

    LibreOffice est très bonne suite bureautique mais possède plusieurs inconvénients:

    1/Problème lié au maj: le téléchargement de plusieurs centaine de mégas pour les majs de version peut poser problème en entreprise
    2/La mise en place des ruban Microsoft Office à innover avec la présentation en ruban et beaucoups de logiciels suivent
    3/La version de base de données qui ne sont pas encore au point par rapport à Access

    • [^] # Re: Pb de LibreOffice

      Posté par . Évalué à 6.

      Ça s'utilise encore, Access ? O_o

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

      • [^] # Re: Pb de LibreOffice

        Posté par . Évalué à -3.

        les gens comprennent quelque chose au ruban ? C'est nul, moche, peu ergonomique…

      • [^] # Re: Pb de LibreOffice

        Posté par (page perso) . Évalué à 6. Dernière modification le 26/08/15 à 16:51.

        3/La version de base de données qui ne sont pas encore au point par rapport à Access

        Ça s'utilise encore, Access ? O_o

        Oui, hélas ! Impossible de trouver un outil libre qui nous permettrait de créer des applications à diffuser auprès de ma profession. L'équipe à laquelle j'appartiens vient donc d'être distinguée par notre ministre, pour produire des logiciels libres (OK, promis bientôt il y aura une étiquette GPL dessus, je fais travailler les consciences), mais qui requièrent krosoft pour fonctionner. Argh !

        Donc à chaque sortie d'une nouvelle version de LO, je regarde fièvreusement le changelog, et à chaque fois, pour Base il n'y a rien, ou presque. Ouiiiiinnnnnn !

        Intendant, donc méchant, mais libre !

        • [^] # Re: Pb de LibreOffice

          Posté par . Évalué à 6.

          Tu ne peux pas payer pour avoir des fonctionnalités qui te manquent ? Genre tous les ans, un petit budget pour améliorer LibreOffice…

          • [^] # Re: Pb de LibreOffice

            Posté par (page perso) . Évalué à 8.

            Là franchement, ça me semble assez titanesque. Mais justement, comme on décroche un commencement de soutien de la part de l'Institution, on peut rêver que le ministère paie ou fasse développer par ses propres ressources. Je suis quand même pessimiste !

            Actuellement nous produisons des applications librement utilisables par des centaines de collègues (sous condition d'avoir MSO sur le poste de travail), et on fait cela sur notre temps personnel. Nos tentatives de faire la même chose avec LO tombent sur des blocages importants très tôt dans le processus de développement, c'est décourageant, tout comme l'absence de la plus petite évolution du module Base depuis longtemps maintenant.

            J'aimerais voir se lever l'intérêt de la communauté pour ce module Base, devant la perspective de généraliser pour de bon l'usage de LO dans les 8000 collèges et lycées du pays. Mais c'est le problème de la poule et de l'oeuf… Et les moyens qu'on peut y mettre actuellement, c'est du perso, et ça représente un bout de coquille, ou une demi-plume. Pas de quoi espérer changer la dynamique. Naturellement, si un enragé passait par là…

            Intendant, donc méchant, mais libre !

            • [^] # Re: Pb de LibreOffice

              Posté par . Évalué à 2.

              Tout seul effectivement c'est titanesque. Mais il y a pas mal d'utilisateur institutionnel de libreoffice en France ! Si chacun s'y met à sa mesure, le logiciel avancera doucement, mais plus sûrement que si on attend totalement l'aide d'un ministère.

              Typiquement dans mon labo de recherche je le fait sur certains logiciels, et j'envisage de le faire sur libreoffice d'ici quelques années. Après effectivement, ça dépend du contexte, et des sous disponible…

            • [^] # Re: Pb de LibreOffice

              Posté par . Évalué à 6.

              Je suis aussi très intrigué par le fait que Base n'a essentiellement pas bougé depuis l'époque de OpenOffice.org…

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

            • [^] # Re: Pb de LibreOffice

              Posté par . Évalué à 5. Dernière modification le 31/08/15 à 10:42.

              Il me semblait que les développeurs LO veulent supprimer la descendance à Java, ce qui veut dire changer la base de donnees de Base (HSQLDB) et la remplacer par un autre moteur. Il y avait un prototype basé sur Firebird.
              Tout ceci pourrait expliquer le manque d'investissement envers Base.

              Il faudrait confirmer tout ça avec des gens qui suivent plus attentivement le développement de LO.

    • [^] # Re: Pb de LibreOffice

      Posté par . Évalué à 6. Dernière modification le 26/08/15 à 13:16.

      1/Problème lié au maj: le téléchargement de plusieurs centaine de mégas pour les majs de version peut poser problème en entreprise

      Ce problème devrait être résolu dans un avenir pas trop lointain. Un étudiant du programme Google Summer of Code a bossé ces derniers mois sur la mise en place d’un système de mise à jour incrémentale basé sur celui de Mozilla. J’ai l’impression que ça a pas mal avancé.

      2/La mise en place des ruban Microsoft Office à innover avec la présentation en ruban et beaucoups de logiciels suivent

      Je doute qu’on voit une évolution sur ce chapitre avant longtemps. À l’époque de Sun Microsystems, en 2009 me semble-t-il, une étude sur la refonte de l’interface avait provoqué une véritable levée de boucliers parce que ça s’inspirait des rubans, et les dévs ont dû faire face à une “shitstorm”. Après ça, l’idée est passée aux oubliettes. Puis avec Oracle et le fork LO, l’idée est restée enterrée, même si la refonte de l’interface n’est pas abandonnée, comme vous avez pu le lire. Les rubans, ça divise vraiment les utilisateurs. Alors, les modifications se font par petites touches.

      • [^] # Re: Pb de LibreOffice

        Posté par (page perso) . Évalué à 8.

        avec les écran 16/9 et même 21/9, je trouve utilisation d'une barre latérale beaucoup plus pratique.

        www.solutions-norenda.com

  • # Abstraction du système de fichiers

    Posté par . Évalué à 4.

    Est ce qu'il y a un papier qui décrit cette expérimentation ? C'était sur du webdav ?

    Et longue vie à libreoffice.

  • # Typo

    Posté par . Évalué à 3.

    le rendu sans affichage et également utilisé

    je pense que c'est "est"

    kentoc'h mervel eget bezan saotred

  • # Menu contextuel réduit :(

    Posté par (page perso) . Évalué à 3.

    Je regrette beaucoup la disparition du menu contextuel pour le formatage des caractères :(

    Avant, c'était mieux (mieux que dans Microsoft Office) car il était possible de garder les mains sur le clavier et faire :
    - [menu-contextuel] → S (ou F) → E pour obtenir l'exposant
    - [menu-contextuel] → S (ou F) → B pour barrer
    - etc.

    S pour le sous-menu Style… à été remplacé plus tard par F pour le sous-menu Format… puis plus aucun sous-menu de ce genre :(

    C'était très pratique lorsqu'il fallait barrer plusieurs mots lors de la saisie, etc.

    Pourquoi ? pourquoi diable avoir supprimé cette merveilleuse possibilité ? :(

    Je vais donc devoir mettre à jour mes fiches : http://www.spaceeman.be/ftl/#ttexte

    Bien sûr que c'est le genre de fiches qu'il faut mettre à jour régulièrement…

    Mais là, je vais devoir expliquer que non, plus rien n'est dispo' dans le menu contextuel !

    'faudra lever votre main et prendre la souris ! :(

Suivre le flux des commentaires

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