LibreOffice 4.2.0 est disponible

94
3
fév.
2014
Bureautique

LibreOffice 4.2.0 vient d’être publié (le 30 janvier 2014). Cette nouvelle version est destinée aux utilisateurs expérimentés – les autres, comme les entreprises et les administrations sont invitées à utiliser LibreOffice 4.1.4 (publié le 18 décembre 2013).

Logo LibreOffice

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

Il vient de publier sur son blog une longue description du travail de refactorisation et de nettoyage qui a eu lieu lors du cycle menant à la version 4.2 de LibreOffice. Comme ce texte est fort intéressant et qu’il est placé dans le domaine public (et sous licence CC0, quand la législation locale interdit à un auteur d’opter pour le domaine public), il m’a semblé pertinent de traduire son billet.

Vous trouverez donc dans la suite de la dépêche une traduction du texte de Michael. Merci à tous les contributeurs de cette dépêche qui ont participé à cette traduction et à la relecture.

Sommaire

Nous publions aujourd’hui même LibreOffice 4.2.0, truffé de nouvelles fonctionnalités ! Vous pouvez bien sûr lire et profiter de toutes les fonctionnalités visibles pour les utilisateurs, fournies par nos nombreux contributeurs héroïques, mais il y a également des contributions dont l’effet se ressent principalement en coulisses, à des endroits pas forcément faciles à apprécier, et qui sont vitales pour le projet. Comme il peut être assez malaisé d’extraire celles-ci au milieu des 12 000 modifs depuis la séparation de la branche LibreOffice 4.1, laissez‐moi vous les détailler :

Interface utilisateur et boîtes de dialogue

La migration de l’interface utilisateur vers des fichiers XML au format Glade se poursuit activement avec des contributions multiples. Nous sommes parvenus à convertir 280 dialogues dans cette version, portant notre avancée globale à environ 70 %. Un grand merci à Caolán McNamara (Red Hat), Manal Alhassoun (KACST), Olivier Hallot (EDX), Faisal M. Al‐Otaibi (KACST), Laurent Balland‐Poirier, Efe Gürkan Yalaman, Krisztian Pinter, Jan Holesovsky (Collabora), Andras Timar (Collabora), Cao Cuong Ngo, Gergo Mocsi, Katarina Behrens, Abdulmajeed Ahmed (KACST) et Alia Almusaireae (KACST). Merci aussi à nos traducteurs qui ont aidé à la migration des chaînes de caractères.

Progression de la migration des modèles d’interface utilisateur

DLFP

Si vous souhaitez vous impliquer pour porter cet effort jusqu’à 100 %, reportez‐vous aux mises à jour et aux Howto de Caolán.

Améliorations de la chaîne de compilation

Dans cette version, nous avons beaucoup progressé en termes de facilité pour compiler le code source, et rendre le tout plus compréhensible — un point toujours important pour les nouveaux contributeurs.

Une chaîne de compilation et d’exécution drastiquement améliorée

Il y a 6 mois, nous avions annoncé la très bonne nouvelle d’une compilation entièrement fondée sur GNU make, plus rapide et plus agréable. Pour accentuer encore les bienfaits en 4.2, nous avons travaillé dur pour nous assurer que vous pouvez compiler et immédiatement exécuter LibreOffice sans — longue — phase intermédiaire d’installation. Nous compilons en direct un binaire exécutable dans instdir/, ainsi :

./autogen.sh
make
cd instdir/program
./soffice -writer

suffit pour avoir une suite pleinement fonctionnelle sous Windows, Mac OS X ou GNU/Linux. Ceci nous évite une tonne de Perl, nettoie une grande partie de scp2/ et permet de supprimer des étapes de configuration à l’installation. Merci à Michael Stahl (Red Hat), David Tardon (Red Hat), Matus Kukan (Collabora) et Marcos Paulo de Souza. C’est toujours amusant de voir des contributeurs et partenaires s’échanger des exécutables Windows au format instdir.zip.

Cerise sur le gâteau : nous avons également fait le ménage un peu partout des vieux sous‐répertoires spécifiques à la configuration de l’installation comme unxlngi6.pro ; si les gens ciblent plusieurs plates‐formes à partir du même source, il leur suffit de lancer ./configure depuis des répertoires différents. Merci à Michael Stahl (Red Hat), et Tor Lillqvist (Collabora).

Compilation individuelle des fichiers de localisation

Compiler le grand nombre de fichiers de localisation de LibreOffice crée une importante demande en temps de compilation (nous supportons plus de 100 langues nativement). Grâce à Bjoern Michaelsen (Canonical) nous pouvons à présent compiler séparément du paquet principal les fichiers de localisation. Cela aide les empaqueteurs des distributions GNU/Linux de nombreuses façons. Cette séparation diminue les besoins en espace disque sur la machine de compilation, besoins qui peuvent dépasser les 25 Gio pour chaque compilation publiable, ce qui est utile pour porter sur des architectures aux ressources plus limitées. Les compilations et les respins sont plus rapides. Avec les binaires de LibreOffice exécutables sur place dans instdir, nous pouvons également éviter d’utiliser les macros moisies scp2/ interprétées par Perl pour les empaqueter directement. Ce changement rend aussi plus simples les mises à jour liées aux correctifs de sécurité, sans avoir à recompiler des centaines de fichiers de localisation non modifiés. Nous nous réjouissons d’avance de voir les distributions GNU/Linux profiter de cela pour faciliter leur travail d’empaquetage et de maintenance.

Autodoc est mort, vive Doxygen !

Depuis de nombreuses années, une horrible version hackée de (…) mais maintenant, grâce à l’excellent travail de Michael Stahl (Red Hat) Doxygen a appris le UNO IDL de LibreOffice, et nous nous sommes débarrassés de cosv, udm et des modules haut niveau d’autodoc, bon débarras de 57 000 lignes de code. Merci aussi à ceux qui ont aidé à améliorer, nettoyer et « doxygéner » les commentaires du code, à savoir : Julien Nabet, Miklos Vajna (Collabora), Christian Lohmaier (TDF), Thorsten Behrens (SUSE), Stephan Bergmann (Red Hat) et Zolnai Tamas (Collabora). Vous pouvez lire la documentation générée pour l’API publique et l’API interne.

Travail sur la qualité du code

Un travail important a été fourni quant à la qualité du code, l’amélioration de sa maintenabilité et sa lisibilité : une autre salve de 80 modifs pour corriger des erreurs relevées par cppcheck a été envoyée par Julien Nabet, ainsi que le brouhaha quotidien pour compiler sans aucun avertissement de compilation avec les drapeaux de compilation -Werror -Wall -Wextra, et ce, sur toutes les plates‐formes, principalement grâce au travail de Tor Lillqvist (Collabora) et de Caolán McNamara (Red Hat).

Analyse statique de code via Coverity Scan

Nous avons beaucoup œuvré sur l’énorme quantité de résultats donnés par l’analyse faite par Coverity Scan. Selon les résultats du rapport sur LibreOffice, dans cette version seulement, il y eut 210 corrections (et bien plus encore de tickets clos). Merci à Caolán McNamara (Red Hat), Eike Rathke (Red Hat), Julien Nabet, Norbert Thiebaud, Andrzej Hunt (Collabora), Markus Mohrhard (Collabora) et Gergo Mocsi.

Tests d’importation et d’exportation

Grâce au travail de Markus Mohrhard nous disposons d’un outil permettant de tester l’importation de fichiers corrompus afin de provoquer des crashs. Il teste maintenant plus de 45 000 documents problématiques issus des remontées de bogues sur tous les projets sur lesquels on peut mettre la main. Nous les testons un par un avec un binaire suractivé en assertions et informations de débogage en tout genre. Depuis peu, nous avons également commencé à exporter ces documents dans plusieurs formats de sortie, de manière à identifier des problèmes, en exécutant également toute une batterie d’outils de validation. Dans la durée, tout ceci impacte positivement la qualité. La sortie est consignée par git hash.

Maîtrise des fuites via Valgrind

Valgrind demeure un outil merveilleux pour dénicher et isoler les fuites [NdT : de mémoire] et les comportements erratiques de diverses sections du code. Merci à Mark Wielaard d’avoir colmaté nombre de fuites et résolu divers problèmes relatifs, de même que de nombreux autres problèmes récurrents.

Tests unitaires

Nous avons également complété et exécuté plus de tests avec LibreOffice 4.2 pour éviter des régressions en changeant le code. Ces ajouts sont assez difficiles à évaluer dans la mesure ou les gens aiment bien empiler les nouveaux tests au sein de modules de tests existants. Une estimation naïve est de rechercher la macro CPPUNIT_TEST(), qui montre que nous avons ajouté 216 de ceux‐ci depuis la 4.1, mais nous avons également ajouté plus de CPPUNIT_ASSERT par test, soit plus de 2 160. L’idéal serait que chaque bogue corrigé donne lieu à un test unitaire associé pour l’empêcher de revenir à jamais. Avec plus de 80 contributeurs à ces tests pour la 4.2, c’est assez difficile de citer tout le monde ici, mais je dois dire que c’est formidable d’avoir une culture de tests systématique et bien ancrée, liée aux corrections de bogues.

Nombre de tests unitaires et de vérifications

DLFP

Assurance qualité

Pour cette version, l’équipe d’assurance qualité s’est agrandie et a accompli un travail remarquable pour tirer et clore les bogues. Merci à Bjoern Michaelsen (Canonical), Robinson Tryon et Joel Madero d’avoir effectué un bon travail ici, et aussi particulièrement à nos meilleurs correcteurs de bogues. Il y a une longue liste de personnes qui répondent aux bogues.

Une métrique que nous suivons est de regarder qui est dans le top 10 du résumé hebdomadaire des bogues centralisé sur freedesktop.org. Il contient une liste des 20 personnes qui apparaissent le plus souvent au palmarès des correcteurs de bogues. Merci à eux : tommy27, Caolán McNamara (Red Hat), Maxim, Jean‐Baptiste Faure, Eike Rathke (Red Hat), ign_christian, Foss, Urmas, Joel Madero, Cor Nouws, Julien Nabet, Michael Stahl (Red Hat), Maxim Monastirsky, Jorendc, Andras Timar (Collabora), Lionel Élie Mamane, Kohei Yoshida (Collabora), mariosv, bfoman, Thomas Arnhold, Adolfo Jayme (fitoschido), Sophie (TDF), Samuel M., Markus Mohrhard (Collabora) et Rob Snelders.

Pour en savoir plus sur les bogues et leurs statistiques, vous pouvez consulter le blog de Bjoern (avec des chats). Pour résumer, on peut dire que des milliers de bogues ont été traités.

  • L’équipe de l’assurance qualité trie les nouveaux bogues, teste et confirme que les bogues sont reproductibles, en fournissant les infos nécessaires. Elle s’efforce de maintenir le flot de bogues non triés aussi bas que possible. Il est très simple de participer et d’aider à cela ici.
  • À chaque cycle de version, elle trouve et étiquette environ un millier de bogues en doublon.
  • À chaque cycle de version, elle clôt et invalide environ un millier de bogues (pour diverses raisons, comme l’absence de réponse du demandeur pendant des mois).
  • À chaque cycle de version (environ 6 mois), les développeurs corrigent environ un millier de bogues.
  • À chaque cycle, le nombre de nouveaux bogues croît un peu, mais cette croissance diminue. En ce moment, nous avons environ 25 000 bogues, dont 6 500 sont nouveaux et 800 non confirmés. Par ailleurs, environ 25 % des bogues sont des demandes de nouvelles fonctionnalités, ce à quoi il n’y a vraisemblablement pas de fin.
  • Concernant les bogues les plus fâcheux [NdT : crashs et dysfonctionnements majeurs] et les régressions, la tendance est plate, tandis que le nombre de corrections sur ces deux points croît rapidement.

Nettoyage du code

Le code crade doit être éradiqué et, sur ce chapitre, nous n’avons pas chômé.

La mort définitive d’UniString

Le plus gros changement dans la 4.2, en gestation depuis les tout débuts du projet LibreOffice, consiste à supprimer nos différents types de chaînes de caractères, obsolètes, nous laissant ainsi avec seulement 2 types de chaînes, l’une pour toutes les chaînes à 8 bits d’encodage, et l’autre pour toutes les chaînes en UTF-16. Le dernier commit a détruit ce monstre une bonne fois pour toutes. Bien sûr, de très nombreuses personnes ont contribué à cette tâche et au nettoyage afférent depuis maintenant plusieurs années ; dans cette version, 30 personnes environ y ont participé. Merci en particulier à Noël Grandin d’avoir mené l’offensive, mais aussi à tous les autres : Matteo Casalin, Caolán McNamara (Red Hat), Stephan Bergmann (Red Hat), Ivan Timofeev, Michael Stahl (Red Hat), Thomas Arnhold, Kohei Yoshida (Collabora), Eike Rathke (Red Hat), Tor Lillqvist (Collabora), Palenik Mihály, Markus Mohrhard (Collabora), Luboš Luňák (SUSE), Máté Gergely, Andrzej J.R. Hunt (Collabora), Christina Rossmanith, Laurent Balland‐Poirier, Julien Nabet, Sean Young, Neil Moore, Jelle van der Waa, Donizete Waterkemper et Arnaud Versini.

Enfin, nous aurons pour la version 4.3 les premiers bénéfices visibles de ce travail, qui permettra d’écrire des paragraphes plus longs que 65 000 caractères. Allez voir notre page Wiki en construction des fonctionnalités de la 4.3 et l’article de blog associé. Par ailleurs, en corrigeant récemment un bogue, j’ai trouvé assez intéressant le bourbier des types de chaînes de caractères sur la plate‐forme Windows.

Une API de gestion des fichiers temporaires en moins

Nous avons un nombre certain d’API hétérogènes pour gérer les fichiers temporaires, de la plus vieille à la plus emberlificotée… tools/tempfile.hxx fut gentiment codé par Palenik Mihály. Dans l’idéal, il y aurait un seul endroit sécurisé dans le répertoire sal/ où les fichiers temporaires seraient gérés.

Traduction des commentaires allemands

Nous avons continué à progresser du côté de la traduction des derniers commentaires restant encore en allemand, pour les remplacer par des commentaires techniques en anglais précis. Remerciements à Philipp Weissenbacher, Philipp Riemer, Laurent Balland‐Poirier, Rolf Hemmerling, Chris Hoppe, Rodolfo Ribeiro Gomes, Matthias Freund et Henning Diedler. Je suspecte que l’effet de traînée dans les chiffres est en partie dû à des faux positifs, conséquence de notre outil de type find qui devine la langue des commentaires.

Commentaires allemands restant à traduire

DLFP

Suppression du code mort grâce aux avertissements du compilateur

Beaucoup de code mort a été identifié et supprimé grâce à de récentes améliorations dans les avertissements de compilation Clang / GCC (-Wunsued-function, -Wunused-variable, -Wunused-private-field, etc.) et via l’utilisation de SAL_WARN_UNUSED. (Caolán McNamara (Red Hat), Luboš Luňák (SUSE), Stephan Bergmann (Red Hat), Tor Lillqvist (Collabora)).

Compilation sous Windows et symboles de déboguage

Le temps de compilation sous Windows a été réduit de 10 minutes, soit 10 % environ, grâce au travail de Bjoern Michaelsen (Canonical), pour ensuite immédiatement augmenter à nouveau, du fait de l’ajout d’optimisations au moment de l’édition de liens à destination des nouveaux compilateurs Microsoft.

Une autre fonctionnalité souvent demandée, qui permet aux utilisateurs de fournir des traces de qualité lors des crashs et gels de l’application, et permet ainsi de corriger les bogues plus rapidement, est l’utilisation du serveur de symboles Windows de Cloph. Renseignez‐vous sur la méthode pour générer une backtrace , c’est un excellent moyen pour les utilisateurs d’améliorer la qualité des bogues remontés sur cette plate‐forme. Merci à Fridrich Štrba (SUSE), Luboš Luňák (SUSE), et Christian Lohmaier (TDF).

Refonte du cœur de Calc

Il y a beaucoup à dire sur ce point. Le détail des changements sera exposé prochainement lors du FOSDEM. Qu’il suffise de dire que le moteur de Calc a été refondu massivement, améliorant l’utilisation de la mémoire, les performances dans de nombreux cas, permettant l’usage d’OpenCL pour calculer certaines formules via le processeur graphique, et plus encore. Mille mercis à Kohei Yoshida (Collabora), Markus Mohrhard (Collabora), et à l’équipe de MultiCoreWare : I‐Jui (Ray) Sung, Hao Chen, Shiming Zhang, Yiming Ju, Yang Zhang, Hongu Zhong, Ming Li, Min Wang, De Chuang, Feng Zheng, mulei, Xin Jiang, Zhenyu Yuan et les autres.

S’impliquer dans LibreOffice

J’espère que vous comprendrez que de plus en plus de développeurs trouvent une nouvelle maison à LibreOffice et travaillent de concert pour accomplir un tâche significative à la fois sous le capot et en surface. Si vous voulez vous impliquer, il y a beaucoup de gens formidables à connaître et avec qui travailler. Comme vous pouvez le constater, les individus peuvent avoir un impact considérable parmi la diversité des contributeurs à LibreOffice (la légende colorée à droite doit être lue de gauche à droite, de haut en bas, et correspond aux couleurs de haut en bas sur le schéma). NdT : le schéma est peu clair, mais je pense que la grosse zone rouge apparue à la naissance de LibreOffice correspond aux individus sans affiliation connue.

Développeurs actifs par mois par affiliation

DLFP

De même, si l’on regarde la diversité des contributeurs du code, c’est très plaisant de voir autant de contributions de volontaires non affiliés [NdT : à une compagnie], même si clairement cette composante varie selon les saisons, les cycles de versions et notre temps de mentorat disponible :

Commits mensuels par affiliation

DLFP

Bien sûr, nous maintenons une liste de bogues et de tâches réputées faciles, dont vous pouvez vous saisir pour commencer à contribuer. Notre page « Easy hacks » est là pour ça, avec des instructions simples pour compiler et configurer le code. Nous avons maintenant un environnement plus propre et plus sain pour travailler à l’amélioration du code. À titre d’illustration, cette vidéo montre à quel point il est simple de se lancer dans le développement de LibreOffice aujourd’hui. Il est aussi encourageant de voir comment les « easy hacks » progressent. Arriverez‐vous à clore le 400e ?

NdT : les _« easy hacks » sont des tâches simples offertes aux nouveaux contributeurs pour les aider à mettre le pied à l’étrier dans le code de LibreOffice, et même certaines tâches ne requièrent pas de savoir coder. Ça libère du temps pour les développeurs confirmés et c’est indispensable pour la clarification et le nettoyage du code. Par exemple : supprimer du code mort, traduire les commentaires en allemand, réécrire des bouts de code, des types, des méthodes obsolètes, virer des vieilles macros inutiles.

Progrès concernant la résolution des « easy hacks »

DLFP

Une autre chose aide réellement : faire tourner les pré‐versions et signaler les bogues. Il suffit de récupérer et d’installer une pré-version et vous êtes prêt à contribuer avec le reste de l’équipe de développement.

Conclusion

LibreOffice 4.2 est la suite d’une série de versions qui améliorent non seulement les fonctionnalités, mais aussi les fondations de la suite bureautique libre. Bien sûr, c’est seulement le premier d’une longue série de parutions 4.2.x mensuelles qui vont apporter une série de corrections de bogues et d’améliorations de la qualité durant les prochains mois.

J’espère que vous aimez LibreOffice 4.2.0, merci pour la lecture et merci de supporter LibreOffice.

  • # LibO

    Posté par . Évalué à 3.

    Félicitations !

    Dans le paragraphe « La mort définitive de UniString » le lien derrière « commit » n'est pas bon.

    Dans les graphes « Développeurs actifs par mois par affiliation » et « Commits mensuels par affiliation », les couleurs ne sont pas super bien choisies, on distingue mal certains groupes.

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

    • [^] # Re: LibO

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

      Bien vu! Je me suis probablement mis dedans en le recopiant.

      Le lien est le suivant : commit

      Quant aux graphes, ben ce sont les originaux !

      Sed fugit interea, fugit inreparabile tempus, singula dum capti circumvectamur amore

    • [^] # Re: LibO

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

      J'ai corrigé le lien.

      • [^] # Mots manquants

        Posté par . Évalué à 4.

        Merci pour la traduction.

        Pendant qu'on y est, je crois qu'il y a des mots qui manquent ici :

        Depuis de nombreuses années, une horrible version hackée de … mais maintenant

        Saurez-vous deviner lesquels ?…

  • # Bravo, mais il y a quand même quelque chose qui me gène dans ce billet ...

    Posté par . Évalué à 8.

    … c'est le dénigrement du code qui a été modifié.

    Le code est peut-âtre moche, mais il a fait son boulot plus ou moins bien pendant des années. D'autre part, si ma mémoire est bonne, à une époque, Perl était employé pour combler le manque de certains outils qui aujourd'hui peuvent remplacer ces outils faits maison. Un peu moins de dénigrement aurait été bienvenu et plus élégant. Là ça fait un peu trop "on est les meilleurs du monde, les autres codent comme des pieds". A l'époque ou le code a été écrit et avec les outils dispo, ils n'auraient probablement pas fait mieux.

    • [^] # Re: Bravo, mais il y a quand même quelque chose qui me gène dans ce billet ...

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

      il y a quand même quelque chose qui me gène dans ce billet…c'est le dénigrement du code qui a été modifié.

      Bon d'abord il faut voir que l'article de Michael n'est pas une liste des nouveautés de LibreOffice 4.2.
      Le lien vers les vrais Release Notes a été mis dans la dépêche mais ici ce n'est pas vraiment l'objet. Dans cet article Michael parle plutôt du travail invisible (compilation, tests, etc) et de la santé du projet (contributions). Il est donc légitime qu'il évoque les améliorations de la qualité du code. A mon sens ce n'est pas du dénigrement mais la volonté de mettre en avant le travail de ceux qui se consacrent à une tâche peu visible mais cruciale pour l'avenir du projet.

      Le code est peut-âtre moche, mais il a fait son boulot plus ou moins bien pendant des années.

      Bien entendu…mais c'est bien aussi de nettoyer une base de code qui est vieille en même temps qu'on ajoute de nouvelles fonctions.

      • [^] # Re: Bravo, mais il y a quand même quelque chose qui me gène dans ce billet ...

        Posté par . Évalué à 10.

        Bien entendu…mais c'est bien aussi de nettoyer une base de code qui est vieille en même temps qu'on ajoute de nouvelles fonctions.

        Je ne parle pas du fond et du travail de nettoyage accompli, que j'ai très bien compris. J'en profite d'ailleurs pour remercier les développeurs actuels qui font un travail immense pour nettoyer le code ancien et améliorer la stabilité et l'efficaci²t²é de la suite bureautique. Par contre sur la forme ça me gène. Après il y a peut-être un effet "traductuion" qui retranscrit mal les expressions utilisées à l'origine.Je pense juste qu'un nettoyage de code, aussi moche soit-il sur un projet aussi ancien, peut s'éviter d'employer certaines expressions. Personellement, en tant qu'utilisateur depuis déjà quelques années, je remercie les développeurs qui ont pondu ce code horrible pour une suite bureautique que j'utilise depuis un bon moment déjà et qui a très bien fait son boulot. Ca me gène qu'on parle de ce code de cette façon.

    • [^] # Re: Bravo, mais il y a quand même quelque chose qui me gène dans ce billet ...

      Posté par . Évalué à 3.

      C'est toujours le même refrain dans tous les projets…
      "au bout de X années on nettoie et on supprime du code parce que les branquignoles d'avant on fait ça à la rache"

    • [^] # Re: Bravo, mais il y a quand même quelque chose qui me gène dans ce billet ...

      Posté par . Évalué à 9.

      Sur ce point précis, je trouve au contraire qu'il ne dénigre pas. On ne sait pas pourquoi cela a été écrit en Perl, mais juste qu'un effort a été fait pour que la chaine de compilation soit plus simple.

      Par contre, les tests unitaires que les contributeurs redéveloppent, la traduction des commentaires en allemand, les fix de fuite mémoire, les outils d'analyse statique qui ne passaient pas..

      Oui tout ca donne l'impression que OOo était codé avec les pieds, mais trouves tu normal que LibO, en tant que fork, ait du passer 3 versions a nettoyer tout ca avant de pouvoir vraiment se mettre au travail sur de nouvelles choses ?

      • [^] # Re: Bravo, mais il y a quand même quelque chose qui me gène dans ce billet ...

        Posté par . Évalué à 3.

        Je cite :

        nous pouvons également éviter d'utiliser les macros moisies scp2/ interprétées par Perl pour les empaqueter directement.

        Je t'accorde que ce n'est pas Perl qui est directement visé mais les macros scp2. Mas qu'y avait-iil d'autre de mieux à l'époque ?

        Depuis de nombreuses années, une horrible version hackée de … mais maintenant, grâce à l'excellent travail de Michael Stahl (Red Hat) doxygen a appris le UNO IDL de LibreOffice et nous nous sommes débarrassé de cosv, udm et des modules haut niveau d'autodoc, bon débarras de 57k lignes de code.

        Je trouve le ton un peu méprisant, mais là c'est peut-être du au passage précédent qui a donné le ton. S'il n'y avait eu que ça je n'aurais peut-être pas prêté attention.

        Le dernier commit a détruit ce monstre une bonne fois pour toutes.

        Personnellement, si j'étais développeur, ça neme donnerait pas envie de participer …. MAintenant, après relecture, je me rends compte que s'inl n'y avait pas le fameux "macros moisies" du début, le reste serait peut-être mieux passé : le "monstre" peut être interprêté comme "horrible" ou comme "énorme", et le "bon débarras" peut être interprêté comme "enfin une tache énorme de terminée" ou comme "enfin débarassé de ce code pourri". Mais pour moi le "code moisi" a donné le ton et influencé ma lecture.

        • [^] # Re: Bravo, mais il y a quand même quelque chose qui me gène dans ce billet ...

          Posté par . Évalué à 10.

          L'auteur original a utilisé le mot "crufty" qui a le sens suivant :
          Crufty:
          - Relating to or containing cruft
          - Poorly built and overly-complex, and unpleasant.

          Cruft:
          - Anything old or of inferior quality
          - Redundant, old or improperly written code, especially that which accumulates over time; clutter.

          Le terme est donc très bien utilisé, c'est exactement ce dont il sagit : un vieux code qui s'est accumulé et qui est de qualité moindre et trop complexe.

          La traduction n'est pas très heureuse.

        • [^] # Re: Bravo, mais il y a quand même quelque chose qui me gène dans ce billet ...

          Posté par . Évalué à 5.

          C'est peut-être l'effet traduction. Le terme traduit par "moisi" est "crufty". Un mot que je n'avais jamais lu avant aujourd'hui et qui semble intraduisible.

          http://www.urbandictionary.com/define.php?term=crufty
          https://en.wikipedia.org/wiki/Cruft

          Ça me semble moins péjoratif que "moisi" même si ça l'est pas mal.

          • [^] # Re: Bravo, mais il y a quand même quelque chose qui me gène dans ce billet ...

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

            Je trouve justement que c'est fort bien choisi. Et je maintiens ma traduction, même si je l'ai faîte un peu tongue-in-cheek. L'image est bien celle de « vieux code perdu », un peu comme des vieilleries dans une cave.
            J'ajoute que rien dans le texte originel n'est écrit avec des pincettes ; ce qui me conforte dans mon choix.
            En sus, il y a eu plusieurs relectures et aucun des contributeurs n'a râlé.

            Sed fugit interea, fugit inreparabile tempus, singula dum capti circumvectamur amore

        • [^] # Re: Bravo, mais il y a quand même quelque chose qui me gène dans ce billet ...

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

          Depuis de nombreuses années, une horrible version hackée de … mais maintenant, grâce à l'excellent travail de Michael Stahl (Red Hat) doxygen a appris le UNO IDL de LibreOffice et nous nous sommes débarrassé de cosv, udm et des modules haut niveau d'autodoc, bon débarras de 57k lignes de code.

          Je trouve le ton un peu méprisant, mais là c'est peut-être du au passage précédent qui a donné le ton. S'il n'y avait eu que ça je n'aurais peut-être pas prêté attention.

          57_000 lignes de code!!

          Remarque générale: on ne blâme le projet d’avoir plein de code sale, on a tous fait du code sale pour que ça marche qu’on a oublié de refaire proprement ou qu’on a eu la flemme de le refaire proprement.

          Écrit en Bépo selon l’orthographe de 1990

        • [^] # Re: Bravo, mais il y a quand même quelque chose qui me gène dans ce billet ...

          Posté par . Évalué à 6.

          J'ai lu la version anglaise et je n'ai pas senti ce denigrement dont tu parles.

          On peut dire que le code a vieilli ou bien qu'il etait lourd sans pour autant jeter le bebe avec l'eau du bain.
          Parfois le code est ecrit salement des le debut, le developeur le sait lui meme, mais des contraintes externes font qu'il ne puisse pas faire mieux dans le temps imparti.

          Oui le code a fait le boulot pendant quelques annees, c'est toujours le cas du code legacy, mais on peut et doit pouvoir le critiquer objectivement et surtout l'ameliorer. C'est la vie de tous projet logiciel.
          Contrairement a ce que tu dis, voir une telle activite de nettoyage me donne envie de contribuer car je sais que tout est fait pour rendre le travail sur cette base de code beaucoup plus agreable en supprimant/reecrivant les parties problematiques. Cela me semble tres sain.

          Le "monstre" ici, c'est pour "enorme". La tache a ete tres longue car ces classes etaient utilisees partout.
          L'utilisation du mo "moisi" dans la traduction est beaucoup trop fort a mon gout et ne traduit pas les mots/le ton de l'auteur original.

          • [^] # Re: Bravo, mais il y a quand même quelque chose qui me gène dans ce billet ...

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

            J'avais fait (avec la collaboration de quelques personnes) un assez gros logiciel en 1980. Il a été largement refondu en passant sous Unix en 1990. Je l'ai ensuite maintenu pendant 12 ans : j'ai réécrit plus de la moitié du code et travaillé sur la documentation. Le logiciel sert toujours.

            J'ai eu le plaisir de rencontrer celui qui maintient le code actuellement. Nous sommes d'accord pour dire qu'il faudrait le refaire avec des outils plus modernes que ceux dont je disposais à l'époque où les logiciels libres étaient au berceau et internet n'existait pas. Je disposais d'un compilateur Fortran et d'un logiciel de gestion de base de données. Il a tout fallu faire depuis les fonctions de lecture des terminaux à la gestion des versions.

            Le monde à évolué, on est passé de terminaux en mode texte à des PC en mode graphique, il a fallu faire des sorties en HTML, les imprimantes à impact sont remplacées par des lasers… Bref, le monde change et le logiciel doit s'adapter bien que sa fonction reste la même.
            C'est pour cela que je comprends très bien le travail en cours sur LO. Refaire et améliorer le code, même quand on l'a écrit quelques années plus tôt est normal et indispensable. Si on le le fait pas, le logiciel meurt.

            J'ai eu un chef de département qui me demandait quand le code serait fini. Je lui ai répondu : jamais ! Il est entré en furie, car pour lui (c'était un mécanicien), quand une pièce était finie, elle était finie, on n'y touchait plus.
            Le gros problème actuel est que les dirigeants des entreprises visent la rentabilité à court terme et qu'un logiciel métier ne peut pas être géré sur le court terme.

            • [^] # Re: Bravo, mais il y a quand même quelque chose qui me gène dans ce billet ...

              Posté par . Évalué à 8.

              J'aime ce genre d'annecdote. Ca prouve plus ou moins ce que je disais par ailleurs : un code crade aujourd'hui a probablement été écrit de façon crade non pas pour le plaisir d'écrire du code crade, mais par mla nécessité bien souvent d'avoirr un truc qui marche avec les moyens du moment. Si on cherche à écrire du code pour avoir du beau code, on peut se retrouver avec un truc qui ne marchera jamais, car jamais assez beau du point de vue du code, ou un truc lent comme pas possible parce que le code rès bien écrit n'est pas optimal, ou parce qu'une nouvelle techno est sortie, rendant le code obsolète. Et c'est pour ça que le terme "moisi" me gène. Quelque chose de moisi, c'est quelque chose qui dépérit non pas par rapport au fait que ce qui est autour s'améliore, mais par un effet de décomposition dui à un organisma "parasite" qui pourrit le code. Le code "pas beau" il faut le refaire quand il faut, je n'ai pas de problème avec ça, bien au contraire. Mais quand on parle de l'ancien code il faut se remettre dans le contexte de l'écriture de celui-ci. Un détail : je ne savais pas que la personne qui a écrit le billet d'origine fait partie des développeurs du début et je n'avais pas en vue ce côté "auto-dérision" que quelqu'un a mentionné : ca relativise un peu les propos (bien que pour moi, moisi reste un terme inadapté, mais ce n'est que mon avis … ).

      • [^] # Re: Bravo, mais il y a quand même quelque chose qui me gène dans ce billet ...

        Posté par . Évalué à 10.

        Oui tout ca donne l'impression que OOo était codé avec les pieds, mais trouves tu normal que LibO, en tant que fork, ait du passer 3 versions a nettoyer tout ca avant de pouvoir vraiment se mettre au travail sur de nouvelles choses ?

        Ca ne me choque pas, il faut savoir qu'OpenOffice est un très vieux projet et traîne du code développé à une autre époque, avec d'autres outils et dans d'autres circonstances. LA page wikipédia d'OpenOffice indique que "Star Division, une entreprise allemande fondée au milieu des années 1980 publie les versions successives de sa suite bureautique multiplateforme et multilingue StarOffice, jusqu’à sa version 5.1 en 1999, année de son acquisition par la société Sun Microsystems." Ce n'est pas tout jeune ça. Et le fait qu'il y aît encore de nombreux commentaires en allemand tendrait à prouver que les restes de codes de l'époque sont encore nombreux. Certes il faut le supprimer, mais pas le dénigrer.

        Dénigrer un projet nouveau qui partirait sur les mêmes bases me paraîtrait logique. Par contre prendre un code existant, écrit à une époque ou certaines "bonnes pratiques" n'étaient pas forcément mises en avant, sur du matériel moins performant (certains bout de code ont peut-être été mal écrits pour ne pas perdre trop de perfs), et le dénigrer me paraît malsain.

    • [^] # Re: Bravo, mais il y a quand même quelque chose qui me gène dans ce billet ...

      Posté par . Évalué à 3.

      Je pense que tu as ce ressenti parce que la dépêche est compacte. Il parle des améliorations évidement qu'il décrit ce qui n'allait pas avant et qu'est ce qu'ils ont fait pour que ça s'améliore. Le fait de lister ça sur pas mal de paragraphes relativement petits peut donner l'impression d'un exutoire, mais je ne crois pas que ce soit le cas. Il décrit juste leur boulot. Sinon on pourrait faire la même remarque pour les dépêches du noyau quand elle parle d'améliorer l'existant (et pas d'ajout pur et simple de fonctionnalité).

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

    • [^] # Re: Bravo, mais il y a quand même quelque chose qui me gène dans ce billet ...

      Posté par . Évalué à 0.

      Hum, accumuler des solutions sous-optimales pendant des années est un problème: ça finit par "c'est in-maintenable, on réécrit tout du début", je trouve que les blogs de Michael Meeks montrent qu'on peut retravailler en profondeur un logiciel pour l’améliorer même quand il était dans un état lamentable.

      Déjà les commentaires en Allemands… Ça, ça mérite d'être dénigré!

      Et tu marques "A l'époque ou le code a été écrit et avec les outils dispo, ils n'auraient probablement pas fait mieux.", c'est faux, il y a plusieurs styles de développement:
      -on utilise les outils dispo et on contourne leurs problèmes dans notre code.
      -on corrige les outils dispo s'ils ont des problèmes et on a du code propre.

      Et puis il y a des développeurs meilleur que d'autre, cf la conception pas très heureuse de Calc..

      • [^] # Re: Bravo, mais il y a quand même quelque chose qui me gène dans ce billet ...

        Posté par . Évalué à 7.

        -on corrige les outils dispo s'ils ont des problèmes et on a du code propre

        Encore faut-il avoir la possibilité de corriger lesdits outils. Staroffice n'était pas libre à l'époque et rien n'indique qu'ils avaient la maitrise des outils utilisés pourle développer. Enfin, il faut également avoir le temps, et s'il faut passer autant de temps, voire plus à développer un outil pour pouvoir ensuite l'utiliser et développer le projet final n'est pas forcément rentable, si on fait le ratio temps passé/temps gagné.

        Tout ce travail aurait pu être fait à l'époque ou OpenOffice a été libéré par Sun, je te l'accorde. Mais là encore il y a une question d'objectifs à prendre en considération, par rapport au nombre de contributeurs disponibles. . Que voulait l'utilisateur à cette époque ? Du code propre, avec moins de fonctionnalités pendant le nettoyage du code, ou plus de fonctionnalités ? Choix difficile à faire.

      • [^] # Commentaire supprimé

        Posté par . Évalué à 9.

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

    • [^] # Re: Bravo, mais il y a quand même quelque chose qui me gène dans ce billet ...

      Posté par . Évalué à 10. Dernière modification le 03/02/14 à 16:07.

      c'est le dénigrement du code qui a été modifié.

      Le code faisait son boulot, mais c’était une accumulation de code divers, de couches et de surcouches de modifications diverses, si bien que c’était difficile de s’y retrouver.

      D’après un dév qui m’avait parlé du code lors de la création de LibreOffice, c’était vraiment triste à voir, un bordel sans nom. Il y avait 6 ou 7 types de chaînes (contre 2 aujourd’hui). Des millions de lignes de code inutiles ont été supprimées. L’outil de build dmake était tellement vieux et obsolète qu’il utilisait la licence GPL 1. Il y avait des macros un peu partout. Compiler OpenOffice était compliqué, long et piégeux. Trois ans après, le nettoyage n’est toujours pas fini, tellement la dette technique est énorme, mais ils en viennent peu à peu à bout.

      Le problème, ce n’était pas l’incompétence (le code est quand même sacrément pointu), mais le manque de gens pour mettre le code à jour et l’accumulation des vieux bidules qui ne servaient plus et encombraient.

      Pour comparaison, OpenOffice contient 10 millions de lignes de code en C++ contre 5 millions pour LibreOffice, qui fait pourtant plus de choses.

      http://www.ohloh.net/p/libreoffice/analyses/latest/languages_summary
      http://www.ohloh.net/p/openoffice/analyses/latest/languages_summary

      Une présentation de Michael Meeks datent de début 2013 sur le nettoyage de code:
      https://people.gnome.org/~michael/data/2013-02-03-re-factoring.pdf

      Et plus encore:
      https://people.gnome.org/~michael/blog/2012-01-09-unused.html

    • [^] # Re: Bravo, mais il y a quand même quelque chose qui me gène dans ce billet ...

      Posté par . Évalué à 10.

      Si cela peut atténuer le ton du billet, plusieurs des développeurs à l'origine de StarDivision et Sun sont actuellement des développeurs de LibreOffice, soit chez RedHat, soit chez Collabora ou encore Canonical. Et même Michael a participé en son temps à ce code, donc c'est plutôt de l'autodérision tout autant que du plaisir de pouvoir faire progresser le code. C'est dur, cela demande du temps, il faut modifier les repository, les systèmes de build, le code, etc… tout en mettant à dispo des versions stables.À chaque pas on se dit : ouf, celui-là est franchi sans trop de casse, hourra :) and to the next ;) - Sophie

      • [^] # Re: Bravo, mais il y a quand même quelque chose qui me gène dans ce billet ...

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

        Pour avoir traduit une grosse partie de la news, je crois que globalement le ton de l'article initial est respecté. Après on peut toujours discuter un mot en particulier. Pour moisi ce serait facile ce n'est pas moi qui l'ait traduit ! Eggman, à bon entendeur. Il y a un peu d'emphase du type "Les gars ce que vous faites en coulisse c'est top", avec la citation systématique des contributeurs de chaque partie contribuée, mais c'est surtout - il me semble - pour valoriser je pense un travail qui peut être ingrat, et en tous les cas pas toujours suffisamment salué. Un peu genre les bénévoles qui travaillent dans l'ombre tous les week-end, et seul le président de l'association serre la main du Mairie une fois par an. Et bien cette année le président de l'association a cité les bénévoles et les a fait monter sur scène s'ils sont présents…

        Ensuite objectivement il y a une démarche, même si elle n'est jamais citée, qui est d'abaisser le plus possible la barrière à l'entrée pour les nouveaux contributeurs. Et dans ce cadre, une procédure d'installation et de configuration la plus simple possible, avec le minimum de dépendances, qui sont parfois casse pieds genre Perl ou autre, à maintenir sur toutes les distributions majeures, c'est un énorme avantage. Tous les projets qui élargissent leur assiette de contributeurs ont cette barrière à l'entrée faible, relativement à la complexité du projet.

    • [^] # Re: Bravo, mais il y a quand même quelque chose qui me gène dans ce billet ...

      Posté par . Évalué à 10.

      … c'est le dénigrement du code qui a été modifié.

      Ce n'est pas du dénigrement mais une analyse que beaucoup de développeurs de LibreOffice, et avant d'OpenOffice.org, partagent depuis de nombreuses années (le blog de Michael mentionne le code de OOo dés 2001, ce n'est donc pas un petit nouveau). C'est aussi une des raisons du fork, pouvoir enfin avoir les mains libres pour faire le grand ménage indispensable dans le code. Sun n'a jamais accepté que ce travail soit engagé, maintenant il est possible de le faire et c'est tant mieux.

      Je trouve le mot "moisi" finalement bien choisi : le fromage était sans doute appétissant et goûteux il y une douzaine d'années, maintenant certaines parties sont moisies après des années de modifications empilées les unes sur les autres et elles doivent être nettoyées.

      Je trouve que ceux qui ont eu le courage de lancer et organiser l'entreprise de nettoyage s'y prennent finalement pas si mal en réussissant à ne pas tout casser à chaque changement en masse. Cela provoque parfois des bugs difficiles à débusquer mais il faut faire avec (la difficulté pas les bugs) si on veut retrouver un code maintenable.

    • [^] # Re: Bravo, mais il y a quand même quelque chose qui me gène dans ce billet ...

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

      Je pense que c'est toujours le réflexe quand on revient sur du code. Parfois il arrive le comble : on se fait la remarque à soit même.
      Il faut une certaine maturité pour réaliser le travail qui a été fait et se mettre en tête que la réalisation à partir de rien aboutit a un résultat pas parfait, mais si elle une bonne source d'inspiration pour la suite alors c'est du bon boulot. L'usage d'outils peu adaptés d'époque ou à la mode contribue aussi à ce problème.
      Avant, tout le monde jurait que par Java, maintenant de plus en plus diront que le code de telle site mérite d'être purifié à coup de gomme html5.

  • # remarques

    Posté par . Évalué à 7.

    Bravo et merci aux contributeurs !

    Trois remarques/questions:

    • le principal truc qui m'empêche d'utiliser LibO au bureau (en travail collaboratif sur des documents .docx) est qu'il parse l'ensemble du document pour le convertir dans sa représentation interne, et du coup on perd de l'information au passage lors de la reconversion en .docx à l'enregistrement (mise en forme cassée, etc). J'ai cru comprendre qu'un travail était en cours pour que le document enregistré à la fin ne touche que les noeuds OOXML nécessaires (correspondant aux zones du document modifiées par l'utilisateur), comme le font les suite Office sur Android. Ce serait vraiment bien => est-il possible d'en savoir plus ? (N.B. accessoirement, je ne peux pas non plus ouvrir les fichiers embarqués dans un .docx (par exemple un .pdf ou un autre .docx embarqué dans un .docx conteneur)).
    • suggestion: une fonctionnalité qui me manque (et qui n'existe nulle part à ma connaissance) est la possibilité de faire des "branches" (un peu à la git) correspondant à différentes formulations de texte, et discuter/voter ensuite sur la formulation préférée.
    • je termine par un troll: pourquoi Glade ? (surtout en 2014 vu l'état de Gtk+ vs QT5, et sur un produit éminemment multi plate-formes. OK… je n'ai qu'à contribuer, mais bon, je n'ai pas pu m'empêcher de le dire :)
    • [^] # Re: remarques

      Posté par . Évalué à 2.

      J'ai deux pistes pour ta suggestion.

      • Est-ce que tu as regardé les fonctionnalités collaboratives de libreoffice ? Je sais qu'elles existent, je n'y ai juste jamais touché.

      • J'avais vu il y a quelques mois, qu'il était possible de faire du diff avec de l'odt et donc d'utiliser un système de gestion de version avec ça. J'ai fait une recherche 2min avec duckduckgo et voilà un début de piste. Par contre, si tu veux travailler sur du docx et je ne peux moralement t'aider car cela encouragerait ce format.

      • As-tu considéré une solution sérieuse de composition (c'est ce que me donne mon dictionnaire comme traduction de "typesetting") telle que TeX/LaTeX ?

      • [^] # Re: remarques

        Posté par . Évalué à 2. Dernière modification le 05/02/14 à 15:11.

        Est-ce que tu as regardé les fonctionnalités collaboratives de libreoffice

        Si tu parles du mode révision, la réponse est oui. Mais c'est analogue à MS Word (donc pas la possibilité de diverger/commenter/voter/merger différentes propositions, ou alors j'ai zappé ça). Donc ça ne marche que si les collaborateurs travaillent ensemble de manière synchrone et non conflictuelle.

        J'avais vu il y a quelques mois, qu'il était possible de faire du diff avec de l'odt (…)

        Note que j'ai juste introduit l'idée, mais git/diff ne permet pas aisément d'identifier les blocs de texte déplacés (ils sont seulement affichés comme supprimé+ajouté)

        As-tu considéré une solution sérieuse de composition (c'est ce que me donne mon dictionnaire comme traduction de "typesetting") telle que TeX/LaTeX ?

        On parle de travail collaboratif, avec d'autres gens qui ne sont pas geek et ne lâcheront pas leurs habitudes avec MS Office + meeting si facilement. Une interface WYSIWYG est indispensable (pas forcément client lourd, une interface web à la Google Docs pourrait aussi faire l'affaire, mais certainement pas du LaTeX !). Et je ne suis pas responsable de ce sujet, j'essaie juste d'être force de proposition pour qu'on puisse faire plus de web-meetings et moins de meetings physiques. Mais les outils appropriés n'existent malheureusement pas.

        • [^] # Re: remarques

          Posté par . Évalué à 1.

          une interface web à la Google Docs pourrait aussi faire l'affaire

          Par exemple Nuxeo DM, qui dispose d'une extension pour faire des "diffs" entre fichiers?

          • [^] # Re: remarques

            Posté par . Évalué à 2. Dernière modification le 05/02/14 à 18:40.

            Il permet de faire des divergences/branches/commentaires/vote/fusion sur des parties de document ? Il permet de détecter les blocs déplacés ? Il a une interface WYSIWYG aussi complète et facile d'usage que MS Word ou Google Docs (avec support des tableaux, équations, références, illustrations, etc.) ? Il est déployable facilement ?

            Si oui, ça m'intéresse !

            • [^] # Re: remarques

              Posté par . Évalué à 2.

              Il permet de faire des divergences/branches/commentaires/vote/fusion sur des parties de document ? Il permet de détecter les blocs déplacés ? Il a une interface WYSIWYG aussi complète et facile d'usage que MS Word ou Google Docs (avec support des tableaux, équations, références, illustrations, etc.) ? Il est déployable facilement ?

              Non.

    • [^] # Re: remarques

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

      je ne peux pas non plus ouvrir les fichiers embarqués dans un .docx (par exemple un .pdf ou un autre .docx embarqué dans un .docx conteneur)

      Dafuq? Ça marche comment?

      je termine par un troll: pourquoi Glade ? (surtout en 2014 vu l'état de Gtk+ vs QT5, et sur un produit éminemment multi plate-formes. OK… je n'ai qu'à contribuer, mais bon, je n'ai pas pu m'empêcher de le dire :)

      Parce que les développeurs de LibO savent faire du GTK et pas du QtGui/QtQuick? Parce qu'ils avaient déjà un peu commencé? Sans compter le fait qu'il sont déjà en train de nettoyer violemment le code.

      Écrit en Bépo selon l’orthographe de 1990

      • [^] # Re: remarques

        Posté par . Évalué à 5.

        Parce que convertir toute la suite à Qt est n travail de titan ? Parce que même si Qt était meilleur que Glade, le gain serait trop faible par rapport au travail nécessaire ? Parce que la solution actuelle fait son job et qu'il n'y a pas besoin de recoder la roue ?

        • [^] # Re: remarques

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

          Parce que convertir toute la suite à Qt est un travail de titan ?

          Plus que maintenir un toolkit entier (VCL) sur 3 plateformes ?

          Du code Qt peut très bien vivre avec du code fait avec autre chose. Le travail peut se faire au fur et a mesure.

          Glade, automake/autoconf… vue de l’extérieur en 2014, les choix technologiques sont tout de même étonnants.

          • [^] # Re: remarques

            Posté par . Évalué à 3.

            Parce que convertir toute la suite à Qt est un travail de titan ?

            Plus que maintenir un toolkit entier (VCL) sur 3 plateformes ?

            VCL n'est qu'une couche d'abstraction vers les les libs qraphiques des OS pour ce que j'en avais vu.

            Du code Qt peut très bien vivre avec du code fait avec autre chose. Le travail peut se faire au fur et a mesure.

            Oui mais la vie est une question de priorite, et pour l'instant les priorites sont ailleurs.
            De plus il semble que personne de suffisamment motive ne se soit lance.
            Tu m'as l'air bien motive, vas-y, lance toi, je ne pense pas qu'ils te diront non.

            D'ailleurs tout ce travail engage sur la base de code permet de faciliter et accelerer ce genre de contributions.

            • [^] # Re: remarques

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

              VCL n'est qu'une couche d'abstraction vers les les libs qraphiques des OS

              Tout comme wxWidgets, AWT, SWT et dans une moindre mesure GTK+, Qt, SWING…
              Ta négation "n'est qu'une […]" sous entends que c'est facile alors que ça ne l'est absolument pas.

              Tu m'as l'air bien motive, vas-y, lance toi

              Remarque récurrente pour éviter de répondre à toute critique.

              • [^] # Re: remarques

                Posté par . Évalué à 9.

                VCL n'est qu'une couche d'abstraction vers les les libs qraphiques des OS

                Tout comme wxWidgets, AWT, SWT et dans une moindre mesure GTK+, Qt, SWING…
                Ta négation "n'est qu'une […]" sous entends que c'est facile alors que ça ne l'est absolument pas.

                WxWidget n'existe que (!) depuis 1992, alors que StarOffice a debute en 1985.
                Je pense que VCL a existe bien avant WxWidget.
                Ensuite, une fois que les VCL ont ete partout, l'inertie du code l'emporte sur la migration vers une nouvelle librairie fournit par un tiers que tu ne connais pas et dont tu ne maitrise pas l'evolution.
                Le cout de changer de librairie devait etre bien superieur au cout de maintenir l'existant.

                Tu m'as l'air bien motive, vas-y, lance toi

                Remarque récurrente pour éviter de répondre à toute critique.

                Repondre a quelle critique? Si c'est pour ecouter des yakafokon, je ne vois pas l'interet.
                Tu proposes un plan pour le faire (avec €€€€) ou tu espere que les gens de LibreOffice vont le faire pour te faire plaisir?
                Encore une fois, ce n'est pas du tout leur priorite. Si tu ne le comprends pas je ne peux rien pour toi.
                D'ailleurs quel serait l'interet pour eux de le faire?

                • [^] # Re: remarques

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

                  l'inertie du code l'emporte sur la migration vers une nouvelle librairie

                  Tout le monde a bien conscience que c'est compliqué de changer, que ça prends des années.
                  Qt permettrait de le faire par étapes en se mélangeant au code historique.
                  Ça c'est déjà fait pour les MFC, Motif et Java AWT/Swing.

                  quel serait l’intérêt pour eux de le faire ?

                  On tourne en rond là…

                  Utiliser un toolkit comme Qt permet d'externaliser beaucoup de code à des gens dont c'est le métier, qui ont le temps, les compétences et les ressources pour le faire beaucoup mieux que toi.
                  Ça permet de te concentrer sur l'essentiel, sur ton cœur de métier qui n'est pas de développer et maintenir une librairie graphique complète.

                  Et les arguments du type "une nouvelle librairie que tu ne connais pas" et "tu ne maîtrises pas l'évolution" tiennent plus de NIH qu'autre chose. On parle de Qt hein : LGPL, open gouvernance, très bien documenté ect…
                  Subsurface, VLC, Wireshark, LXDE, OpenShot, Stellarium, Autodesk Maya, Ubuntu Unity, TortoiseHg… ont bien réussis à changer pour Qt.

                  Que va t'il se passer s'ils continuent avec leur toolkit interne ?

                  • Le toolkit va continuer de vieillir gentiment : moins jolie que la concurrence, widgets pauvres, pas d’accélération, pas d'animation, moins bonne intégration avec les futurs versions de Windows, OS X…
                  • Temps consacrer à la maintenance et à l’évolution de VCL
                  • Temps de développement important pour ajouter/améliorer des fonctionnalités à LO : exemple de rapidité de développement avec Qt : http://www.youtube.com/watch?v=_6_F6Kpjd-Q, je doute que ça soit aussi rapide et facile avec VCL…
                  • Rebuter les potentiels contributeurs : les gens connaissent les toolkits couramment utilisés, pas VCL
                  • Difficultés de portage sur d'autres plateformes (Android, iOS, FirefoxOS… je parle pas du POC présenté ici : http://arstechnica.com/information-technology/2013/03/libreoffice-for-android-frustratingly-close-to-release/ mais de vrais applications utilisables au quotidien)

                  J'ai travaillé dans des entreprises qui n'ont pas toujours fait évoluer leurs outils et librairies : build system custom en Perl, librairie graphique développée en interne, base de données interne…
                  Ces outils avaient un intérêt 10-15 ans auparavant mais sont devenu un frein important par la suite.

                  En revanche on est bien d'accord que la priorité est de nettoyer le code avant de pouvoir faire un changement de cette importance. Mais apparemment remplacer VCL pour Qt n'est clairement pas à l'ordre du jour :-/

                  Et ce n'est pas parceque je ne contribuerais probablement jamais à LO que je n'ai pas le droit de faire des analyses à son sujet.

                  • [^] # Re: remarques

                    Posté par . Évalué à 4.

                    Merci pour ta reponse detaillee, ca fait beaucoup plus plaisir a lire!!

                    l'inertie du code l'emporte sur la migration vers une nouvelle librairie

                    Tout le monde a bien conscience que c'est compliqué de changer, que ça prends des années.
                    Qt permettrait de le faire par étapes en se mélangeant au code historique.
                    Ça c'est déjà fait pour les MFC, Motif et Java AWT/Swing.

                    Je ne connaissais pas ces pages, c'est interessant. Je croyais que Qt Jambi est mort, mais c'est seulement le support commercial. Il semble qu'il soit maintenu par la communaute.

                    Je pensais que tu parlais d'ajouter une nouvelle implementation de la VCL pour Qt. Cela aurait ete un peu redondant avec l'implementation GTK sur la plateforme GNU/Linux, d'ou le fait que personne ne se bouscule pour la realiser.
                    Je pensais qu'alors il faudrait avoir une implementation Qt complete de la VCL avant de pouvoir l'utiliser, ce qui retarde d'autant le moment ou tu peux l'utiliser.

                    D'ailleurs, le code existe pour une implementation Qt de la VCL (patches welcome):
                    http://ubuntu.5.x6.nabble.com/LibreOffice-welcomes-Qt-devs-was-ubuntu-devel-Digest-Vol-96-Issue-24-td4988545.html

                    quel serait l’intérêt pour eux de le faire ?

                    Utiliser un toolkit comme Qt permet d'externaliser beaucoup de code à des gens dont c'est le métier, qui ont le temps, les compétences et les ressources pour le faire beaucoup mieux que toi.

                    J'avoue que je ne connais pas parfaitement Qt puisque je fais essentiellement du Java. Mais je commence a voir ou tu veux en venir: Qt pourrait etre utilise non seulement en tant que lib graphique, mais plus que cela: types de bases tels que String, filesystem, reseau, audio, etc.

                    Quelqu'un a deja propose Qt, mais rien ne semble bouger:

                    Ceci dit, je n'ai pas trouve de position des developpeurs principaux. J'ai juste trouve l'email de Bjoern Michaelsen (ci-dessus) qui est un contributeur tres regulier.

                    Et les arguments du type "une nouvelle librairie que tu ne connais pas" et "tu ne maîtrises pas l'évolution" tiennent plus de NIH qu'autre chose.

                    Je parlais surtout de WxWidget. Si je travaillais sur LibreOffice, je ne pense pas que je me baserais dessus. Pour Qt, cela me semblerait tout a fait faisable, surtout vu la maniere dont le perimetre de Qt a augmente, et aussi depuis qu'il a ete separe en plusieurs librairies independantes.

                    Temps de développement important pour ajouter/améliorer des fonctionnalités à LO : exemple de rapidité de développement avec Qt : http://www.youtube.com/watch?v=_6_F6Kpjd-Q, je doute que ça soit aussi rapide et facile avec VCL…

                    Oui, mais je pense que Glade leur permet de facilement concevoir des propositions d'interfaces. Je viens de voir que Qt a Qt designer dans le meme registre.

                    En revanche on est bien d'accord que la priorité est de nettoyer le code avant de pouvoir faire un changement de cette importance. Mais apparemment remplacer VCL pour Qt n'est clairement pas à l'ordre du jour :-/

                    Oui, je pense que c'est un enorme pas dans la bonne direction que ce changement d'attitude vis-a-vis du code legacy.
                    Je reconnais que tes arguments sont tout a fait pertinents, et j'ai bien bien peur qu'un portage vers Qt ne soit pas dans le radar actuellement.

                    • [^] # Re: remarques

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

                      Je pensais que tu parlais d'ajouter une nouvelle implementation de la VCL pour Qt
                      […] Je pensais qu'alors il faudrait avoir une implementation Qt complete de la VCL avant de pouvoir l'utiliser

                      Un backend Qt pour VCL pourrait être aussi une façon de passer progressivement vers Qt. C'est même, pourquoi pas, 2 approches complémentaires.

                      En plus des mélanges Qt/MFC, Qt/Motif…, il est possible de mélanger du code Qt avec Glib et probablement même du code Qt avec du GTK+.

                      Glade [..] permet de facilement concevoir des propositions d'interfaces. […] Qt a Qt designer dans le meme registre.

                      Glade et Qt Designer existent depuis la fin des années 90. Ce que propose Qt Quick/QML est d'un tout autre niveau.
                      De plus contrairement à ce qu'on pourrait penser, les perfs sont excellentes ! : http://tolszak-dev.blogspot.fr/2013/02/simple-qml-vs-efl-comparison.html

                      j'ai bien peur qu'un portage vers Qt ne soit pas dans le radar actuellement

                      AMHA ça n'arrivera jamais :/

                      Quand la suite bureautique Calligra sera disponible en version Qt 5 (et grâce au travail sur KDE Frameworks 5), celle-ci tournera logiquement sans "hacks" sous Windows et OS X et profitera ainsi peut être d'un regain d’intérêt et d'une visibilité plus grande (au même titre que d'autres applications KDE comme Amarok, Kate, KMail, Okular…)

                      En attendant tous mes clients travaillent avec MS Office et j'ai jamais vu l'un d'eux utiliser LO.

                      • [^] # Re: remarques

                        Posté par . Évalué à 6.

                        En attendant tous mes clients travaillent avec MS Office et j'ai jamais vu l'un d'eux utiliser LO.

                        C'est probablement parce que LO n'utilise pas Qt. Ils attendent que les devs investissent énormement de temps pour convertir la suite à Qt, ils n'aiment pas que le code soit sale.

                        C'est donc bien une priorité de passer à Qt.

              • [^] # Re: remarques

                Posté par . Évalué à 10.

                Tu m'as l'air bien motive, vas-y, lance toi

                Remarque récurrente pour éviter de répondre à toute critique.

                Sans aller jusque là. Oui Qt est très à la mode depuis quelques temps, mais ça n'est pas choquant que les très gros projets comme OOo/LibO ne passent pas à la dernière mode aussi rapidement que ce que vous vous attendez.

                Il faut tout de même rappeler que le projet reviens de loin. Les distributions Linux les plus grosses en étaient à maintenir leur set de patchs et la dette technique s'est lourdement agrandi avec le temps. Le travail fait actuellement (et depuis la création de LibO) permettra de diminuer l'inertie de tout ça.

                Il me paraît sain pour un projet aussi en vu (= avec des utilisateurs (que ce soit les utilisateurs lambda windows, les administrations ou les libristes aigris) prêt à les démolir et surtout à les finir à coup de pied dans la nuque au moindre problème) de commencer par améliorer précautionneusement l'existant avant de foncer tête baissée vers la dernière techno à la mode.

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

      • [^] # Re: remarques

        Posté par . Évalué à 2.

        je ne peux pas non plus ouvrir les fichiers embarqués dans un .docx (par exemple un .pdf ou un autre .docx embarqué dans un .docx conteneur)

        Dafuq? Ça marche comment?

        Je ne sais pas "comment ça marche" dans le détail, mais je sais juste que je n'arrive pas à ouvrir les PJ dans ce genre de fichier sous Linux.

        • [^] # Re: remarques

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

          Effectivement, ça ne fonctionne pas dans LibO. Mais c’est quoi l’intérêt? Rien que l’idée d’inclure un .zip dans un .doc, ça me donne des suées froides.

          Écrit en Bépo selon l’orthographe de 1990

          • [^] # Re: remarques

            Posté par . Évalué à 3. Dernière modification le 06/02/14 à 15:32.

            Il faudrait que tu précises ta question :

            • "c'est quoi l'intérêt de supporter ça dans LibO" ? Eh bien, juste de pouvoir être compatible avec les documents des autres ! La compatibilité avec .docx reste incomplète sans ça…
            • "c'est quoi l'intérêt de faire ça" ? On est d'accord que c'est critiquable, mais bon, des gens l'utilisent et on ne peut rien y faire. En l'occurence ici il s'agit de la CEPT et des contributeurs/administrations associées. ça fait beaucoup de monde et je n'ai aucun moyen de pression pour faire changer les choses, d'autant que personne ne s'en plaint (à part moi) puisque tout le monde utilise MS Office et n'a aucun problème avec cette fonctionnalité (qui est d'ailleurs à leurs yeux plus simple que d'utiliser un soft d'archivage tel que winzip), donc il est absolument exclu de changer les pratiques. Note que le 3GPP ne fait guère mieux. Dans le monde réel, les gens/organisations/entreprises utilisent ce genre de truc et il faut faire avec.

            Conclusion: après avoir longuement lutté, j'ai dû revenir sous Mac pour avoir un OS Unix à peu près potable tout en ayant MS Word (il y a une autre raison aussi: l'hibernation "juste marche", tout comme le Wi-Fi, le branchement d'un écran externe et la gestion d'énergie, et l'autonomie est double de celle de mon ancien vieux PC/Linux). Mais franchement, j'aimerais me passer du Mac, surtout que la stabilité de Maverick laisse à désirer (< troll > on dirait presque une Ubuntu < /troll > :)

            • [^] # Re: remarques

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

              "c'est quoi l'intérêt de supporter ça dans LibO" ? Eh bien, juste de pouvoir être compatible avec les documents des autres ! La compatibilité avec .docx reste incomplète sans ça…

              Oui évidemment.

              "c'est quoi l'intérêt de faire ça" ? On est d'accord que c'est critiquable, mais bon, des gens l'utilisent et on ne peut rien y faire. En l'occurence ici il s'agit de la CEPT et des contributeurs/administrations associées. ça fait beaucoup de monde et je n'ai aucun moyen de pression pour faire changer les choses, d'autant que personne ne s'en plaint (à part moi) puisque tout le monde utilise MS Office et n'a aucun problème avec cette fonctionnalité (qui est d'ailleurs à leurs yeux plus simple que d'utiliser un soft d'archivage tel que winzip), donc il est absolument exclu de changer les pratiques. Note que le 3GPP ne fait guère mieux. Dans le monde réel, les gens/organisations/entreprises utilisent ce genre de truc et il faut faire avec.

              «Quand on n’a qu’un marteau, tous les problèmes ressemblent à des clous.»

              Écrit en Bépo selon l’orthographe de 1990

          • [^] # Re: remarques

            Posté par . Évalué à 3.

            Ça sert exactement à la même chose que la fonctionnalité "pièce jointe" des emails.

            C'est très pratique par exemple pour pondre un rapport et joindre en annexe des feuilles de calcul avec les données qui ont amené aux conclusions (sans polluer le doc avec des zillions de pages d'annexe inexploitables).

            BeOS le faisait il y a 15 ans !

            • [^] # Re: remarques

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

              Je ne dis pas que ça n’est pas pratique, ça ne me parait pas être la meilleure solution. Mais c’est peut-être parce que c’est le genre de truc qui se fait proprement en web et pas très facilement ailleurs.

              Écrit en Bépo selon l’orthographe de 1990

    • [^] # Re: remarques

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

      je termine par un troll: pourquoi Glade ? (surtout en 2014 vu l'état de Gtk+ vs QT5, et sur un produit éminemment multi plate-formes. OK… je n'ai qu'à contribuer, mais bon, je n'ai pas pu m'empêcher de le dire :)

      LibreOffice ne passe pas à Gtk. Il reste avec son toolkit perso (VCL). Il n'utilise Glade que pour définir l'UI. Le problème avec leurs système passé est décrit ici

      Après pourquoi Glade plutot que QT Designer ? Aucune idée, j'ai pas trouvé d'info en 5 minutes, mais on aurait aussi pu se poser la même question si ils avaient l'autre choix.

      Peut être que Qt est conçu pour être un Framework complet plutôt qu'un simple bibliothèque graphique et qu'il est plus difficile d'utiliser un seul composant en dehors du framework ? Ou que le format xml de Glade était plus proche de ce qu'ils avaient déjà ?

      Matthieu Gautier|irc:starmad

      • [^] # Re: remarques

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

        Ha ben zut alors. Ma magnifique balise <troll></troll> entourant mon dernier paragraphe a été viré par markdown …

        Matthieu Gautier|irc:starmad

    • [^] # Re: remarques

      Posté par . Évalué à 2.

      surtout en 2014 vu l'état de Gtk+ vs QT5

      C'est quoi exactement le problème de GTK+ ?

      • [^] # Re: remarques

        Posté par . Évalué à 10.

        C'est quoi exactement le problème de GTK+ ?

        Lire https://linuxfr.org/news/gtk-to-qt-a-strange-journey et les commentaires du journal originel.

      • [^] # Re: remarques

        Posté par . Évalué à 10.

        Phoronix : The Biggest Problem With GTK & What Qt Does Good. En résumé : les copains de Linus qui développent avec lui un logiciel de plongée aquatique font une présentation orale en expliquant pourquoi ils sont passé à Qt. Traduction personnelle d'un extrait de l'article de Michael Larabel :

        « Pendant leur oral à LCA 2014, Dirk Hohndel a partagé avec l'auditoire ce qu'il pense être le plus gros problème de GTK… ce n'est pas le manque de portabilité cross-plateforme ou un problème technique quelconque, mais “le plus gros problème avec GTK c'est l'attitude du noyau de la communauté”. Dirk partage le même point de vue de nombreux utilisateurs à propos du travail avec des développeurs en amont GTK/GNOME, qui est une tâche rude, conduit à de nombreuses flame-wars et à des accusations de la part des développeurs que “c'est vous qui faites ça de travers”. Dirk trouve que la communauté des développeurs de Qt est tout à l'opposé : les développeurs voulaient aider, il y a beaucoup de documentation pour développeur, et il n'y avait pas de problèmes de communication comme ceux qui se produisaient lorsqu'il avait affaire aux développeurs de GTK »

        Dans un autre registre, le point de vue de David Nečas, le contributeur principal de Gwyddion, un logiciel spécialisé de traitement d'images scientifiques, sur la mailing-list des utilisateurs. Un utilisateur demandait comment on fait pour transformer un menu en fenêtre flottante. Le développeur est bien étonné que ça ne fonctionne plus (ça a fonctionné dans Gimp depuis des lustres…), indique donc qu'il enlèvera la fonctionnalité, mais cherche aussi sur le bugzilla de gnome pourquoi ça ne marche plus. Je traduis de l'anglais son avis désabusé suite à sa découverte du problème :

        « Le rapport de bug pertinent est : https://bugzilla.gnome.org/show_bug.cgi?id=602882 et il suit les lignes familières :

        1. Emmanuele Bassi déclare qu'une fonctionnalité est dépassée.
        2. Les gens essayent de lui démontrer son utilité et Emmanuele Bassi leur répond que c'est leur interface qui est mal conçue.
        3. La fonctionnalité est dépréciée (deprecated).
        4. La fonctionnalité est cassée bien qu'elle fasse toujours partie de l'API stable. »

        Source : Messages de novembre 2013

        • [^] # Re: remarques

          Posté par . Évalué à 10.

          Ce rapport de bug est parfait.

          On peut trouver des perles comme ceci:

          yes, I do know how tearoff menus work, thank you very much.

          what I'm arguing is:

          • tearoff menus are used to implement toolboxes; gtk+ recently (and I mean
          today) merged the toolpalette widget to make it even easier to write UIs with
          toolboxes;
          • tearoff menus are used in specific applications, much like other widgets
          that have been deprecated and are planned to be removed (GtkCurve, GtkHSV);

          hence, they should be removed from gtk+ 3.0. you are still free to copy and
          paste the code into your application, if license allows it. or you might wish
          to re-evaluate the user interaction of your application if you rely on a piece
          of ancient UI design like tearoff menus.

          C'est meme pire que le resume donne par David.

          [x] Ton meprisant: je sais comment marche GTK, merci bien
          [x] Complete hypocrisie: la solution a votre probleme est de re-ecrire votre UI en utilisant la nouvelle fonctionnalite qui vient d'etre ajoutee aujourd'hui
          [x] Si vous etes pas contents, vous n'avez qu'a faire un copier coller du code de GTK dans votre appli (si la license l'autorise, hahaha)

          Meme si on peut comprendre que les devs GTK ne veuillent pas maintenir certaines parties, la facon de presenter les choses est franchement insultante et repondre de facon plus sympathique ne leur couterait pas grand chose.

          Par exemple:

          Merci d'avoir partage votre facon de travailler avec GTK. Malheureusement, les menus flottants sont une fonctionnalite depreciee qui nous avons prevu de retirer de Gtk3. La maintenance etait devenue trop importante et plusieurs problemes d'UX etaient apparus avec le temps (voir [ici] pour les choix qui nous ont conduit a retirer cette fonctionnalite). Nous travaillons actuellement sur un remplacement potentiel. Vous pouvez trouver plus d'information [ici].

          Tout retour sur cette nouvelle fonctionnalite et les manques que vous pourriez rencontrer pour remplacer votre interface utilisateur existante sera grandement apprecie.

          Apres il y en aura pour dire que c'est du politiquement correct et que la methode directe est meilleure. Evidemment, si les devs GTK n'en on rien a faire des applications qui utilisent le toolkit, trouvent que les utilisateurs sont des emmerdeurs et que si ils ne sont pas contents ils peuvent aller se faire voir, n'ont pas de documentation pour expliquer leurs decisions et ne savent pas communiquer sans passer pour des malotrus, ca va pas le faire…

          • [^] # Re: remarques

            Posté par . Évalué à 10.

            Et une autre belle perle : "Do not add rants or insults to this bug. (…) Thanks—GNOME Bugzilla Maintainers." en réponse à un mec qui dit simplement "you have no perspective of this issue at all."

            C'est-à-dire, en français, "Pas d'insulte, sinon vos comptes seront suspendus" en réponse à quelqu'un qui dit (et développe avec des exemples) au développeur qui retire la fonctionnalité "je te donne des exemples d'utilisateurs, tu les trouves artificiels, tu n'as aucun recul sur ce sujet"

            Ça résume bien l'état d'esprit des développeurs de GTK : leur démontrer qu'ils sont dans leur tour d'ivoire en donnant des cas d'utilisation réels et concrets est considéré comme une insulte.

    • [^] # Re: remarques

      Posté par . Évalué à 3.

      pourquoi Glade ?

      De mémoire, M. Meeks et plusieurs autres dévs ont bossé sur Gnome et GTK+. Je présume qu’ils ont choisi l’outil qu’ils connaissaient.

    • [^] # Re: remarques

      Posté par . Évalué à 10.

      Bonjour et merci :)
      Pour tes points 1 et 2, il y a des choses en cours (comme le parseur xml maison) et en réflexion, mais c'est un peu prématuré pour en parler, rien de caché, mais c'est entrer dans des détails qui n'ont pas trop à leur place ici.

      Pour ton dernier point, c'est aussi assez interne. La gestion des boîtes de dialogue est très liée à la localization, y compris en anglais, dans le développement de LibreOffice. Glade permet d'avoir une prévisualisation des dialogues dans chaque langue que nous pourrons également bientôt avoir à la volée dans Pootle. Bref, notre cuisine interne et elle nous va bien :) - Sophie

  • # Merci

    Posté par . Évalué à 3.

    Merci à tous pour les contributions rapides

  • # Qu'il est beau le lavabo !

    Posté par . Évalué à -10.

    Désolé si je dépare dans ce feu d'artifice de nouveautés merveilleuses, mais j'ai installé Libreoffice 4.2 sur ma kubuntu 13.10 pendant une semaine et j'ai largement déchanté.
    Plantages à répétition ( dix fois de suite en voulant supprimer une ligne dans un fichier calc ) , impossibilité de fabriquer des étiquettes : l'écran de config des étiquettes s'ouvre une fois sur trois et le nouveau document est une page texte… j'ai failli péter un plomb ! Il m'a fallu un quart d'heure pour accéder à un répertoire avec les boites de dialogue de kde alors qu'avec la version précédente, il n'y avait aucun problème. Là j'ai été obligé d'utiliser les dialogues de libreoffice que je n'aime pas trop. Jamais vu de version aussi crade !
    J'ai bien entendu supprimé le profil pour "nettoyer" le terrain mais ça ne change rien. C'est ri-pou !
    Il y a sans doute des améliorations mais c'est pas pour les linuxiens apparemment.
    C'était mon quart d'heure de mauvaise humeur.
    Merci de m'avoir supporté et vivement une version de libre office propre et belle. Au siècle prochain peut être ?

    • [^] # Re: Qu'il est beau le lavabo !

      Posté par (page perso) . Évalué à 10. Dernière modification le 03/02/14 à 16:37.

      j'ai installé Libreoffice 4.2 sur ma kubuntu 13.10 pendant une semaine

      Eh bien, je suis heureux de t'apprendre que ce que tu as installé et utilisé, c'était une version bêta, puisque LibreOffice 4.2 n'a été publié qu'il y a quatre jours. Et tu t'étonnes d'y trouver des bogues ?

      Je te suggère d'installer maintenant LibreOffice 4.2 pour effectuer un essai plus pertinent. Si ces bogues sont toujours présents, tu pourras râler de façon légitime.

      • [^] # Re: Qu'il est beau le lavabo !

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

        tu pourras râler de façon légitime.

        Et ouvrir des bugs en consequence.

        • [^] # Re: Qu'il est beau le lavabo !

          Posté par . Évalué à -10.

          Poussé par mon empathie envers les libreoffice fanboys je viens d'installer les paquets de la version 4.2.4 ( et non plus 4.2.2 ) que j'avais insolemmment voulu essayer.
          Je tente mon test : créer une feuille d'étiquettes.
          Résultat : le nouveau document s'ouvre sur une page de texte. La fenêtre se fige. Une boîte de dialogue apparait m'indiquant que libre office ne répond plus.
          Bravo les gars, tout est parfait !
          Je vois d'ici les utilisateurs candides qui auront suivi vos conseils. Ça va les vacciner un moment….
          et merci pour le moinssage très pertinent.
          Pour finir, un mot sur l'ouverture des bugs : je ne sais pas faire et je n'ai pas le temps d'apprendre.

          • [^] # Re: Qu'il est beau le lavabo !

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

            Pour finir, un mot sur l'ouverture des bugs : je ne sais pas faire et je n'ai pas le temps d'apprendre.

            C'est ultra-simple. Ça consiste simplement à décrire son problème de façon précise (version, distro, comment reproduire le bug).

            Après en fonction du bug ça peut te prendre un peu de temps, certes.

            Écrit en Bépo selon l’orthographe de 1990

          • [^] # Re: Qu'il est beau le lavabo !

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

            Pour finir, un mot sur l'ouverture des bugs : je ne sais pas faire et je n'ai pas le temps d'apprendre.

            Triste vie que celle où l'on n'a pas le temps d'apprendre. Je compatis.

          • [^] # Re: Qu'il est beau le lavabo !

            Posté par . Évalué à 10.

            Pour finir, un mot sur l'ouverture des bugs : je ne sais pas faire et je n'ai pas le temps d'apprendre.

            Nous avons même pensé à toi, tu peux décrire les problèmes rencontrés en français : http://fr.libreoffice.org/participer/signaler-un-bug-en-francais/

            Fais toi plaisir.

          • [^] # Re: Qu'il est beau le lavabo !

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

            Bravo les gars, tout est parfait !
            Je vois d'ici les utilisateurs candides qui auront suivi vos conseils. Ça va les vacciner un moment….
            et merci pour le moinssage très pertinent.

            Tu as dû rater le tout premier paragraphe de la dépêche:

            LibreOffice 4.2.0 vient d'être publié (le 30 janvier 2014). Cette nouvelle version est destinée aux utilisateurs expérimentés – les autres, comme les entreprises et les administrations sont invitées à utiliser LibreOffice 4.1.4 (publié le 18 décembre 2013).

            Python 3 - Apprendre à programmer en Python avec PyZo et Jupyter Notebook → https://www.dunod.com/sciences-techniques/python-3

    • [^] # Re: Qu'il est beau le lavabo !

      Posté par . Évalué à 2.

      j'ai installé Libreoffice 4.2 sur ma kubuntu 13.10 pendant une semaine et j'ai largement déchanté.

      Le problème c'est peut-être Kubuntu. Il faudrait voir ce que ça donne avec KDE sur une autre distribution.

      • [^] # Re: Qu'il est beau le lavabo !

        Posté par . Évalué à -2.

        T'as le droit d'y croire.
        Pour ceux qui font remonter les bugs, voici celui du matin : lorsque tu affiches les contrôles de formulaire, il faut passer par le menu affichage pour masquer la barre d'outils. Les boutons ne fonctionnent pas.

    • [^] # Re: Qu'il est beau le lavabo !

      Posté par . Évalué à 8.

      Precedemment on parlait du "'dénigrement' du code qui a été modifié", et bien je parle ici du denigrement du projet LibreOffice.

      C'est ri-pou !

      C'est triste ton avis sur LibreOffice et ton attitude non constructive.
      Si tu n'es pas content et que tu n'as pas le temps, passe ton chemin et utilise Calligra ou Gnome Office.

  • # Mouahis

    Posté par . Évalué à 0.

    Bon ben vivement que Calligra decolle. Plus les annees passent et plus LibreOffice devient inutilisable et a la traine. Il n'y a strictement aucune avance majeure (surtout dans l'UI) et lorsque l'on regarde les nouveautes (site officiel) cela ne concerne a peu pres qu'une seule chose: Microsoft OXML. Ce qui est debile car c'est un combat perdu d'avance. La norme est buggue et meme chez Microsoft deux equipes differentes n'arrivent pas a l'implementer de la meme facon. Il y a plein de truc qui ne fonctionneront JAMAIS dans les fichiers docx/pptx/xlsx niveau interoperabilites. J'ai recu un jour un template qui etait assez immonde a l'ouverture avec LO et Calligra, j'ai donc regarde dedans et qu'est ce que j'ai vu a votre avis? Rien de moins que des fichiers image au format EMF, un format Microsoft que rien ni personne n'utilise ni ne lit. Et je parle d'un template tout beau tou neuf.

    Donc courir apres cette merde de docx au lieu d'avoir une suite office digne de ce nom c'est nul car cela fait le jeu de Microsoft qui lui ameliore sa suite (pas son format mais ca c'est fait expres) avec des trucs utile ou pratique dans l'UI alors que ca fait 10 ans que celle de LO n'a pas change d'un iotat. Je ne parlerai meme pas de impress (et la calligra est dans la meme merde car leur logiciel de presentation est le truc le moins developpe).

    • [^] # Re: Mouahis

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

      Je partage ta vision sur le format de Microsoft, mais il y a des travaux en cours pour améliorer l’interface comme une barre latérale (un peu comme Calligra). Même si j’aime beaucoup Calligra et que je la trouve très bonne, on ne peut nier qu’il n’est pas encore au niveau de LibreOffice (fonctionnalités, stabilité, support des différents formats), à part peut-être Kexi (pour les bases de données, j’ai cru comprendre qu’ils avançaient bien sur celui-là).

      Écrit en Bépo selon l’orthographe de 1990

    • [^] # Re: Mouahis

      Posté par . Évalué à 10.

      Si tu lis la dépêche qui pourtant est assez claire là-dessus, la direction actuelle de LO c'est de nettoyer le bousin pour repartir sur une bonne base avant d'attaquer les gros changements.

      Presque tout ce que je vois ici parle généralement d'assainissement du code et remplacement de composants obsolètes par des composants modernes.

      Pour voir la révolution, je pense qu'il faudra attendre une version ou deux encore.

      En attendant, je ne comprends pas bien en quoi il devient inutilisable. Pour moi, ça marche aussi bien qu'avant (note que je n'ai pas essayé cette version explicitement déclarée comme réservée aux experts).

      L'interface, je suis content qu'elle ne change pas radicalement, parce qu'après 2ans, je rame encore souvent avec les rubans de tu-sais-qui.

      • [^] # Re: Mouahis

        Posté par . Évalué à 0. Dernière modification le 03/02/14 à 18:18.

        J'ai bien lu mais bon ca fait plusieurs annees de nettoyage pour arriver a un truc qui marche mal sur les bureaux KDE et qui stagne sur toutes les fonctionnalites. Vu le temps pris pour le nettoyage je me demande si il n'aurait pas mieux valu abandonner le code et repartir d'un truc propre?

        Pourquoi conserver le vieux toolkits qui s'integre mal partout et fait bien sentir son age. Pourquoi ne pas passer sur le seul toolkit reellement multiplateforme Qt?

        Je ne parlais pas de changer radicalement l'interface mais d'apporter des ameliorations. Je ne peux pas croire que l'interface etait parfaite. Un truc que j'aimerai bien avoir c'est le changement des font de la justification etc avec le curseur comme le fait MS Office, ca c'est tres pratique et limite les mouvements de la souris. Un exemple parmis d'autre.

        • [^] # Re: Mouahis

          Posté par (page perso) . Évalué à 2. Dernière modification le 03/02/14 à 20:04.

          Un truc que j'aimerai bien avoir c'est le changement des font de la justification etc avec le curseur comme le fait MS Office, ca c'est tres pratique et limite les mouvements de la souris.

          Lapin compris.

          ÉDITION: j'ai compris. Tu parles de la possibilité de changer la police, la couleur, la justification du texte etc qui apparait au-dessus du curseur.

          Et une fonte n'est pas une police, qu'on se le dise.

          Écrit en Bépo selon l’orthographe de 1990

        • [^] # Re: Mouahis

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

          J'ai bien lu mais bon ca fait plusieurs annees de nettoyage pour arriver a un truc qui marche mal sur les bureaux KDE et qui stagne sur toutes les fonctionnalites. Vu le temps pris pour le nettoyage je me demande si il n'aurait pas mieux valu abandonner le code et repartir d'un truc propre?

          Est-ce que tu penses sérieusement que tu peux faire une suite bureautique compétitive, aujourd'hui, en repartant de zéro ? Tu es sérieux ? Tu fais du développement dans la vraie vie ?

          • [^] # Re: Mouahis

            Posté par . Évalué à 3.

            C'est rigolo mais Apple l'a bien fait et actuellement le meilleur logiciel de presentation que je connaisse c'est keynote. Donc je n'y connais rien mais je regarde ce qui se passe a cote et quand je vois que la suite est de moins en moins competitive, que les differents modules sont de moins en moins utilisables. En 98, staroffice impress fonctionnait mieux que LO impress!!! C'est hallucinant mais pourtant c'est vrai.

            Combien d'heures/homme ont ete passe pour la pseudo-compatibilite avec un truc qu'il sera toujours impossible a etre compatible (cf le probleme des fichiers emf du dessus) au lieu de faire en sorte que l'implementation de ODF soit parfaite, d'ameliorer l'UI etc.

            Mais comme tu dis je n'y connais rien mais je vois que il y a 5 ans, il y avait plus de LO installe que aujourd'hui.

            Tente donc de trouver un moyen d'ouvrir et d'editer des fichiers ODF avec un tablette ou un smartphone. Il n'y a rien de valable. C'est sur ce genre de point que les forces auraient du se concentrer a mon avis.

            • [^] # Re: Mouahis

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

              Plusieurs points :
              - On parle d'une suite bureautique, pas d'un logiciel de présentation
              - Combien de dév. sont payés et travaillent à plein temps sur Keynote. Combien sur LibreOffice
              - Apple se base sur une communauté de clients "fanboy", clients qui sont prêt à ne pas avoir de compatibilité avec le monde extérieur parce qu'ils sont convaincus qu'eux détiennent la vérité (dans le sens "les meilleurs outils"). Quand tu as cette approche, tu ne cherches pas à faire de compatibilité.
              - Dans le monde professionnel, je ne connais personne qui travaille (édite des documents) sur téléphone mobile ou tablette ; la plupart du temps le téléphone est utilisé en consultation et les tablettes pour faire des démos aux clients, parce que c'est plus sexy qu'un bon vieux portable de 5kg.

              Pour le reste, je ne sais pas si LibreOffice a fait de bons choix stratégiques, je n'ai pas la compétence pour en juger et donc je m'abstiens. Un peu d'humilité ne fait jamais de mal.

              • [^] # Re: Mouahis

                Posté par . Évalué à 1.

                - On parle d'une suite bureautique, pas d'un logiciel de présentation

                C'est vrai d'ailleurs on se demande pourquoi c'est uniquement la version pro de MS office qui a ce module…

                - Combien de dév. sont payés et travaillent à plein temps sur Keynote. Combien sur LibreOffice
                - Apple se base sur une communauté de clients "fanboy", clients qui sont prêt à ne pas avoir de compatibilité avec le monde extérieur parce qu'ils sont convaincus qu'eux détiennent la vérité (dans le sens "les meilleurs outils"). Quand tu as cette approche, tu ne cherches pas à faire de compatibilité.

                Donc on part de c'est pas faisable a d'autre considerations

                - Dans le monde professionnel, je ne connais personne qui travaille (édite des documents) sur téléphone mobile ou tablette ; la plupart du temps le téléphone est utilisé en consultation et les tablettes pour faire des démos aux clients, parce que c'est plus sexy qu'un bon vieux portable de 5kg.

                Dans mon monde pro c'est de plus en plus le cas mais bon encore une fois cela n'existe pas dans ton monde donc cela n'est pas vrai. Je precise que je ne suis pas forcement pour mais cela arrive petit a petit. Dans les confs ou je suis alle, j'ai vu de plus en de personne ne pas amener le portable mais juste une tablette et vouloir malgre tout changer ou finir leur presentation. Sur un ipad c'est faisable, sur n'importe quel autre tablette euh comment dire … c'est de la merde en boite? Oui je crois que c'est la bonne def. Les raisons sont multiples: la securite c'est chiant a passer, le risque aux USA qu'ils te gardent le PC, les problemes qu'il y a des donnees sensibles (et que tu n'as pas forcement le temps de faire le menage), le poid et l'encombrement etc.
                Ce n'est donc pas juste une question de sexy.

                • [^] # Re: Mouahis

                  Posté par (page perso) . Évalué à 6. Dernière modification le 04/02/14 à 12:36.

                  Les raisons sont multiples: la securite c'est chiant a passer, le risque aux USA qu'ils te gardent le PC, les problemes qu'il y a des donnees sensibles (et que tu n'as pas forcement le temps de faire le menage),

                  Parce qu'il n'y a aucun risque qu'aux États-Unis ils te gardent la tablette, et qu'il n'y a pas de données sensibles dessus, c'est ça ?

                  le poid et l'encombrement etc.

                  Ça, ce sont des raisons valables, au moins.

                  • [^] # Re: Mouahis

                    Posté par . Évalué à 3.

                    Je sais pas mais quand je vois que des boites ont des PC speciaux pour les deplacements a l'etranger et que en fait il n'y a du coup absolument rien dessus. C'est qu'il y a une raison. Mais je peux me tromper et l'espionnage industriel n'existe pas sauf dans les romans.
                    Quitte a avoir un truc sans rien autant partir avec une tablette.

                    • [^] # Re: Mouahis

                      Posté par . Évalué à 2.

                      Je pertinente : j'ai déjà vu des personnes (pas contentes, du coup) se faire embarquer leur PC professionnel à l'aéroport, même en dehors des États-Unis, parfois pour 30 minutes, alors que des étudiants passaient leur PC sans soin particulier.

                      • [^] # Re: Mouahis

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

                        La régle quand on voyage et qu'on a des données "importantes" : tout chiffré et/ou tout récupérer par Internet SSL… Sinon mauvais personnel, changer personnel ;-).

                        (Il n'y a que moi qui chiffre le disque de mon portable?)

                        • [^] # Re: Mouahis

                          Posté par . Évalué à 7.

                          Chiffrer le disque n'est pas facile à mettre en place pour une "grosse" boîte surtout si ce n'est pas sa spécialité, et ça protègera assez peu de la rubberhose cryptanalysis (franchement, est-ce qu'à l'aéroport, fatigué avec un avion à prendre, dans un pays parfois peu connu, on a envie de vérifier que c'est bien un état de droit ? À moins d'utiliser un truc dans le genre des volumes cachés de TrueCrypt, qui ne sont vraiment pas démocratisés, et qui sont encore plus risqués si on se fait prendre).

                          Récupérer les données via un canal chiffré après coup est le mieux (après la valise diplomatique :-p), mais encore faut-il que le PC n'ai pas été compromis par le pays d'accueil (donc qu'on ne l'ait pas quitté des yeux à l'aéroport). Dès que le PC quitte nos yeux, il faut le considérer comme définitivement compromis (y compris avec un BIOS verrouillé : les malware dans les firmware de disque ne sont pas de la blague, cf les révélations de Snowden)

                          Enfin bref, le mieux pour partir à l'étranger est de n'emporter qu'un PC dédié à ça sur lequel on met le minimum de données nécessaire à l'accomplissement du voyage : si c'est une filiale de la boîte qu'on visite, il faut récupérer les données de l'intérieur via un VPN ou équivalent ; si on visite un partenaire potentiel, il ne faut mettre que les documents nécessaires à la négociation).

                          • [^] # Re: Mouahis

                            Posté par . Évalué à 1.

                            PC Vierge + live cd gravé sur un cd non réinscriptible + récupération ultérieure des données via VPN donc ?

                            • [^] # Re: Mouahis

                              Posté par . Évalué à 3.

                              Ça ne change rien si le PC a été compromis à l'aéroport. Les virus de bios sont une réalité.
                              Il s'agit surtout de partir avec les données strictement nécessaires.

                          • [^] # Re: Mouahis

                            Posté par (page perso) . Évalué à 4. Dernière modification le 04/02/14 à 15:25.

                            mais encore faut-il que le PC n'ai pas été compromis par le pays d'accueil (donc qu'on ne l'ait pas quitté des yeux à l'aéroport).

                            La, on attaque l'arme lourde, rarement (pas pour une petite/moyenne boite) utilisée il me semble. Je trouve qu'un chiffrement est la base (et même pour une petite structure, ce n'est vraiment pas difficile à mettre en oeuvre de nos jours) pour éviter les yeux indiscrets.

                            Après, si c'est ultra confidentiel, clair tu passe à l'aéroport sans rien et tu achète un PC dans un commerce inconnu pris au pif et tu télécharges tout par internet (bref, un PC portable jetable :) ) via un Live CD non reinscriptible et un pass à toi, le risque n'est plus alors que la backdoor soit sur toutes les machines (la, il faut être gros parano!)

                            Bref, gardons quand même une sécurité adaptée au risque.

                            • [^] # Re: Mouahis

                              Posté par . Évalué à 2.

                              rarement (pas pour une petite/moyenne boite) utilisée il me semble
                              C'est le problème avec la sécurité : d'un côté, il n'y a rien de pire que l'illusion de sécurité, de l'autre l'espionnage économique et les compromissions de firmware sont des réalités.

                              Je nuancerais un peu ton propos cela dit : une start-up encore petite (donc PME) mais sur des technologies de pointe est une cible royale pour l'espionnage économique (ce sont celles qui innovent le plus, et qui se protègent le moins). Les grosses boîtes sont cela dit importantes à cibler notamment pour viser leurs labos de recherche.

                              Par contre bon nombre de petites boîtes ne sont sans doutes pas visées, clairement. Surtout celles qui bossent dans l'open-source, vu que leurs produits sont publics :-)

                              • [^] # Re: Mouahis

                                Posté par (page perso) . Évalué à 4. Dernière modification le 05/02/14 à 10:10.

                                Surtout celles qui bossent dans l'open-source, vu que leurs produits sont publics :-)

                                Le code source n'est pas la seule donnée sur une machine (surtout pour un commercial, oui ça existe un commercial pour de l'Open-Source!).
                                Perso, j'ai des fichiers client de test sous NDA, des entreprises qui ne veulent pas qu'on sache qu'elles travaillent avec moi ni combien elles me payent etc… L'Open-Source ne change rien dans le besoin de sécuriser sa machine pour ne pas se faire piquer des données.

                          • [^] # Re: Mouahis

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

                            Chiffrer le disque n'est pas facile à mettre en place pour une "grosse" boîte surtout si ce n'est pas sa spécialité, et ça protègera assez peu de la rubberhose cryptanalysis

                            Pfiou, j'ai du chercher ce que c'était que ça, même si j'avais bien une petite idée. Pour ceux qui se posent la question, la « cryptanalyse au tuyau en caoutchouc », c'est ce qu'on pourrait appeler de façon plus claire la cryptanalyse à la clef à molette ou à la gégène, décrite dans le 538.

                            • [^] # Re: Mouahis

                              Posté par . Évalué à 3.

                              Dans ce cas, ce serait surtout la cryptanalyse à la garde-à-vue de 48 heures avec menace d'enfermement à guantanamo / au laogai / dans les geôles secrètes iraniennes ou israéliennes.

                          • [^] # Re: Mouahis

                            Posté par . Évalué à 2.

                            Donc soit on fait rien, soit on doit se considéré comme ennemis publique numéros 1 des USA ? Commençons par chiffrer les partitions après on verra si le risque de se faire piéger sa machine est si important que ça.

                            Enfin bref, le mieux pour partir à l'étranger est de n'emporter qu'un PC dédié à ça sur lequel on met le minimum de données nécessaire à l'accomplissement du voyage : si c'est une filiale de la boîte qu'on visite, il faut récupérer les données de l'intérieur via un VPN ou équivalent ; si on visite un partenaire potentiel, il ne faut mettre que les documents nécessaires à la négociation).

                            Ça n'est pas du tout une solution au problème que tu décris juste avant. Parce que si tu as vraiment peur que ton PC soit compromis parce que tu ne l'a pas vu pendant 30 min. Il vaut mieux ne plus le connecter à un réseau de confiance.

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

                            • [^] # Re: Mouahis

                              Posté par . Évalué à 2.

                              Commençons par chiffrer les partitions
                              Oui, c'est la base, bien sûr. Et verrouiller le bios pour éviter le démarrage sur une clef USB et la compromission de /boot ou équivalent.

                              Ça n'est pas du tout une solution au problème que tu décris juste avant.
                              Dans le cas où on arrive dans une filiale, elle a déjà un accès sécurisé au réseau de l'entreprise, il suffit donc d'arriver avec sa carte à puce : pas besoin de transporter un PC avec des données confidentielles, on pourra les récupérer de l'intérieur.

                              Sinon effectivement, si on considère le PC comme compromis, son utilisation sur un réseau interne est à proscrire.

                • [^] # Re: Mouahis

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

                  On parle d'une suite bureautique, pas d'un logiciel de présentation
                  C'est vrai d'ailleurs on se demande pourquoi c'est uniquement la version pro de MS office qui a ce module…

                  Il y en a un dans LibreOffice. Il est limité, je te l'accorde, mais faire évoluer un module d'une suite logicielle est beaucoup plus compliquer que faire "une appli toute seule qui n'a pas besoin de compatiiblité avec d'autres logiciels, quels qu'ils soient".

                  • Combien de dév. sont payés et travaillent à plein temps sur Keynote. Combien sur LibreOffice
                  • Apple se base sur une communauté de clients "fanboy", clients qui sont prêt à ne pas avoir de compatibilité avec le monde extérieur parce qu'ils sont convaincus qu'eux détiennent la vérité (dans le sens "les meilleurs outils"). Quand tu as cette approche, tu ne cherches pas à faire de compatibilité. Donc on part de c'est pas faisable a d'autre considerations

                  Je vois pas où j'ai dit que c'était pas faisable. Ce que je dis c'est que les moyens et les objectifs de LibreOffice sont très différents de ce de ton logiciel de présentation. C'est un fait. Et si ton logiciel te convient, pourquoi veux-tu que LibreOffice face pareil ?

                  • Dans le monde professionnel, je ne connais personne qui travaille (édite des documents) sur téléphone mobile ou tablette ; la plupart du temps le téléphone est utilisé en consultation et les tablettes pour faire des démos aux clients, parce que c'est plus sexy qu'un bon vieux portable de 5kg.

                  Dans mon monde pro c'est de plus en plus le cas mais bon encore une fois cela n'existe pas dans ton monde donc cela n'est pas vrai.

                  Je n'ai pas dit que ça n'existait pas, je dis que dans certains domaines (le mien par exemple), il n'y a aucune attente particulière quant à LibreOffice. Les personnes qui font du business utilisent des outils proprio, les autres des logiciels libres.

                  De toute façon, avant de faire tourner LibreOffice sur un téléphone mobile… on a encore un peu de marge ;)

                  Je precise que je ne suis pas forcement pour mais cela arrive petit a petit. Dans les confs ou je suis alle, j'ai vu de plus en de personne ne pas amener le portable mais juste une tablette et vouloir malgre tout changer ou finir leur presentation. Sur un ipad c'est faisable, sur n'importe quel autre tablette euh comment dire … c'est de la merde en boite? Oui je crois que c'est la bonne def. Les raisons sont multiples: la securite c'est chiant a passer, le risque aux USA qu'ils te gardent le PC, les problemes qu'il y a des donnees sensibles (et que tu n'as pas forcement le temps de faire le menage), le poid et l'encombrement etc.
                  Ce n'est donc pas juste une question de sexy.

                  Tu veux en venir où ? Je me trompe sur l'utilisation des tablettes, soit. Mais Tu n'utilises pas LibreOffice sur une tablette de toute façon : les ressources sont plus limitées, donc il faut des performances plus pointues quitte à faire des compromis sur la richesse des fonctionnalités (je ne parle pas de pertinence, hein, mais de richesse).

                  Tu voudrais quoi, en fait ? Qu'au lieu d'assainir le code, l'équipe de LibreOffice mette au point le portage sur Android ? Qu'ils implémentent des filtres pour être compatible avec Keynote ? J'ai pas compris.

                  • [^] # Re: Mouahis

                    Posté par . Évalué à 1.

                    Il y en a un dans LibreOffice. Il est limité

                    Il n'est pas limite, il est tout simplement inutilisable ou plutot moins utilisable qu'il y a +10 ans.

                    Mais Tu n'utilises pas LibreOffice sur une tablette de toute façon

                    Mais le truc c'est que LO etant l'implementation de ref de ODF, si l'implementation est merdique et utilise uniquement pour ecrire une lettre a tata jacqueline ca sert a rien d'avoir un truc aussi lourd. Tu le dis toi meme ca sert a rien au pros et c'est trop lourd pour le particulier. C'est quoi alors le marche vise par LO?

                    Je m'en fous qu'il soit compatible avec Keynote, MS Office etc (pour le dernier on sait deja que cela n'est pas possibel. Apres 20 ans il faudrait un peu avoir le courage de l'admettre) alors autant developper une suite avec ODF mais qui soit bien et utilisable et la le format ODF aura une chance.

                    • [^] # Re: Mouahis

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

                      Mais le truc c'est que LO etant l'implementation de ref de ODF, si l'implementation est merdique et utilise uniquement pour ecrire une lettre a tata jacqueline ca sert a rien d'avoir un truc aussi lourd. Tu le dis toi meme ca sert a rien au pros et c'est trop lourd pour le particulier. C'est quoi alors le marche vise par LO?

                      Je dis qu'il n'est pas utilisé par les gens du business. Mais les pros qui font comme moi un métier technique, ça marche très bien :

                      • pour faire des schémas
                      • pour rédiger des docs utilisateur
                      • pour faire des présentations (bah oui, pour ce que je fais ça marche bien)
                      • pour faire des feuilles de calcul (genre juste des calculs)

                      Accessoirement, je peux utiliser le même outil pour des besoins pro et perso, donc c'est bonus.

                      Je m'en fous qu'il soit compatible avec Keynote, MS Office etc (pour le dernier on sait deja que cela n'est pas possibel. Apres 20 ans il faudrait un peu avoir le courage de l'admettre) alors autant developper une suite avec ODF mais qui soit bien et utilisable et la le format ODF aura une chance.

                      Je pense qu'il y a de très grandes organisations qui l'utilisent de manière importante, par exemple la gendarmerie nationale (je ne fais pas la distinction LibreOffice / OpenOffice, je ne sais d'ailleurs pas ce qu'ils utilisent). Le format ODF a déjà gagné parce qu'il est pérenne, utilisable sur toutes les plateformes (hors mobile), utilisé par de grandes organisations, facile à générer automatiquement et que les 3 années de nettoyage de code peuvent très bien laisser penser que l'application de référence va encore beaucoup évoluer. Pourquoi je dis ça ? Parce que souvent les développeurs sont plus friands de nouvelles fonctionnalités que de maintenance et refactoring. Si on passe 3 ans à faire du refactoring, du nettoyage et de l'amélioration, c'est qu'on a une vision à long terme sur le projet, donc que les développeurs s'y voient encore sur la durée (et donc que des évolutions vont arriver pour "quelques années" encore ).

                      • [^] # Re: Mouahis

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

                        Le format ODF a déjà gagné parce qu'il est […] facile à générer automatiquement

                        Tu aurais quelques liens à partager là-dessus ? Bonnes pratiques, cas d'utilisation, outils, modules ?

                        * Ils vendront Usenet^W les boites noires quand on aura fini de les remplir.

                  • [^] # Re: Mouahis

                    Posté par . Évalué à 4.

                    • [^] # Re: Mouahis

                      Posté par (page perso) . Évalué à 4. Dernière modification le 04/02/14 à 18:09.

                      Sinon le daily build de LibO pour Android. Double combo: évolution OOo → LibO + non-passage par Big Brother pour les espèces de sales libristes comme moi qui n’ont pas de compte Google (ou qui ne veulent pas le relier à leur téléphone).

                      Il y a aussi un liseur ODT sur F-Droid (et le Google Play).

                      Écrit en Bépo selon l’orthographe de 1990

                      • [^] # Re: Mouahis

                        Posté par . Évalué à 1.

                        Je ne connaissais pas, je vais tester

                    • [^] # Re: Mouahis

                      Posté par . Évalué à 2.

                      Je viens de tester et ben c'est … inutilisable c'est une application desktop point barre, il n'y a aucune tentative de modifier l'UI pour la rendre utilisable sur une tablette ne parlons meme pas d'un telephone.

                      C'est un joli exercice technique mais cela ne peut convenir que si tu as une tablette avec clavier+souris (et encore vu que l'acces a pas mal de fonction sont en dehors de la fenetre ou derriere un widget en haut a droite).

                      • [^] # Re: Mouahis

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

                        Ben en même temps, pour faire de la bureautique, sans clavier, comment dire, faut être maso.

                        • [^] # Re: Mouahis

                          Posté par . Évalué à 2.

                          sur les tablettes tu as un clavier mais la souris ce sont tes gros doigts et la dommage avec le truc mais je suis d'accord avec toi sur le principe. Toutefois comme je le disais avant pour faire un changement de derniere minute dans un document cela peut etre utile.

                  • [^] # Re: Mouahis

                    Posté par . Évalué à 3.

                    Mais Tu n'utilises pas LibreOffice sur une tablette de toute façon : les ressources sont plus limitées, donc il faut des performances plus pointues quitte à faire des compromis sur la richesse des fonctionnalités (je ne parle pas de pertinence, hein, mais de richesse).

                    Pour ce qui est du probleme de performance de LibreOffice, ce n'est pas lie du tout a la richesse des fonctionnalites, mais principalement voir meme uniquement a l'architecture archaique de leur code. Ils ont pas mal de chose en cours pour ameliorer les choses et si quelqu'un les sponsorise en 6 mois, tu auras une suite utilisable sur telephone en terme de performance avec le meme niveau de fonctionnalite (D'ailleur avec leur support OpenCL, tu devrais outperformer la concurrence sur le tableur).

                    Par contre le vrai probleme, c'est qu'il faut effectivement faire une interface specifique pour tablette et une autre pour telephone. C'est dans cette optique qu'ils passent a XML pour definir leurs interfaces pour avoir plus de souplesse dans ca definition.

                    En gros le grand nettoyage a des objectifs bien clair sur ou ils vont…

                    • [^] # Re: Mouahis

                      Posté par . Évalué à 2.

                      C'est dans cette optique qu'ils passent a XML pour definir leurs interfaces pour avoir plus de souplesse dans ca definition.

                      Euhhh non ne parlons pas de QML.

                      • [^] # Re: Mouahis

                        Posté par . Évalué à 2.

                        Si tu sous entend qu'ils auraient du passer directement a qml, je pense que ça aurait été un saut trop gros saut et pas forcément de chemin d'évolution progressif.

                • [^] # Re: Mouahis

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

                  Je tiens à signaler que la syntaxe Markdown a une syntaxe pour les citations, qui évite aux gens normaux de finir miros à 25 ans à force de plisser les yeux, sans parler des malvoyants. C’est pas pour rien que l’emphase faible est représentée par de l’italique par défaut sur la quasi-totalité des navigateurs web.

                  Écrit en Bépo selon l’orthographe de 1990

              • [^] # Re: Mouahis

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

                • Combien de dév. sont payés et travaillent à plein temps sur Keynote. Combien sur LibreOffice

                Ca, c'est les moyens, qui est le problème de celui qui propose le produit, et ça n'a rien à faire dans une évalution d'un produit, à part pour les extrémistes qui acceptent un mauvais produit du moment où il a une qualification qui lui plait (libre par exemple).

                Si tu en es à devoir sortir ce genre d'argument, ça laisse penser que tu ne penses pas toi-même que le produit est techniquement bon (sa seule qualité serait qu'il est libre, ouch).

                • [^] # Re: Mouahis

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

                  Je n'argumente pas pour dire que le produit est mieux/moins bien, j'argumente pour dire que comparer Keynote avec LibreOffice ça ne me paraît pas judicieux.

                  Pour moi LibreOffice est bon dans la mesure où c'est un outil unique, qui permet de faire des présentations, des schémas, des feuilles de calculs, des documents mis en page, etc, etc. Je ne pense pas que ce soit le meilleur dans aucune de ces catégories, mais c'est une excellent combinaison (avec un spectre de fonctionnalités très large, donc difficilement compétitif avec des applications dédiés).

                  (et non, je ne suis pas un extrémiste;)

        • [^] # Re: Mouahis

          Posté par . Évalué à 9.

          un truc qui marche mal sur les bureaux KDE

          La faute à qui ? Faut croire qu’aucun dév actuel de LO n’utilise KDE. ;)

          qui stagne sur toutes les fonctionnalites

          N’importe quoi. Depuis que LO existe, quasiment tout ce que j’attendais en termes de fonctionnalités est apparu. Lis les changelogs, tu verras que ça ne stagne pas du tout. Au contraire, LibreOffice, c’est ce qui pouvait arriver de mieux à OpenOffice.org.
          https://wiki.documentfoundation.org/ReleaseNotes/3.5/fr
          https://wiki.documentfoundation.org/ReleaseNotes/3.6/fr
          https://wiki.documentfoundation.org/ReleaseNotes/4.0/fr
          https://wiki.documentfoundation.org/ReleaseNotes/4.1/fr
          https://wiki.documentfoundation.org/ReleaseNotes/4.2/fr

          Pourquoi conserver le vieux toolkits qui s'integre mal partout et fait bien sentir son age. Pourquoi ne pas passer sur le seul toolkit reellement multiplateforme Qt?

          Parce que le toolkit actuel (VCL) est tellement incrusté dans le code qu’on ne peut pas le virer comme ça, d’après ce qu’on m’a dit. Mais ça va venir.

          Je ne parlais pas de changer radicalement l'interface mais d'apporter des ameliorations.

          Ouvre un OpenOffice.org d’avant le fork LibreOffice et compare : les améliorations sont légion, petites touches un peu partout, et loin d’être négligeables, franchement. Ça se voit sur pas mal de boîtes de dialogue et dans plein de détails de l’interface. Bon, je n’utilise pas KDE, je ne sais pas si ça paraît propre. LibreOffice apparaît comme du GTK+, mais sur certaines distribs KDE, ça ne fonctionne apparemment pas, me semble-t-il.

          Quant au nettoyage de code, oui, c’est long, très long, mais ils commencent à voir le bout du tunnel, ça se sent. Plusieurs décennies de dette technique, ce n’est pas rien à nettoyer.

          • [^] # Re: Mouahis

            Posté par . Évalué à 7.

            Ça se voit sur pas mal de boîtes de dialogue et dans plein de détails de l’interface. Bon, je n’utilise pas KDE, je ne sais pas si ça paraît propre

            Moi si, et je ne vois pas ce qu'on peut lui reprocher. Ça juste marche, et les améliorations sont visibles de version en version (ne serait-ce que la rapidité).

            Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

        • [^] # Re: Mouahis

          Posté par . Évalué à 10.

          J'ai bien lu mais bon ca fait plusieurs annees de nettoyage pour arriver a un truc qui marche mal sur les bureaux KDE et qui stagne sur toutes les fonctionnalites. Vu le temps pris pour le nettoyage je me demande si il n'aurait pas mieux valu abandonner le code et repartir d'un truc propre?

          Ha ha ha!
          Abandonner une base de code sur laquelle il y a eu des dizaines (centaines) de millions d'investissement pour repartir de zero?
          Lit ceci: http://www.joelonsoftware.com/articles/fog0000000069.html

          Pour le reste, je ne crois pas que tu comprennes la difficulte et l'enormite de la tache.

          Pourquoi conserver le vieux toolkits qui s'integre mal partout et fait bien sentir son age. Pourquoi ne pas passer sur le seul toolkit reellement multiplateforme Qt?

          Ils attendent ta contribution…

          • [^] # Re: Mouahis

            Posté par . Évalué à 4.

            Pour le reste, je ne crois pas que tu comprennes la difficulte et l'enormite de la tache.

            Et peut-être que tu ne comprends pas la difficulté et l'énormité de la tâche qui consiste à faire évoluer LibreOffice suffisamment pour qu'il soit au niveau de la concurrence :) ?

            • [^] # Re: Mouahis

              Posté par . Évalué à 4.

              (hum, une remarque en passant pour les moinsseurs : je participe au développement de LibreOffice - mais bon, restez avec vos certitudes : puisque Joel Spolsky le dit c'est que c'est vrai il faut toujours conserver le code existant et ne jamais repartir de zéro)

              • [^] # Re: Mouahis

                Posté par . Évalué à 2.

                Pour le reste, je ne crois pas que tu comprennes la difficulte et l'enormite de la tache.

                Et peut-être que tu ne comprends pas la difficulté et l'énormité de la tâche qui consiste à faire évoluer LibreOffice suffisamment pour qu'il soit au niveau de la concurrence :) ?

                Je dois dire que je n'ai pas compris ta blague ni ce qui te fais penser que je sous estime le besoin d'evolution?

                (hum, une remarque en passant pour les moinsseurs : je participe au développement de LibreOffice - mais bon, restez avec vos certitudes : puisque Joel Spolsky le dit c'est que c'est vrai il faut toujours conserver le code existant et ne jamais repartir de zéro)

                Evolution n'est pas revolution.
                Tu as mal compris mon propos ou celui de Joel Spolsky.
                Reecrire une base de code depuis zero est la pire erreur qui peut etre faite.
                Je suis au contraire fan de faire evoluer (meme a grande vitesse, quitte a creer quelques bugs au passage) une base de code existante tout en etant capable de livrer une nouvelle version a tout moment.

                Je suis donc tout a fait content de l'evolution actuelle de LibreOffice, et je dois meme dire que cela m'a attire puisque j'ai soumis quelques patches (acceptes!!) pour supprimer la class UniString.

                 

                Merci a toi pour tes contributions :)

                • [^] # Re: Mouahis

                  Posté par . Évalué à 2.

                  Je dois dire que je n'ai pas compris ta blague ni ce qui te fais penser que je sous estime le besoin d'evolution?

                  Ce n'est pas le besoin d'évolution que je pense que tu sous-estimes, mais la difficulté de faire évoluer LibreOffice tout court (à cause du code, des concepts utilisés, etc).
                  Plus exactement je réagissais à la doctrine que tu reformules dans ton commentaire :

                  Reecrire une base de code depuis zero est la pire erreur qui peut etre faite.

                  Que je trouve absurde quand elle est énoncée comme une vérité absolue.

                  Concernant LibreOffice les développeurs principaux ont choisi l'évolution rapide au prix de quelques régressions, on verra dans quelques années si ce choix est viable ou non.

                  • [^] # Re: Mouahis

                    Posté par . Évalué à 3.

                    Ce n'est pas le besoin d'évolution que je pense que tu sous-estimes, mais la difficulté de faire évoluer LibreOffice tout court (à cause du code, des concepts utilisés, etc).

                    Je ne crois pas que je le sous-estime non.

                    Reecrire une base de code depuis zero est la pire erreur qui peut etre faite.

                    Que je trouve absurde quand elle est énoncée comme une vérité absolue.

                    Je pense et je maintiens que c'est une grosse erreur dans 95-99% des cas de repartir de zero pour TOUT le projet.
                    [apparte: quelqu'un sait-il comment souligner du texte en markdown?]

                    Tu penses reellement que LibreOffice aurait ete plus vite en repartant de zero? (C'est une vraie question)
                    Et est ce que les developpeurs auraient suivi?
                    Est ce que cela aurait attire les contributeurs sachant que les projets libres concurrents sont plethores? (Apache OpenOffice, Caligra, Gnome Office)

                    • [^] # Re: Mouahis

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

                      [apparte: quelqu'un sait-il comment souligner du texte en markdown?]

                      On ne peut pas. Ça évite que des gens comme toi induisent en erreur les gens comme moi qui croient que tout ce qui est souligné est un lien. Parce que sur le web, c’est comme ça, tout ce qui est souligné est lien, en tout cas c’est la règle générale.

                      Écrit en Bépo selon l’orthographe de 1990

                      • [^] # Re: Mouahis

                        Posté par . Évalué à 1. Dernière modification le 05/02/14 à 10:49.

                        Alors je suis oblige de crier ou de faire une emphase ce qui ne correspond pas a la typographie usuelle. :-/

                        • [^] # Re: Mouahis

                          Posté par . Évalué à 7.

                          L'emphase se fait en utilisant l'italique ou, au pire, le graissage des caractères.

                          • [^] # Re: Mouahis

                            Posté par . Évalué à 2.

                            Oui, oui, c'est bien ce que je voulais dire :)

            • [^] # Re: Mouahis

              Posté par . Évalué à 2.

              Et peut-être que tu ne comprends pas la difficulté et l'énormité de la tâche qui consiste à faire évoluer LibreOffice suffisamment pour qu'il soit au niveau de la concurrence :) ?

              Je crois que tu n'as aucune idee de ce que fait la concurrence techniquement ! Un peu comme lors d'une demo, ceux qui compte, c'est les graphismes. A cour terme pour faire croire qu'on fait quelques choses de nouveau, il suffit de changer les icones, les gradients, deplacer et relooker les toolbar. Et tada, tu as des utilisateurs qui sont sur d'avoir quelques choses de neuf !

              Alors que c'est le meme moteur de rendu, le meme coeur de calcul, juste plus lent que la precedente version, car la hierachie de toutes les grosses societes seraient contre la reecriture de ces morceaux critiques ! Or les avances de LibreOffice dans le domaine sont extremement prometteur bien plus que la concurrence. Faire le relooking et etre hype arrivera apres lorsque l'infrastructure sera proprement en place.

              Mais c'est vrai qu'une joli demo, ca a toujours fait plus vendre meme si ca ne fait pas un produit utilisable…

              • [^] # Re: Mouahis

                Posté par . Évalué à 2.

                Je crois que tu n'as aucune idee de ce que fait la concurrence techniquement !

                En effet, par contre j'ai une bonne idée de ce que fait LibreOffice et du temps passé à résoudre des problèmes uniquement causés par du code jamais repris de 0.

                Or les avances de LibreOffice dans le domaine sont extremement prometteur bien plus que la concurrence.

                C'est encore mieux de les lister :)

                De mon côté j'apprécie les progrès de Calc. Je suis beaucoup moins impressionné par l'évolution de Writer (quelles 'avancées' prometteuses ont été réalisées ?) et d'Impress (même question).

        • [^] # Re: Mouahis

          Posté par . Évalué à 1.

          Pourquoi ne pas passer sur le seul toolkit reellement multiplateforme Qt?

          Tu n'a plus que ce mot (Qt) là à la bouche (sic). Tu en rêve la nuit ?

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

    • [^] # Re: Mouahis

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

      Il n'y a strictement aucune avance majeure

      Est-ce qu'on a lu les mêmes notes de version ?
      Pour toi la réécriture complète du moteur de Calc ce n'est pas majeur ?
      Le backend expérimental Firebird SQL de Base à la place de l'immonde HSQLDB ce n'est pas majeur ? Regarde l'écart monstrueux de perf décrit ici : http://www.firebirdnews.org/?p=9109

      • [^] # Re: Mouahis

        Posté par . Évalué à -10.

        Je ne me sers p[as de calc donc non c'est pas majeur pour moi. Ce que je constate c'est que le module impresse, a peu pres le seul truc que j'ai besoin de temps en temps avec l'editeur, est pourrit.

        Mais bon si vous etes content de cela tant mieux mais il ne faut pas se plaindre que MS Office reste dominant.

        • [^] # Re: Mouahis

          Posté par . Évalué à 2.

          Puisque tu fais la fine bouche concernant les "Powerpoint-like", Beamer est fait pour toi… Mais toi, es-tu fait pour Beamer ?

          • [^] # Re: Mouahis

            Posté par . Évalué à 6.

            Je ne sais pas si je suis fait pour beamer mais je m'en sers mais bon parfois (c'est a dire tous les jours) je travaille avec d'autre personne sur des gros projets et nous devons utilise les templates du projet en question et curieusement ils ne sont jamais fournit en format latex…

      • [^] # Commentaire supprimé

        Posté par . Évalué à -2.

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

        • [^] # Re: Mouahis

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

          Ah donc quand ils corrigent les imports foireux de documents OOXML l’utilisateur s'en fout ? Ou pas, car justement ce qu'il veut c'est d'exploiter les documents de Microsoft Office sans forcément le posséder lui même. Et dans ce domaine LibreOffice a donné lieu à psa mal d'amélioration notamment dans cette version.

          C'est loin d'être négligeable.

          • [^] # Re: Mouahis

            Posté par . Évalué à 0.

            les import de document Microsoft OOXML seront TOUJOURS foireux. Le format a ete fait pour. Meme chez Microsoft deux equipes differentes n'arrivent pas avoir le meme resultat.

            Donc oui je m'en fous un peu. Par contre un support parfait de ODF et des ameliorations d'utilisation (par exemple re-rendre untilisable impress) ca c'est pour moi nettement plus important que n'importe quel pseudo compatibilie avec MS Office. Ne revons pas la compatibilite est tellement mauvaise (du a Microsoft comme montre au dessus) que toute personne cense essaye deux fois d'ouvrir un document Microsoft OOXML avec LO et puis apres il ne s'embete plus et il utilise la seule suite qui gere ces fichiers comme il faut c'est a dire Microsoft Office. Ca c'est la vrai vie.

            • [^] # Re: Mouahis

              Posté par (page perso) . Évalué à 5. Dernière modification le 04/02/14 à 18:27.

              Qu’est-ce qui te fais tant haïr Impress? Pour l’avoir utiliser quelques fois, il n’est pas aussi inutilisable que tu sembles le prétendre.

              Ne revons pas la compatibilite est tellement mauvaise (du a Microsoft comme montre au dessus) que toute personne cense essaye deux fois d'ouvrir un document Microsoft OOXML avec LO et puis apres il ne s'embete plus et il utilise la seule suite qui gere ces fichiers comme il faut c'est a dire Microsoft Office. Ca c'est la vrai vie.

              Donc pour que les gens passent de Microsoft Office à LibreOffice, il ne faut faire aucun effort pour pouvoir convertir ses documents? Donc selon toi les gens vont magiquement aller utiliser LibreOffice sans pouvoir utiliser leurs documents?

              Même si le support du OOXML n’est pas très bon (il est vraiment si mauvais que ça?), c’est toujours mieux que tout recommencer de zéro. C’est une stratégie qui me parait quand même cohérente.

              Par contre un support parfait de ODF

              LibreOffice ne supporte pas bien son format principal?

              Écrit en Bépo selon l’orthographe de 1990

              • [^] # Re: Mouahis

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

                Même si le support du OOXML n’est pas très bon (il est vraiment si mauvais que ça?)

                Soyons honnête, non. Même pour des documents assez simples il va y avoir de nombreux problèmes d'affichages. Peut être que la version 4.2 permettra d'améliorer tout ceci avec l'annonce qui en a été faite de ce point de vue.
                D'autant que sous Android par exemple j'ai déjà ouvert quelques documents OOXML en la visualisation simple est déjà de meilleure qualité, presque fidèle à l'original ce qui montre que cet objectif est possible et je leur souhaite le meilleur pour en venir à bout.

                Car comme tu le dis, contrairement au propos précédent, c'est un élément important. Les gens reçoivent de nombreux documents OOXML par l'entourage familial, amical ou professionnel dont on ne choisit pas le format de rédaction. Si certains peuvent se la jouer à la Stallman et exiger des ODF/PDF, ce n'est pas le cas de tout le monde et il est nécessaire que l'outil qu'on utilise s'intègre bien dans cet environnement. Car bon démarrer sous Windows pour lancer Microsoft Office uniquement dans ces cas d'utilisation peut être assez pénible.

                Et quand je vois le nombre de personnes qui critiquent LO car il ne gère pas bien les formats de Microsoft, cela montre que c'est un frein à son adoption (même si en soit le format OOXML devrait être proscrit mais on ne peut pas changer cet état de fait en un claquement de doigt).

              • [^] # Re: Mouahis

                Posté par . Évalué à 0.

                Je trouve cela inutilisable en comparaison de beamer ou de … Microsoft Powerpoint et ne parlons meme pas de keynote.

                Même si le support du OOXML n’est pas très bon

                Pas tres bon??? C'est un euphemisme. La moindre presentation basique en docx est foireuse. Ne serait ce que les titres sont avec la bonne police, la bonne taille et malgre tout cela depasse de partout. Il y a clairement un probleme non? Et sur un truc aussi basique que cela. Le petit truc qui me chagrine c'est que quand je fais une presentation avec Impress et que je l'ouvre avec Calligra c'est tout aussi bordelique. Le probleme vient de l'un ou de l'autre ou du format mal defini pour les presentations? Je ne sais pas. C'est connu mais c'est toujours present et ca rend le truc totalement inutilisable pour bosser en equipe.

                • [^] # Re: Mouahis

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

                  Je trouve cela inutilisable en comparaison de beamer ou de … Microsoft Powerpoint et ne parlons meme pas de keynote.

                  Des exemples, je veux des exemples!

                  Écrit en Bépo selon l’orthographe de 1990

                  • [^] # Re: Mouahis

                    Posté par . Évalué à 1.

                    Essaye de te servir de l'un et de l'autre et tu verras bien. J'en ai marre de batailler pour faire une presentation donc je ne m'en sers plus. Je vais revoir avec 4.2 mais bon deja le template que j'ai passe mal (cf le probleme de police du dessus).

                    • [^] # Re: Mouahis

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

                      Après m'être battu avec PowerPoint et ses copier-coller de schémas foireux, j'ai choisi : Impress vainqueur haut la main. Au moins il ne m'a jamais fait perdre des heures de boulot. Pour moi, il « juste marche » et c'est tout ce qui m'importe.

                      • [^] # Re: Mouahis

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

                        Impress marche bien et s'améliore avec les versions. J'ai une collection de mes conférences dans http://pjarillon.free.fr/docs/conferences/ les premières étaient faites avec StarOffice. Je crois même que la première avait été commencée avec PauvrePoint.
                        J'ai eu des soucis avec le séquencement automatique et avec le changement de fontes entre OS. Mais c'est du passé.

                        J'apprécie énormément la fonction deuxième écran (impeccable avec KDE), qui permet au conférencier d'avoir sous les yeux l'image projetée, les notes, l'image suivante, l'heure et le temps passé.

                    • [^] # Re: Mouahis

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

                      J’ai pas Microsoft Powerpoint. Si je te demande un exemple, c’est aussi parce que je pense que ça pourrait intéresser d’autres personnes. Je crois que je l’ai jamais utiliser, et je peux comprendre que tu ne l’aimes pas, mais bon c’est pas très constructif de répéter que c’est nul.

                      Écrit en Bépo selon l’orthographe de 1990

                      • [^] # Re: Mouahis

                        Posté par . Évalué à 1.

                        je n'ai ni le temps ni l'envie de retester. En gros je faisais depuis des années mes présentations avec latex. Il a fallu que je fasse une présentation pour le boulot avec un truc comme impress. Je m'en étais servi dans le passé sans trop de problème la ce fut une galère sans nom, j'ai par la suite du en faire une avec MS Office et l'expérience a été beaucoup moins douloureuse. Je n'ai pas de truc spécifique et particulier sinon j'aurai rempli des bugs comme d'habitude. Il y a un gros problème d'utilisation générale (a mon avis). Et je lis les "changelog" c'est vraiment très très rare de voir des modifs dessus.

                        • [^] # Re: Mouahis

                          Posté par . Évalué à 1.

                          Je suis recemment passer de LO a LaTeX pour a peu pres tout. Le sentiment de liberation que j'ai ressenti en comprenant que creer des documents pouvait etre autre chose qu'un douloureux calvaire est magnifique. Je n'ose pas imaginer l'inverse. Je suis desole pour ce que tu as du subir.

          • [^] # Re: Mouahis

            Posté par . Évalué à 1.

            J'ai oublie de dire que en fais si LO avait pris du temps de changer l'UI sous windows ca ressemble a du Windows 8. Comme quoi c'est faisable!

            • [^] # Re: Mouahis

              Posté par . Évalué à 1.

              Je viens d'installer la version 4.2 sous linux et c'est genial lorsque tu demarres LO cela t'ouvre une fenetre style windows 8. Non je prefere rien dire la!

        • [^] # Re: Mouahis

          Posté par . Évalué à 10.

          Pour toi la réécriture complète du moteur de Calc ce n'est pas majeur ?

          Non. Niveau utilisateur, ca change rien. Ca marche pareil qu'avant, (ou pas, mais on s'ee fout, un bug doit etre corrige, que ca soit par un nouveau moteur ou pas)

          Sauf si ca permet de corriger de nombreux bugs dans le futur et d'accelerer l'ajout de nouvelles fonctionnalites.

          Le backend expérimental Firebird SQL de Base à la place de l'immonde HSQLDB ce n'est pas majeur ?

          Non plus, l'utilisateur s'en bat les roubignoles.

          Qui es tu pour parler au nom de tous les utilisateurs?
          Pour autant que je sache tu n'es qu'un unique utilisateur.

          Peut etre que tu ne fais que des petits tableurs alors tu t'en moque, mais ceux qui ont des gros tableurs doivent y voir un interet eux.
          L'utilisateur n'en a rien a foutre d'amelioration

          Pour rappel: ceci est une suite bureautique destinee aux utilisateurs finaux.
          Tout ce qui est derriere l'interface et un detail sans importance.

          Si tu n'en a rien a foutre, pourquoi lire et commenter les changelogs techniques?
          Ne le fais pas, tout le monde t'en remerciera.

          • [^] # Commentaire supprimé

            Posté par . Évalué à -5.

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

            • [^] # Re: Mouahis

              Posté par . Évalué à 10.

              Un utilisateur se fout de la methode.

              En même temps, "un utilisateur" aurait dû s'arrêter là où il est écrit que cette version est réservée aux experts et pas pour lui. Comme ça il ne se serait pas offusqué que les notes de version parlent de trucs dont il se fout.

              Et je suis loin d'etre le seul a penser que les details techniques n'ont rien a foutre dans les notes de version destinees a tout le monde.

              Ça tombe bien parce que ce n'était pas destiné à tout le monde.

              • [^] # Commentaire supprimé

                Posté par . Évalué à -5.

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

                • [^] # Re: Mouahis

                  Posté par . Évalué à 7.

                • [^] # Re: Mouahis

                  Posté par . Évalué à 7.

                  En dehors de l'énorme message dans la page de téléchargement mis en lien ci-dessus, tu peux également lire la dépêche aussi loin que la deuxième phrase.

                  • [^] # Commentaire supprimé

                    Posté par . Évalué à -9.

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

                    • [^] # Re: Mouahis

                      Posté par . Évalué à 2.

                      Non, car les notes de versions en question décrivent les nouveautés apportées par la branche 4.2. Elles sont présentées à l'occasion de la sortie de la 1ère mouture 4.2.0 de cette branche 4.2. C'est cette première mouture qui est conseillée seulement aux utilisateurs avancés.
                      Ensuite nous auront des mises à jour correctives qui ne font que corriger des bugs sans nouvelle fonctionnalité. En général à partir de la 2e ou 3e mise à jour corrective la version est recommandée pour tous les utilisateurs.

  • # Bugzilla

    Posté par . Évalué à 1.

    J'ai fait un tour dans les "easy hacks", ce qui me semble être une bonne idée pour attirer les contributeurs. Le problème est que ça redirige vers des tickets Bugzilla, et l'interface est tellement dégueulasse sur tous les plans qu'elle me rebute à chaque fois (même pour poster un bug)…

  • # Version portable

    Posté par . Évalué à -4.

    Et encore une fois pas de version portable de base.

    Grrr… quand est-ce que les développeurs comprendront que NOUS NE VOULONS PLUS D'INSTALLATEURS ET D'INSCRIPTIONS DE CLES DANS UNE BASE DE REGISTRE !

    Une application utilisateur ça s'installe en userspace et ça ne doit A AUCUN MOMENT nécessiter de droits d'admin.

    • [^] # Re: Version portable

      Posté par . Évalué à 5.

      Personnellement, je ne suis pas d'accord.

      Installer des logiciels est une opération administrateur. La base de registre a beau être une abomination, c'est un moyen de maintenir une base de donnée des logiciels installés pour pouvoir centraliser leur administration, notamment leur désinstallation.

      Aussi, un installeur permet de générer les raccourcis utiles, simplement en cochant une case (et ça ne nécessite pas de droits admin).

      Accessoirement, merci d'éviter DE CRIER.

      • [^] # Re: Version portable

        Posté par . Évalué à 2.

        Ca c'est la théorie de celui qui a son PC et les droits dessus. La pratique c'est qu'on utilise souvent un ordinateur sans droits administrateurs, par exemple dans les ordinateurs partagés des facs et écoles. Dans ce cas, pas de version portable signifie pas d'installation possible. C'est pour moi un bug critique.

        • [^] # Re: Version portable

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

          Si tu travailles dans un environnement conçu pour te fournir des outils choisis et t'empêcher d'en utiliser d'autres et que ça ne te convient pas, ce n'est pas aux développeurs de LibO qu'il faut t'en plaindre.

          • [^] # Re: Version portable

            Posté par . Évalué à 4.

            L'environnement ne m'empêche pas d'en utiliser d'autre, je peux lancer n'importe quel .exe téléchargé depuis internet. Il m'empêche juste d'utiliser un compte administrateur, ce qui est plutôt sain, car cela protège les comptes de mes voisins. Ce qui n'est pas sain c'est qu'un logiciel comme un traitement de texte devrait être non intrusif et ne pas me demander les clefs de mon ordinateur pour s'installer.

            • [^] # Re: Version portable

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

              Tiens, cadeau : http://live.debian.net/cdimage/release/stable/amd64/iso-hybrid/

              C'est un système qui peut être installé sur une clef USB ou un DVD, qui fonctionne de façon non intrusive et contient LibreOffice.

              • [^] # Re: Version portable

                Posté par . Évalué à 5.

                Merci, je connais. Ce n'est pas le problème. Je ne veux pas installer un nouveau système, je veux utiliser le système qui m'est fourni et qui me permet de lancer des applications, tant que celles-ci ne demandent pas des droits exubérants.

                • [^] # Re: Version portable

                  Posté par . Évalué à 1. Dernière modification le 05/02/14 à 12:24.

                  Je ne comprends pas : pourquoi vouloir utiliser absolument le système qui t'est fourni mais pas les applications qui le sont ?

                  Quitte à vouloir une application précise, changer d'OS ne devrait pas être un problème si celle-ci est la même partout et résout ton problème.

                  Au passage, un LiveCD/USB est beaucoup moins intrusif. Qu'est-ce qui gène dans cette démarche ?

                  Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                  • [^] # Re: Version portable

                    Posté par . Évalué à 5.

                    Car l'environnement qui m'est fourni me convient dans 95% des cas. J'ai accès aux documents partagés, à des logiciels propriétaires dont j'ai besoin, il est relativement sûr, je n'ai pas à m'en occuper. Pour les 5% restants il me manque de pouvoir utiliser une suite bureautique libre et récente. C'est pour moi un besoin auxiliaire mais non négligeable.

                    Par ailleurs la solution du live CD est un cache misère. Je sais que ça existe, je sais l'installer, mais ce n'est pas le cas de la grande majorité des utilisateurs de LOO. C'est dommage de perdre un grand nombre d'utilisateurs pour un choix technique contestable. Ça fait autant de documents non compatibles de créés.

                  • [^] # Re: Version portable

                    Posté par . Évalué à 0. Dernière modification le 05/02/14 à 13:05.

                    Édit : doublon

          • [^] # Re: Version portable

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

            Si tu travailles dans un environnement conçu pour te fournir des outils choisis et t'empêcher d'en utiliser d'autres et que ça ne te convient pas, ce n'est pas aux développeurs de LibO qu'il faut t'en plaindre.

            D’après mon expérience personnelle, pour un service de l’établissement qui ne fonctionne pas bien, il faut batailler auprès des administrateurs système incompétents pour qu’ils admettent que si ça marche bien pour eux, ça n’est pas forcément le cas pour tout le monde, et daignent jeter un coup d’œil.

            Et je ne parle pas de l’impossibilité de développer pour Android avec les outils préinstallés dans le cours de programmation sur Android (obligé de choper un bundle, donc une version portable).

            Écrit en Bépo selon l’orthographe de 1990

        • [^] # Re: Version portable

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

          "Bug, c'est un peu violent, un bug étant une réaction du logiciel qui ne fait pas ce que le développeur attendait, de mon point de vue en tous cas. Pourquoi ne pas parler tout simplement de fonctionnalité manquante?

        • [^] # Re: Version portable

          Posté par . Évalué à 2.

          Il y a peut-être une bonne raison pour que tu n'ais pas les droits dessus ? Genre éviter que tout le monde installe n'importe quoi n'importe où sur le parc informatique de l'organisation ? ou parce que les admin ont un système plus évolué que « suivant, suivant » pour déployer des logiciels et leurs mises à jours ?

        • [^] # Re: Version portable

          Posté par . Évalué à 4.

          Il y a une version portable pour LibreOffice 4.1.4 téléchargeable depuis le site LibreOffice.
          Sachant l'avertissement sur le public auquel la 4.2.0 est destinée, une version portable pour cette version là n'a rien d'urgent.

    • [^] # Re: Version portable

      Posté par . Évalué à 10.

      NOUS NE VOULONS PLUS D'INSTALLATEURS ET D'INSCRIPTIONS DE CLES DANS UNE BASE DE REGISTRE !

      Bah installe le sous Linux :-)

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

      • [^] # Re: Version portable

        Posté par . Évalué à 2.

        Et encore sans Gnome et son horrible Gconf. Comment ont-il pu faire cette… horreur.

        Enfin vu que je n'aimais déjà pas Gnome à la base ce n'est pas vraiment un problème :-)

        • [^] # Re: Version portable

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

          D’abord maintenant c’est dconf!

          Je me garderais de faire tout jugement de valeur sur l’intérêt de dconf, néanmoins je pense que le problème principal pour ceux qui commencent à y toucher, c’est que c’est le bordel et qu’on a aucune idée d’où peut bien se trouver telle ou telle propriété. Sinon je crois qu’il n’y a pas d’indication sur ce à quoi sert telle ou telle propriété, alors que dans dconf c’est affiché. On peut aussi remettre la valeur par défaut.

          Ah, et on peut difficilement rendre son système inutilisable en touchant à dconf j’ai l’impression. En touchant un peu au registre sous Windows, j’ai supprimé l’association «.exe» → exécutable, je ne pouvais même plus lancer le registre pour réparer ma connerie (vive les machines virtuelles).

          Écrit en Bépo selon l’orthographe de 1990

          • [^] # Re: Version portable

            Posté par . Évalué à 2. Dernière modification le 05/02/14 à 12:26.

            La même idée a été reprise par XFCE avec xfconf. Mais bizarrement quand c'est GNOME qui implémente c'est une mauvaise idée, mais si c'est XFCE ça va, c'est pas criticable.

            Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

            • [^] # Re: Version portable

              Posté par . Évalué à 2.

              Peut-être parce que xfconf, plutôt que d'utiliser une base de données, utilise des fichiers XML (plus lent, mais facilement modifiable avec un éditeur texte, même si il y a aussi le programme xfconf-query en cli et la GUI pour xfconf), comme le faisait GConf.

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

              • [^] # Re: Version portable

                Posté par . Évalué à 5.

                GConf utilisait aussi des fichiers xml. Mais ça n'a pas empêché les gens de critiquer, au contraire.

                Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                • [^] # Re: Version portable

                  Posté par . Évalué à 4.

                  A juste titre d'ailleurs car de nombreuse personne avait predit que le fait de cacher les options dans gconf les ferait a long terme disparaitre ce qui est le cas dans Gnome3.

                  • [^] # Re: Version portable

                    Posté par . Évalué à 2. Dernière modification le 05/02/14 à 14:18.

                    D'une part : source ? Qui a prédit ça et où ?

                    D'autre part : non les options ne disparaissent pas puisqu'il y a dconf aujourd'hui.

                    Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                    • [^] # Re: Version portable

                      Posté par . Évalué à 2.

                      Comment vais je trouver un lien sur quoique ce soit a ton avis? Et oui comme toi, en ouvrant une tab sur un moteur de recherche et chercher cela. Donc comme je suis feignant, pas comme toi, je te laisse le soin de chercher ca.

                      Sinon je pense que tu as du rate quelques episodes sur Gnome3… Allez prenons un exemple, tu fais comment pour diviser en deux une fenetre de nautilus? Parceque meme si l'option n'est plus visible dans l'UI mais uniquement dans dconf ca va etre difficile a la faire marcher sans le code :)

                  • [^] # Re: Version portable

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

                    On peut se passer de Xconf pour configurer, et surtout les noms des catégories ne sont pas abscons. C'est peut-être aussi parce qu'il n'y a pas beaucoup de clés.

                    Écrit en Bépo selon l’orthographe de 1990

    • [^] # Re: Version portable

      Posté par . Évalué à 1.

      Et encore une fois pas de version portable de base.

      La version portable n'est pas faite par LibreOffice.

    • [^] # Re: Version portable

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

      NOUS

      qui "nous"? toi et un pote?

    • [^] # Re: Version portable

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

      NOUS NE VOULONS PLUS D'INSTALLATEURS ET D'INSCRIPTIONS DE CLES DANS UNE BASE DE REGISTRE !

      C'est quoi ces trucs dont tu causes en hurlant comme un goret ?

      * Ils vendront Usenet^W les boites noires quand on aura fini de les remplir.

      • [^] # Re: Version portable

        Posté par . Évalué à 1.

        C'est une manière de travailler qui me dérange depuis plusieurs années. Celle d'associer des types de fichiers à des programmes-type. Et ça passe entre autres par une base de registre qui associe l'extension de fichier avec un programme pour l'action "ouvrir". Je déteste cette manière de faire. on me rétorquera que c'est plus rapide et pratique de double-cliquer sur un fichier mais ça me déplaît profondément. Donc je crie :-p

        • [^] # Re: Version portable

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

          KDE a le même comportement sans base de registre.

          « 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

  • # Reculer un peu pour mieux avancer

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

    Merci pour cette traduction.
    Je trouve que c'est Très bonne démarche de l'équipe de développement d'avoir rendu le développement plus conviviale à la communauté, et d'avoir solidifié les briques du développement et simplifié la maintenance.
    Je suis certains que ça sera payant à l'avenir, visiblement c'est déjà le cas avec des "incrits non affilié" plus nombreux.

  • # Outch – lancem*hock*lancem*hock*lancem*hock*…

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

    Compilé, lancé sans avoir installé… tourne en boucle en relançant frénétiquement la petite fenêtre de chargement :( Ptêtre loupé quelque chose, sais pas. Quelqu’un dans le même cas ?

    Love – bépo

  • # Stabilité perfectible

    Posté par (page perso) . Évalué à 2. Dernière modification le 09/02/14 à 16:03.

    Je ne critique pas gratuitement LibreOffice que je trouve formidable et que j'utilise exclusivement, mais je voulais juste partager cette expérience personnelle :
    Sur ma machine perso sous Debian Sid avec LibreOffice du dépôt Sid et Firefox Aurora du dépôt Mozilla, Firefox Aurora (avec pas mal d'extensions et d'onglets ouverts, mais pas de plugins type Flash) ne plante quasiment jamais (je ne me souviens pas d'un plantage) alors qu'il arrive que LibreOffice plante de temps en temps (sans conséquences, grâce à la boite de dialogue de récupération qui fait le job).
    Là ça vient de m'arriver avec 3 petits documents ouverts, pourtant créés par moi-même sous LibreOffice.
    J'espère que ce point s'améliorera au fur et à mesure de l'appropriation et du nettoyage du code.

    • [^] # Re: Stabilité perfectible

      Posté par (page perso) . Évalué à 2. Dernière modification le 09/02/14 à 17:32.

      Perso j’ai jamais eu de problèmes de ce type sur les documents. Par contre, chercher des mises à jour pour une extension plante systématiquement LibreOffice 4.1 (je vais faire un rapport de bug).

      Et sur leur nouveau site, «Download LibreOffice Now» cache le texte (ou les images) en fonction des «diapos».

      Écrit en Bépo selon l’orthographe de 1990

      • [^] # Re: Stabilité perfectible

        Posté par . Évalué à 1.

        Je ne reproduis pas de tels plantages, ni avec la 4.1 ni avec la 4.2. Mais je n'utilise pas la version fournie par ma distribution Linux (Ubuntu).
        La version officielle de TDF contient un paquet libobasis4.1-onlineupdate. Si ce paquet n'est pas installé, la mise à jour des extensions marche évidemment moins bien. Apparemment ce paquet n'existe pas chez Ubuntu. Je ne sais pas si cela signifie que la fonction n'est pas installée par Ubuntu (c'est faisable, on peut compiler LibreOffice sans cette fonction) ou si elle est packagée autrement. Je ne sais pas ce qu'il en est pour les autres distributions.
        En conclusion, le rapport de bug est peut-être à faire sur le bugtracker de ta distribution et non sur celui de LibreOffice.

        • [^] # Re: Stabilité perfectible

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

          Vu que Arch Linux patch que dalle habituellement, à mon avis faut que je m’adresse directement à LO.

          Écrit en Bépo selon l’orthographe de 1990

    • [^] # Re: Stabilité perfectible

      Posté par . Évalué à 1.

      Problème coté Debian ou coté LibreOffice ? Pour le savoir il faudrait installer la version Linux générique fournie par le site LibreOffice et voir si celle-là plante de la même façon.

Suivre le flux des commentaires

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