Michael Meeks est un hacker qui travaille sur la suite bureautique LibreOffice pour l'éditeur SUSE.
Il vient de publier sur son blog une longue introduction à certaines nouveautés méconnues de la version 4.1 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 post.
Vous trouverez donc dans la suite de la dépêche une traduction du texte de Michael.
Sommaire
- Sous le capot de la Beta LibreOffice 4.1
Sous le capot de la Beta LibreOffice 4.1
Nous allons sortir LibreOffice 4.1 très bientôt - en ce moment nous sommes en phase Beta et nous apprécierions que des gens aident pour les tests. Vous pouvez télécharger les builds depuis les pré-versions ou bien, si vous préférez les trucs très frais, depuis les dev-builds.
Nous sommes encore en train de rédiger la liste complète des nouveautés et des remerciements. Bien entendu nous avons déjà un certain nombre de nouveautés visibles ici avec les crédits associés. Cor a écrit une paire d'entrées sur son blog à propos des améliorations de l'interface et de la fonction d'album photo qui seront intégrés dans cette 4.1.
Cela m'a fait penser aux nombreux développeurs qui ont travaillé extrêmement dur sur des choses qui sont sous le capot, qui ne sont pas vraiment visibles mais qui sont pourtant vraiment importantes. Je voudrais expliquer ici certaines de ces nouveautés (en créditant l'employeur du développeur quand il y en a un). Souvent ce sont des choses assez simples et qui semblent triviales quand on les regarde isolément mais, prises ensembles, elle donnent une base de code qui est bien plus simple à aborder et sur laquelle on peut contribuer plus facilement.
Build system: configure / make
Depuis des années l'une des tâches qui irritent et qui bloquent le plus les nouveaux développeurs voulant travailler sur la base de code est notre système de build. Au démarrage de LibreOffice il y a eu une transition incomplète vers GNU make ce qui nous a obligé à utiliser à la fois l'horrible dmake ainsi que gnumake avec configure utilisant un script Perl pour générer un script shell configurant un ensemble de variables d'environnements qui doivent être utilisées dans votre shell pour que ça compile (ce qui rend impossible la reconfiguration depuis ce shell). Il y a également un script de build en Perl qui fait de la compilation en batch avec deux niveaux de parallélisme.
Au final ça ressemble à un truc comme ça:
Le vieux système bien horrible
autoconf
./configure --enable-this-and-that
source LinuxIntelEnv.Set.sh
./bootstrap
cd instsetoo_native
build --all
Grâce aux efforts enthousiastes de Björn Michaelsen (Canonical), David Tardon (Red Hat), Peter Foley, Norbert Thiebaud, Michael Stahl (Red Hat), Matúš Kukan, Tor Lillqvist (SUSE), Stephan Bergmann (Red Hat), Luboš Luňák (SUSE), Caolán McNamara (Red Hat), Mathias Bauer (Oracle), Jan Holesovsky (SUSE), Andras Timar (SUSE), David Ostrovsky, Hans-Joachim Lankenau (Oracle) et d'autres—(plus de details) les 126 000 cibles et les 1 700 makefiles sont maintenant complètement convertis vers GNU make. Cela permet d'utiliser la syntaxe suivante qui est bien plus simple:
Le configure & make actuel pour LibreOffice
./autogen.sh --enable-this-and-that
make
Plus de pollution de shell, plus de script de « bootstrap », plus de wrapper Perl, plus de vieux « dmake » sur le chemin. Que des fichiers GNU make classiques —avec un niveau incroyable de parallélisme puisqu'après la génération des headers, nous pouvons utiliser des milliers de processeurs.
C'était un boulot bien précis avec un objectif bien spécifié, comme le processus de retrait du code mort que nous avons effectué dans les versions précédentes, et c'est maintenant terminé. Cela libérera les développeurs qui pourront faire des trucs plus intéressants par la suite.
Système de Build: make dev-install
LibreOffice, contrairement à beaucoup d'autres logiciels, est entièrement re-localisable : vous le balancez où vous voulez, et l'exécutez à partir de là. Nous utilisons un make-dev-install pour créer une installation dans install/ que vous pouvez exécuter dans l'arbre de compilation. Ce processus était traditionnellement effectué par un script Perl utilisant un ensemble compliqué de règles pré-traitées, pour réaliser ce qui est (essentiellement) une opération de copie. David Tardon a fait le gros travail de bouger ça vers l'utilisation de listes de fichiers qu'on génère automatiquement. Donc, aujourd'hui, nous avons un instdir/ top-niveau (sur lesquelles opèrent ces listes de fichiers) qui commence à refléter l'install : l'idée étant que la phase make install tourne à l'intérieur de l'arbre de compilation. Jusqu'à présent, nous avons plus de 250 listes de fichiers, gérant près de 20k fichiers.
Cette initiative facilite grandement l'ajout ou la suppression de fichiers d'installation, et élimine un tas de zip/unzip de jeux de fichiers utilisés pendant la compilation, accélérant le packaging et la compilation : Le packaging du SDK est passé de 90 secondes à environ 30 secondes, en éliminant plein de règles scp2/. L'espoir est que lorsque ce sera fini nous aurons une suite office qui est exécutable out-of-the-box après un make, sans la phase supplémentaire d'installation.
Nettoyage du code
Un énorme boulot a été fait là pour rendre le code-base plus facile à comprendre. Ça rend la lecture du code plus rapide et facile, permet de le vérifier, de comprendre le "flux" pour ajouter des fonctions et réparer des bugs.
Des includes propres
Dans les sombres vieux jours chaque module avait un répertoire inc/<module> intégré, où étaient cachés ses fichiers d'include externes. Pendant la compilation de chaque module, ces fichiers étaient copiés vers d'autres répertoires « artifacts » (le « solver ») et le module suivant était compilé à partir de ces copies. Ça posait plein de problèmes avec les débuggeurs qui identifiaient des copies des en-têtes, des débutants éditant les mauvais (solver) en-têtes, des problèmes de performance sous Windows, et plus. Donc merci à Bjoern Michaelsen, Matúš Kukan et Michael Stahl pour avoir migré tous les ent-êtes dans un dossier unique include à la racine, et nettoyer les makefiles pour rendre tout ça plus propre.
Nettoyage des outils
Le module tools/ était plein de fonctionnalités dupliquées et inutiles ; dans ce cycle nous avons retiré une abstraction complète du système de fichiers en la virant du code, grâce à Tomas Turek, Krisztian Pinter, Thomas Arnhold, Marcos Paulo de Souza & Andras Timar. Il est toujours bon pour la sécurité de retirer encore un énième code redondant et multi-plateforme de création temporaire sécurisée de fichier.
Nettoyage des chaînes
Nous avons continué à faire de bon progrès vers l'objectif consistant à retirer la classe obsolète UniString avec des retraits de méthodes effectuées par Jean-Noël Rouvignac & Caolán McNamara. De plus Lubos Lunak a procédé à une suppression de masse des préfixes des espaces de noms rtl:: pour le code de OUString et OString. Cela rend ce code plus lisible avec d'autres améliorations sur la propreté et les performances.
Un grand nombre d'appels de fonctions ont été changés de UniString vers OUString, ont vu leur macro inutile RTL_USTRING_CONSTASCII retiré et utilisent maintenant des moyens plus rapides pour concaténer les chaînes.
Merci à : Olivier Hallot, Christina Rossmanith, Stephan Bergmann, Chris Sherlock, Peter Foley, Marcos Paulo de Souza, José Guilherme Vanz, Jean-Noël Rouvignac, Markus Mohrhard, Ricardo Montania, Donizete Waterkemper, Sean Young, Thomas Arnhold, Rodolfo Ribeiro Gomes, Lionel Elie Mamane, Matteo Casalin, Janit Anjaria, Noel Grandin, Tomaž Vajngerl, Krisztian Pinter, Fridrich Strba (SUSE), Gergő Mocsi, Prashant, Ádám Csaba Király, Kohei Yoshida—et aux autres que j'ai raté dans les logs (envoyez moi un mail).
Enregistrement des composants
Noel Grandin continue sa quête indomptable pour nettoyer tous les appels créant des composants avec les nouveaux "service constructors", et toutes les améliorations qui vont avec. Cela représente environ deux cents cinquante commits dans cette 4.1
Travail sur la qualité du code
La moins visible des améliorations est peut-être celle qui retire des bugs provoquant des plantages. Il est clair que le but est de ne jamais planter, mais comment y arriver ? Markus Mohrhard a travaillé sur un ensemble de tests automatisés qui chargent plus de vingt-quatre mille fichiers différents —les plus vicieux et mal-formés que nous puissions trouver en écumant les tréfonds du bugzilla. Il y a eu un gros travail de Markus, Fridrich Strba (SUSE), Michael Stahl, Eike Rathke (Red Hat) pour corriger tous les bugs trouvés. Nous espérons que nos utilisateurs apprécierons de voir encore moins souvent la fenêtre moche signalant un crash.
Une autre source significative d'améliorations est l'utilisation des techniques d'analyse statique pour améliorer la qualité du code, et donc sa fiabilité. Durant ce cycle une équipe a enquêté de façon systématique sur les données générées par l'outil coverity. Il en a résulté presque trois cents commits pour lesquels nous devons remercier Markus Mohrhard, Julien Nabet, Norbert Thiebaud, Caolán McNamara, Marc-André Laverdière (TCS), et bien d'autres.
Il faut aussi ajouter les plus de soixante-cinq corrections de Julien Nabet et issues de l'outil intégré cppcheck. Enfin nous continuons d'utiliser Clang et les plugins très utiles de Lubos pour détecter et retirer le mauvais code dès qu'il apparait.
Un autre outil qui s'est amélioré est bibisect puisqu'il permet d'avoir un dépôt git avec les binaires contenant les dernières dizaines de commits ayant été intégrés. C'est fort utile pour les utilisateurs/testeurs qui peuvent ainsi trouver très précisément à quel moment un bug a été introduit en bissectant de nombreux binaires dans le même dépôt git.
Merci à Bjoern Michaelsen et au labo qualité de Canonical pour les serveurs de build.
Nous avons aussi ajouté et vérifié de nouveaux tests unitaires dans LibreOffice 4.1, afin d'éviter les régressions dans le code. C'est assez difficles à mesurer parce que les gens aiment empiler de nouveaux tests dans les modules de tests unitaires qui existent déjà. En greppant sur la macro d'enregistrement CPPUNIT_TEST on peut constater l'ajout d'à peu près une centaine de tests dans la 4.1 —la majorité pour Calc mais aussi pour Writer, Chart2, la connectivité et Impress.
Merci à Miklos Vajna (SUSE), Kohei Yoshida (SUSE), Noel Power (SUSE), Markus Mohrhard, Luboš Luňák, Stephan Bergmann, Michael Stahl, Noel Grandin, Eike Rathke, Julien Nabet, Caolán McNamara, Jan Holesovsky, Thomas Arnhold, Tor Lillqvist, David Ostrovsky, Pierre-Eric Pelloux-Prayer (Lanedo), Christina Rossmanith et les autres qui ont travaillé sur ces tests.
Refonte du cœur de Calc
Une des raisons pour lesquelles Calc a eu besoin de tests unitaires systématiques pour le code qui n'était pas couvert, c'est qu'un travail de re-factorisation profond est en cours au cœur du module. Depuis plusieurs années Calc est architecturé autour de l'illusion qu'un tableur est constitué de cellules - ce qui a créé de nombreux problèmes de performances et de passage à l'échelle. Le but final de ce travail de refonte est de se débarrasser définitivement de ScBaseCell et de passer à un stockage de données contiguës d'un type uniforme au niveau de la colonne. Les débuts de ce travail sont présents dans la 4.1 mais pour en percevoir les bénéfices il faudra attendre au moins jusqu'à la 4.2 ou même les versions suivantes où nous pourrons faire le travail d'ajustement pour utiliser au mieux cette nouvelle structure de stockage des cellules.
Le but dans cette 4.1 est d'éviter toute régression visible en terme de performances, peut-être même de gagner un peu en terme de rapidité et de réduction de l'empreinte mémoire dans certaines zones. Mais le plus important c'est la meilleure maintenabilité du code du fait de la séparation entre le mécanisme d'utilisation des cellules et du système de stockage lui-même. Merci à Kohei Yoshida pour son excellent travail sur ce sujet.
Traduction des commentaires en allemand
C'est toujours encourageant de faire des statistiques à ce sujet. Dans ce cycle nous avons traduit en anglais près de cinq mille commentaires qui étaient en allemand. Cela aide les nouveaux développeurs à débuter sur le code, à le comprendre et à travailler plus rapidement. Le graphique (approximatif puisqu'il peut y avoir quelques faux positifs) ressemble à ça :
Avec de nombreux remerciements à Urs Fässler, Christian M. Heller, Philipp Weissenbacher, Luc Castermans, David Verrier, Chris Sherlock, Joren De Cuyper, Thomas Arnhold, Philipp Riemer, et d'autres. De l'aide est attendue de la part des locuteurs allemands pour traduire les derniers seize mille commentaires. C'est juste une question de télécharger le code et de lancer bin/find-german-comments sur un module, de traduire quelques lignes et d'envoyer par mail un git diff à libreoffice At lists.freedesktop.org (pas besoin de s'inscrire).
Portage Python des assistants
Java demeure un environnement excellent, sans doute la solution privilégiée pour écrire des extensions multi-plateformes. Tout le support et les API de Java restent disponibles comme ils l'étaient avant. Ceci dit Java n'est pas disponible sur certaines plateformes et, en conséquence, l'utilisation de notre runtime Python interne peut se révéler judicieux pour construire de nouvelles fonctions.
Cette version 4.1 apporte la conversion en Python des assistants précédemment en Java (qui sont accessibles sous Fichier -> Assistants). Cela devrait apporter des bénéfices tangibles aux utilisateurs Windows qui n'ont pas la chance d'avoir un JRE installé. Merci à Xisco Fauli et Javier Fernandez (Igalia).
Édition des liens et démarrage
Une des fonctions clés nécessaire pour faire tourner les prototypes LibreOffice sous Android et iOS est la possibilité de lier tout notre code au sein d'une unique bibliothèque partagée (Android) ou d'un unique exécutable (iOS). Ce travail est utilisable avec l'option de configuration --enable-mergelibs —qui agrège la majorité du code générique de LibreOffice au sein d'une seule bibliothèque partagée. Cela a été fait en collaboration avec Mozilla et c'est de plus en plus le choix par défaut des builds effectués par les distributions Linux puisque cela autorise des gains en terme de démarrage à froid. Du travail reste à réaliser en terme de réorganisation du code et de compilation guidée par des profils (PGO) afin d'améliorer encore plus les performances au démarrage.
Merci à Matus Kukan (pour la Raspberry Pi Foundation) et à Tor Lillqvist pour leur travail.
Une autre fonctionnalité liée aux performances qui a été financée par la Raspberry Pi foundation est la réduction des données de configuration qui sont analysées sans raison au moment du démarrage. Une des belles avancées dans ce domaine a consisté à retirer de la configuration plus de quatorze mille lignes de données d'impression d'étiquettes. L'analyse de ces lignes se fait maintenant quand quelqu'un a réellement besoin d'imprimer des étiquettes. Merci encore une fois à Matus Kukan pour ça.
Nouveau format de type
L'interface de programmation qui est utilisé dans LibreOffice a besoin d'une information sur le type, en particulier pour tout ce qui est scripting. Dans le passé cette information était stocké dans une base de données binaire au format vraiment antique et inefficace. Grâce à Stephan Bergmann (Red Hat) nous avons maintenant un tout nouveau format binaire plus efficace et compressé ce qui permet à notre offapi.rdb de passer de 6,5 Mo à 0,65 Mo. Plus de détails dans cette conférence FOSDEM. À l'heure actuelle ce format est seulement utilisé pour des informations internes et privées, nous prévoyons de rester complètement compatibles avec les extensions qui se basent sur l'ancien format.
La documentation sur ce format est disponible dans l'arbre des sources. De nos jours nous avons de la documentation détaillée dans le fichier README de chaque module.
Divers
D'autres endroits du code où il y a eu des améliorations :
Temps
La résolution des types de données liés au temps dans UNO (l'API de LibreOffice) a été portée jusqu'à la nanoseconde alors qu'elle était auparavant limitée au centième et à la milliseconde. C'est surtout utile dans Base puisque LibreOffice ne tronquera plus les timestamps au centième de seconde ni les durées au millième pour les données utilisateur. Merci à Lionel Elie Mamane.
Base
Dans un formulaire, DatabaseListBox expose maintenant les valeurs sélectionnées (au lieu des chaînes qui sont affichées) à l'interface de scripting. Là encore des remerciements pour Lionel Elie Mamane.
Migration de l'interface vers Glade XML
La migration de l'interface vers des fichiers XML Glade a continué à un bon rythme avec des contributions de nombreux développeurs. Nous sommes passés de 64 descriptions de type .ui dans la version 4.0 à plus de 230 dans cette branche 4.1 (jusqu'à présent). C'est un progrès appréciable vers le but final des cinq cents fichiers.
Merci à Caolán McNamara, Krisztian Pinter, Jack Leigh, Alia Almusaireae (KACST), Katarina 'Bubli' Behrens, Abdulaziz A Alayed (KACST), Jan Holesovsky, Faisal M. Al-Otaibi (KACST), Abdulmajeed Ahmed (KACST), Andras Timar, Manal Alhassoun (KACST), Bubli, Albert Thuswaldner, Olivier Hallot, Miklos Vajna, Abdulelah Alarifi (KACST), Gokul Swaminathan (KACST), Rene Engelhard, et d'autres. Il faut également mentionner l'excellent travail réalisé par les traducteurs pour vérifier et mettre à jour les chaînes de caractères.
Le gain le plus important de cette migration de l'interface est qu'il est maintenant très facile de changer et améliorer l'interface utilisateur.
Sorties de déboguage
Il y a de nouvelles macro SAL_INFO et SAL_DEBUG qui facilitent l'ajout de sorties de deboguage filtrées ou temporaires. Nos crochets git vous préviennent aussi si vous laissez des déclaration de SAL_DEBUG au moment du commit.
Construction des galeries
LibreOffice a toujours été encombré avec un format assez hideux pour stocker les galeries. Nous mettons généralement à disposition les galeries d'images en tant que fichiers à part, mais nous avons aussi un ensemble de ressources binaires au sein même de LibreOffice et qui contiennent les miniatures de ces images ainsi que des nombres pour désigner les traductions des noms des images.
Dans la 4.1 nous construisons la plupart des ces fichiers à la compilation pour chaque plateforme, ce qui les rend plus facile à compléter (et qui évite des binaires incompréhensibles dans git). Pour accompagner cela, nous traduisons les noms de thèmes avec une nouvelle syntaxe .desktop. Cela devrait faciliter la vie des utilisateurs voulant builder leurs propres galeries en tant qu'extensions et les mettre à disposition avec leurs traductions.
Retrait complet de SDF
Bien que nous ayons, dès la version 4.0, retiré SDF de la vue de nos contributeurs s'intéressant à la traduction, il restait des fichiers SDF qui étaient générés dans certaines étapes intermédiaires du build. Merci à Tamás Zolnai pour nous avoir permis de migrer vers une solution se basant purement sur des fichiers .po.
S'impliquer
J'espère que vous avez retiré de ce texte l'idée que les développeurs ont continué à se sentir chez eux au sein du projet LibreOffice et ont travaillé ensemble pour amener des améliorations significatives sous le capot…mais aussi sur la carosserie. C'était vraiment amusant de hacker avec eux sur certaines de ces nouveautés. Notre espoir est que, à mesure que le projet trouve son rythme de croisière, de nouveaux contributeurs vont nous rejoindre et découvrir à quel point c'est devenu fun et bien plus facile d'améliorer le code de nos jours. Vous serez en bonne compagnie, que ce soit en terme de contributeurs de code avec qui collaborer :
Mais aussi en terme de diversité d'origine des commits. Nous aimons vraiment voir de nombreux contributeurs bénévoles sans affiliations, même si les quantités et les ratios varient en fonction de la saison, du cycle et du temps disponible pour la supervision :
Bien entendu nous maintenons une liste de tâches simples et courtes dans laquelle vous pouvez piocher afin de commencer à contribuer. Allez jeter un coup d'oeil sur notre page Easy Hacks et sur les instructions de build. Nous avons maintenant un environnement plus propre et plus sûr à partir duquel travailler à l'amélioration du code.
Une des choses les plus simples à faire pour aider est de rapporter les bugs et de participer au tri de ces bugs (confirmer, corriger et améliorer les rapports de bugs des autres personnes). Avec seulement un peu d'expérience vous pouvez devenir un trieur efficace et les rapports de bugs bien rédigés aident vraiment les développeurs. Il vous suffit d'installer une pré-version et vous serez prêt à contribuer aux côtés des autres membre de l'équipe de développement. Encore mieux, vous pouvez participer au très fun concours de tri des bugs et gagner des prix.
Conclusion
LibreOffice 4.1 va être un nouveau jalon et nous espérons également qu'il fixera la barre en terme de qualité de code, d'améliorations du design et de fondations incrémentalement plus solides pour la meilleure suite bureautique du monde.
Bien entendu, avec autant de changements, nous aimerions que vous testiez nos bêtas et nos version candidates, qui devraient (nous l'espérons) vous être utiles dans votre travail - pensez quand-même à sauvegarder régulièrement. Si vous n'avez pas le temps de tester nos bêtas et de nos version candidates, notre plan de sortie prédit une date pour la version finale à la fin du mois de juillet.
Merci de soutenir LibreOffice.
Aller plus loin
- Le post original sur le blog de Michael Meeks (330 clics)
- Le site de LibreOffice (708 clics)
- Faire un don pour LibreOffice (45 clics)
# Java ?
Posté par zebra3 . Évalué à 10.
Et aux autres aussi, ça permettra d'utiliser les assistants sans attendre trois plombes.
Blague à part, ça fait plaisir de voir autant d'améliorations. Dommage que ça n'ait pas été fait du temps d'OOo, ça aurait permis de se concentrer sur de nouvelles fonctions, mais au moins ça avance.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Java ?
Posté par djano . Évalué à 10.
Il me semble qu'OpenOffice.org était bloque par les processus de la QA. J'avais cru lire que le problème était chez Sun qui était effrayé qu'il y ait des régressions due aux refactorings.
Depuis le passage a LibreOffice, le ton a totalement change: ils préfèrent voir un projet vivant qui nettoie les vieilleries car cela permet:
Ils préfèrent avoir occasionnellement quelques bugs qui seront vite et facilement corrigés plutôt que d'avoir des problèmes de design qui traînent des années sans être corriges et qui amènent a du code pas propre avec des contournements, etc.
[^] # Re: Java ?
Posté par collinm (site web personnel) . Évalué à -5.
pas sûr qu'il y est vraiment un gain en performance en utilisant python.
les plateformes que java n'est pas dispo c'est android?
www.solutions-norenda.com
[^] # Re: Java ?
Posté par Shunesburg69 . Évalué à -2. Dernière modification le 18 juin 2013 à 17:21.
Si on a tant de performance dans les dernières versions ce n'ai pas que dû aux améliorations du code, le JAVA est plus lourd que le Python. Et il y a pas que iOS et Android qui n'ont pas de JAVA, il y a des distributions où il n'est pas installé par défaut. En plus pourquoi devoir installer le JAVA alors que le Python est intégré à LO? Ça permettra aussi en passant du JAVA au Python de revoir le code, de l'améliorer et de mieux le comprendre.
[^] # Re: Java ?
Posté par ariasuni . Évalué à 3.
C’est marrant on ressort toujours cette explication alors que le Java est plus rapide que le Python parce que c’est compilé en bytecode contrairement au Python qui est interprété. Par contre tu veux peut-être parler de l’occupation mémoire, et de ce côté-là j’ai l’impression que Java est très très gourmand.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Java ?
Posté par Albert_ . Évalué à 1.
Tu peux compiler python si c'est vraiment ca qui t'inquiete et si ta distribution fait bien son boulot c'est generalement ce qui est fait.
[^] # Re: Java ?
Posté par ariasuni . Évalué à -1.
J’ai jamais vu de Python compilé sur ma distribution, je ne connais même pas de projet qui soit capable de faire ça (bon on peut compiler du Python vers du Java ou utiliser Pypy qui utilise un JIT mais bon).
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Java ?
Posté par Albert_ . Évalué à 2. Dernière modification le 18 juin 2013 à 23:32.
Avant de moinsser commer des cons, il faudrait un peu reflechir les gars. Faites donc une recherche de fichiers .pyo (python bytecode optimise) ou .pyc (python bytecode).
Certes cela ne concerne "que" le demarrage du code et pas le fait qu'il va tourner plus vite mais bon je vous lance au defi de lancer un truc utilisant un certains nombre de lib mais sans avoir aucune compilation avant. Ca va etre rigolo et python sera en effet tres tres tres lent au demarrage (a chaque fois) et pour la grande majorite des utilisateurs c'est uniquement la que se situe le probleme.
[^] # Re: Java ?
Posté par Shunesburg69 . Évalué à 0.
Après c'est comme tout, sans optimisation de code la lenteur est au rendez-vous quelque soit le langage. Mais le choix du python en premier lui n'était pas pour ça rapidité mais parce qu'il est déjà intégré dans la suite.
Si on avait intégré le JAVA, on aurait pas eu à l'installer sur nos poste et on parlera pas de tout ça.
[^] # Re: Java ?
Posté par Albert_ . Évalué à 6. Dernière modification le 19 juin 2013 à 11:49.
la licence de Java ne permet pas l'inclusion et il ne faut pas chercher plus loin. Apres il y a tout de meme le leger probleme de l'empreinte memoire. Python a une licence adequate et pour ce quoi il est utilise dans LO, sa "lenteur" est tres peu perceptible.
Il fallait un truc qui soit multiplateforme, avec une licence adequate, qui soit maintenable (ca c'est pour lancer un troll perl :) ). Alors certes ils auraient pu choisir mono/C# (et hop un autre troll) comme cela a etait le cas un temps lorsque novell/microsoft participait a OOo mais bon ils ont ete un peu serieux et pris un truc perenne.
[^] # Re: Java ?
Posté par zebra3 . Évalué à -3.
Parce qu'il n'y en a pas besoin : c'est suffisamment rapide comme ça.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Java ?
Posté par zebra3 . Évalué à 2.
C'est marrant, Java a beau être compilé et Python interprété, je n'ai jamais vu d'application Java rapide.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Java ?
Posté par Zenitram (site web personnel) . Évalué à 3.
Pas plus que Python
[^] # Re: Java ?
Posté par ariasuni . Évalué à 0.
Ouais j'ai vérifié et en fait non… Impression dû à des programmes codés avec les pieds?
Minecraft anyone?
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Java ?
Posté par woprandi . Évalué à -2.
Minecraft codé avec les pieds ? Tu sais de quoi tu parles ?
[^] # Re: Java ?
Posté par zebra3 . Évalué à 6.
Bah en même temps, faire un truc qui rame autant en étant aussi moche, soit c'est codé avec les pieds, soit Java c'est vraiment lent…
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Java ?
Posté par Larry Cow . Évalué à 2.
C'est moche, mais c'est grand.
[^] # Re: Java ?
Posté par zebra3 . Évalué à 0.
Et ?
Je sais que la carte est plusieurs fois celle de la Terre, mais le jeu est obligé de l'avoir entièrement en mémoire ?
Non parce que la carte de GTA4 si elle est largement moins grande n'est pas négligeable non plus, pourtant le jeu est largement plus beau et ne rame pas sur une machine correcte.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Java ?
Posté par oao . Évalué à 2.
Dans GTA, tu n'as pas besoin de voir à dix kilomètres. Dans Minecraft, si.
[^] # Re: Java ?
Posté par zebra3 . Évalué à 1.
Mais dans GTA, tu as beaucoup plus de détails (c'est pas juste des cubes).
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Java ?
Posté par woprandi . Évalué à -1. Dernière modification le 20 juin 2013 à 20:56.
La carte est généré au fur et à mesure dans minecraft.
Dans GTA c'est moins grand, moins haut, les éléments mobiles quand ils se sont plus en visu, disparaissent, alors que tout reste dans minecraft. Et surtout c'est toujours la même map, où on fait le tour en 1h. Bref incomparable
[^] # Re: Java ?
Posté par ariasuni . Évalué à 2.
Et quand la carte est déjà généré (parce qu'on est déjà passé par là), c'est moins lent certes mais bon.
Il ne se passe des choses que dans les chunks chargés dans en mémoire.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Java ?
Posté par rakoo (site web personnel) . Évalué à 2.
La carte n'est pas entièrement chargée en mémoire, ça serait bien stupide. Ça pose d'ailleurs quelques problèmes, parce que pour que certains événements arrivent, il faut qu'elle soit chargée… mais dans certains mods, il existe des solutions pour ca.
[^] # Re: Java ?
Posté par zebra3 . Évalué à 3.
Bah alors, pourquoi c'est si lent si c'est pas la carte ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Java ?
Posté par ariasuni . Évalué à 3. Dernière modification le 20 juin 2013 à 15:32.
Minecraft, ou comment apprécier des graphismes 8 bits en mettant à genoux un dual core avec 2 Go de mémoire vive.
(j'apprécie le jeu pourtant… mais c'est insupportable de ne pas pouvoir mettre en pause Minecraft pour aller troller sur Linuxfr ou vérifier un truc sur le wiki de Minecraft)
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Java ?
Posté par woprandi . Évalué à 0. Dernière modification le 20 juin 2013 à 20:51.
Faut y jouer avant de dire ça. Cartes gigantesques, énormément de calculs…. C'est pas un jeu FB
[^] # Re: Java ?
Posté par ariasuni . Évalué à 0.
À part la génération du monde et les monstres à côté de toi, rien de très complexe.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Java ?
Posté par zebra3 . Évalué à 5. Dernière modification le 21 juin 2013 à 09:22.
Merci, j'ai essayé et je confirme : c'est trop lent pour ce que c'est.
Cartes gigantesques ? On m'a dit plus haut que la carte n'est pas chargée en totalité.
Énormément de calculs ? Pour afficher des cubes ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Java ?
Posté par claudex . Évalué à 5.
Une différence entre GTA et Minecraft, c'est que le paysage de GTA ne peut pas être modifié, ça permet d'avoir des image précalculées à afficher. Tandis que dans Minecraft, le paysage peut potentiellement être complètement différent à chaque fois que tu le regarde.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Java ?
Posté par ariasuni . Évalué à 2.
D'accord, mais quand rien ne bouge? Les blocs de sables qui sont au-dessus du vide lors de la génération du monde ne tombent que si on pose un bloc à côté: ça marche à l'évènementiel.
Maintenant, regarde Minetest. C'est exactement pareil à ce niveau-là, sauf que ça met pas deux plombes. Bien sûr c'est plus simple, mais il y a à peu près les mêmes fonctionnalités: blocs qui tombent, éclairage dynamique, etc.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Java ?
Posté par claudex . Évalué à 3.
J'expliquais juste les différence entre GTA et Minecraft qui fait qu'il est difficile de vouloir les comparer. Je n'ai aucun avis sur le reste n'ayant jamais joué à Minecraft.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Java ?
Posté par ariasuni . Évalué à 1.
Je suis assez d'accord, et de toute façon je n'ai jamais joué à GTA! :p
J'en profite pour rajouter qu'il y a aussi Manic Digger en C#, j'ai pas réussi à le faire tourner sous GNU/Linux mais ça fait un moment…
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Java ?
Posté par ariasuni . Évalué à 1.
Oui justement…
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Java ?
Posté par Zenitram (site web personnel) . Évalué à 4. Dernière modification le 19 juin 2013 à 10:12.
Au contraire, Python c'est très fort en lenteur.
Mais on s'en fout, ce n'est pas pour ça qu'ils sont utilisés (sinon on ferai en C/C++), c'est pour leur simplicité/adaptabilité.
Changer de langage est le meilleur moyen d'ajouter des bugs (ben sinon ta review de code, ça marche aussi sans changer de langage… Si tu veux le faire).
[^] # Re: Java ?
Posté par ariasuni . Évalué à 0.
Un autre benchmark pour confirmer.
Et un en faveur de Python pour équilibrer.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Java ?
Posté par grim7reaper . Évalué à 3.
Le bench en faveur de Python est à foireux.
Le code Java est pourri au possible (suffit de voir que pour l’écriture il n‘utilise même pas des I/O bufferisé, alors que script Python le fait).
Pour info, chez moi ça donne :
Time to write: 0.466531038284 (Python)
Time to write: 3.083743529 (Java foireux du bench)
Time to write: 0.437884799 (Java bufferisé, ~équivalent au code Python donc)
Résultat : bah y’a pas grande différence.
De toutes façons, niveau I/O c’est rarement là que les langages se distingue (s’ils sont pas trop mal foutu…) les uns des autres, vu que ça fini souvent en appels de l’API C du système sous-jacent.
Idem pour la lecture, Scanner est réputé pour être lent donc c'est clairement pas ça qu’un programmeur Java va utiliser pour lire une grosse liste de double dans un fichier.
[^] # Re: Java ?
Posté par zebra3 . Évalué à 2. Dernière modification le 19 juin 2013 à 12:32.
C'est un peu le problème des benchs : ça n'est jamais représentatif de cas réels.
Ici on parle d'assistant dans une suite bureautique. Y'a un bench pour ça ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Java ?
Posté par ariasuni . Évalué à 0.
Je me doutais que le benchmark était pas parfait… C'était pour montrer que je citais pas que des benchmark en faveur de Java.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Java ?
Posté par floriang . Évalué à 0.
Sauf erreur de ma part, à part le noyau qui est Linux, tout Android est en Java. Du moins, dans les 1res versions.
[^] # Re: Java ?
Posté par claudex . Évalué à 4.
Les couches de bases sont en C quand même.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Java ?
Posté par antistress (site web personnel) . Évalué à 2.
Ben oui, si Python est utilisé comme dans PiTiVi, il n'a pas besoin d'être rapide, ses qualités attendues sont autres
# Diagramme à aires en pourcentages
Posté par lrbabe . Évalué à 10.
Bonne dépêche, on est content pour LibreOffice. Juste une remarque, les deux derniers graphiques sont absolument illisible : impossible de mettre en relation le diagramme et sa légende.
[^] # Re: Diagramme à aires en pourcentages
Posté par ben51 . Évalué à 7.
J'appuie cette remarque.
Couleur trop proche (ex : ALTA et TATA).
# Quant à la carrosserie…
Posté par coid . Évalué à 6.
c’est par là : https://wiki.documentfoundation.org/ReleaseNotes/4.1/fr
[^] # Re: Quant à la carrosserie…
Posté par nicko . Évalué à 6. Dernière modification le 18 juin 2013 à 14:06.
Le plus intéressant là dedans selon moi, c'est l'arrivé d'un volet latéral.
Enfin ! j'ai en envie de dire. Depuis le temps que nos écrans sont 16/9 ou 16/10 sans que cette espace supplémentaire soit utilisé à bon escient.
Mais c'est quoi le rapport avec IBM symphony (qu'on voit sur les captures) ?
[^] # Re: Quant à la carrosserie…
Posté par nud . Évalué à 5.
Le volet latéral vient en fait du code source de IBM Symphony qui a été fusionné avec le code de Apache OpenOffice.
[^] # Re: Quant à la carrosserie…
Posté par Shunesburg69 . Évalué à 3.
Pas encore fusionné mais donné à Aoo par IBM, et vu que la licence de Aoo permet la réutilisation de leur code par LO, on peux avoir le panneau de Symphony sur LO.
[^] # Re: Quant à la carrosserie…
Posté par Albert_ . Évalué à 7.
Le volet lateral c'est aussi ce qu'a choisi calligra et en effet c'est "legerement" plus logique vu le format des ecrans. Le defaut c'est qu'il faut eventuellement bouger sur de plus longues distances la souris mais avoir plus de 3 lignes (bon suivant votre config ca peut etre 4 :) ) que tu as ecris a l'ecran c'est tellement plus agreable.
# Encourageant !
Posté par Pierre Jarillon (site web personnel) . Évalué à 9.
Merci tout d'abord à notre fabuleux Patrick_Guignot à qui nous devons le plaisir de lire un article aussi passionnant.
J'avais entendu parler du grand nettoyage de code par des contributeurs de LibreOffice mais je n'avais jamais eu d'informations détaillées du chantier.
J'ai été surpris par le nombre de lignes de commentaires en allemand qui datent de StarOffice. Lorsque Sun avait acheté StarOffice, il y avait eu un assez gros travail de fait pour libérer le code et supprimer le bureau vieillot qui venait par dessus votre bureau favori (KDE, Gnome, XFCE, etc). Ensuite Sun a toujours trainé pour intégrer les modifications d'où les versions patchées livrées par les distributions. Au vu de cet article, on peut comprendre pourquoi Sun n'a pas été plus réactif car la tâche était immense.
Des question se posent maintenant : Que va faire Apache avec OpenOffice ? Est-ce Apache a les moyens de faire le même travail que LibreOffice ? La même motivation ?
[^] # Re: Encourageant !
Posté par patrick_g (site web personnel) . Évalué à 10.
Du fait des licences différentes entre Apache OpenOffice et LibreOffice, tous les patchs d'AOO qui sont intéressants peuvent être importés dans LO (voir cette page qui liste les patchs importés). Ce n'est pas le cas en sens inverse et aucun patch de LO ne pourra arriver dans AOO.
Si on ajoute à ça le fait que les contributeurs ont migrés en masse vers LO, je pense que le futur d'AOO est sombre. Le mieux que la fondation Apache pourrait faire ce serait de mettre fin au projet et de rejoindre la Document Foundation pour aider LO à croitre encore plus vite.
Malheureusement c'est rare que des projets libres s'allient entre-eux pour le plus grand bénéfice de tous. La division et la séparation des forces est une situation bien plus courante.
[^] # Re: Encourageant !
Posté par djano . Évalué à 6.
Peu importe la fondation Apache dans cette histoire, le plus ennuyeux c’est surtout qu'Oracle ait donne le trademark a la fondation Apache au lieu de la TDF, et qu'IBM ait choisit de soutenir Apache OpenOffice au lieu de LibreOffice. Du coup, les efforts se sont un peu dispersés au lieu d'avoir un projet unique.
Mais bon, je comprend la peur des grosses entreprise envers de gros refactorings, ça rend les choses difficiles a planifier et maîtriser la qualité devient plus compliqué lorsque les tests unitaires sont en nombre insuffisant.
Heureusement, ces choses sont en train de changer du cote de LibreOffice.
[^] # Re: Encourageant !
Posté par Atem18 (site web personnel) . Évalué à 4.
En effet, et ça commence dès maintenant pour la 4.1 :
http://www.unixmen.com/libreoffice-4-1-beta-1-arrives-with-loads-of-features-including-symphony-sidebar/
[^] # Re: Encourageant !
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 4.
Rien n’empêche que les contributeurs des patches de LO les publient sous une licence plus permissives s’ils le souhaitent, afin qu’ils puissent bénéficier aux deux projets.
[^] # Re: Encourageant !
Posté par claudex . Évalué à 8.
Les patch sont souvent des produits dérivés d'un autre code, il faut donc respecter la licence de cet autre code.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Encourageant !
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 2.
Certes, mais je parlais plutôt des contributions plus importantes.
[^] # Re: Encourageant !
Posté par claudex . Évalué à 6.
Même pour les contributions plus importantes, il faut vraiment qu'elles ne soient pas basé sur l'existant pour que ce possible.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Encourageant !
Posté par Thomas Debesse (site web personnel) . Évalué à 5.
Cela dit, si le patch modifie un même code (issu de Sun OpenOffice.org) licencié d'une manière chez Apache et et d'une autre manière chez la Document Foundation, ça doit être acceptable non ? En ce sens, le code modifié peut-être tout à fait AOO ou LibO, dans le cas où LibO où sur la partie de code modifiée, ni le projet LibO ni AOO n'aient divergés… Le code que cite le patch… chez AOO il est d'une licence, et chez LibO d'une autre licence… bon ça fait beaucoup de conditions, mais dans l'absolu, qu'est ce qui définie qu'un patch modifie LibO ou AOO, pris isolément, si la partie de code modifée est communer aux deux projets ?
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Encourageant !
Posté par claudex . Évalué à 5.
Dans ce cas, je pense que c'est bon. Mais comme tu le dis, ça fait beaucoup de conditions.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Encourageant !
Posté par Littleboy . Évalué à 4.
Il manque quand meme une section 'douchebag' dans la news avec la traduction des commentaires de robweir sur LWN.net
[^] # Re: Encourageant !
Posté par djano . Évalué à 6.
Boarf il défend son pré carré (Apache OpenOffice) et son employeur (IBM), il est donc stratégique pour lui de dire qu'AOO est mieux que LibreOffice. Ce qui est amusant c'est que dans son premier post, il dit qu'il ne faut pas que LO tape sur AOO et vice versa, mais il se contredit dans tous ses posts suivants pour taper sur LO.
Tant pis pour lui si LO a remplacé AOO dans le cœur des libristes, et si LO semble avancer plus vite, de manière plus ouverte et et dans une meilleure direction qu'AOO.
Il semble que LO est développé par une communauté ouverte alors qu'AOO est juste développé par des entreprises (oui, oui, je sais que LO est aussi développé par des entreprises telles que Novell, RedHat, etc.)
# Projets d'interface
Posté par JGO . Évalué à 10.
Je sais que ce n'est pas le sujet de cette dépêche très intéressante, mais si quelqu'un de LibO nous lit, j'aimerais savoir quels sont leurs projets à plus long terme pour l'interface.
En ce moment, LibO a une interface assez similaire à Word 6, avec ses boutons empilés sur deux lignes et les lignes d'icônes qui apparaissant ou disparaissent (dessin, table). Ça marche, mais cela a des désavantages : barres d'outils surchargées de boutons pas très identifiables avec leur petite icône, barres d'icones parfois pas très bien placées, etc. Il existe plusieurs autres modes d'interaction avec l'utilisateur !
Ce qui serait vraiment cool, ce serait un choix de profil d'interface, pour avoir un mode d'affichage ruban, un mode d'affichage dock et le mode classique. Cela peut être beaucoup de travail, mais pour un logiciel comme libO, l'interface, c'est TOUT. LibO n'a pas le carcan qu'utilise la concurrence pour forcer ses utilisateurs à aimer les nouvelles interfaces. De nombreux utilisateurs fidèles aiment le style classique, mais de nombreux utilisateurs venus d'autres suites logicielles aimeraient un style plus moderne.
Passer à des fichiers XML .ui est une première étape pour permettre une plus grande abstraction. J'aimerais que libO fasse en sorte ensuite de ne perdre aucun utilisateur en donnant à l'aspect la flexibilité nécessaire pour que chaque workflow puisse fonctionner de la meilleure façon possible.
[^] # Re : Projets d'interface
Posté par _jordan_ . Évalué à 3.
J'aime bien le système de ruban de la concurrence : aération de l'interface et peut être même une diminution générale du nombre de clic.
Il y a certains points que j’abhorre notamment les petites flèches en bas de certains cadres qui ouvrent des menus supplémentaires (pas du tout intuitif, on pense que c'est de la décoration ou destiné au redimensionnement du cadre). Il m'arrive aussi de me tromper de menu pour trouver quelque chose.
Un autre mode d’interaction complémentaire : le système de fenêtres qui surgissent après sélection du texte. Je remarque que beaucoup de personnes le trouvent gênant mais pour moi cela accélère vraiment certaines actions.
[^] # Re: Re : Projets d'interface
Posté par JGO . Évalué à 4. Dernière modification le 17 juin 2013 à 15:29.
Chez la concurrence, ce que je trouve intéressant c'est la prévisualisation au survol (parcourir différents effets en les survolant permet de voir une prévisualisation directement sur le document, cela permet de choisir en ayant moins à réfléchir et réduit la fatigue de ceux qui utilisent ces logiciels pendant de longues heures).
[^] # Re : Projets d'interface
Posté par _jordan_ . Évalué à 4.
Cette prévisualisation a commencé d'être incluse depuis lo 4. Je ne sais pas si elle va être généralisée.
[^] # Re: Re : Projets d'interface
Posté par dsant69 . Évalué à 6.
+1 JGO
Je déteste les Rubans, et hélas la "concurence" l'impose sur mon poste de travail au quotidien, je trouve jamais les fonctions avancées. Et vous ?
Je rêve vraiment d'avoir le choix.
[^] # Re: Re : Projets d'interface
Posté par dinomasque . Évalué à 4.
Comme tout le monde j'ai eu du mal à réapprendre l'usage de la suite MS Office mais je trouve le ruban très bien.
Si je devais demander quelquechose en plus, ce serait une interface à la "HUD" d'Ubuntu ou on tape ce qu'on veut faire et l'ordinateur trouve la fonction associée comme un grand.
BeOS le faisait il y a 20 ans !
[^] # Re: Re : Projets d'interface
Posté par lolop (site web personnel) . Évalué à 10.
Et pour distinguer que c'est une commande et pas du texte qu'on est en train de saisir, on appuie sur
escpuis sur::-)Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Projets d'interface
Posté par antistress (site web personnel) . Évalué à 1.
Le ruban est breveté il me semble
[^] # Re: Projets d'interface
Posté par Shunesburg69 . Évalué à 2. Dernière modification le 17 juin 2013 à 16:37.
Breveté peut-être sur sa structure et la position des icônes mais rien empêche de faire quelque chose de similaire mais différent.
Personnellement je n'aimais pas le ruban de µsoft, mais étant obligé de l'utiliser au boulot, je m'y suis fait et je trouve qu'au finale c'est pas mal (quoique non configurable).
Par contre si on met une telle chose sur LibreOffice, il faudra au moins qu'on ai le choix et que ce soit configurable à souhait.
(qu'on fasse pas du forcing à la gnome 3)
[^] # Re: Projets d'interface
Posté par djano . Évalué à 4.
On s'y fait lorsque l'on a des besoins basiques.
Par exemple, je n'arrive plus a retrouver certaines des fonctionnalités que j'utilisais avant le ruban (certes, ce ne sont pas des fonctionnalités que je utilise très souvent) et même l'aide ne peut pas me dépanner. L'option a simplement disparu!
C'est réellement frustrant lorsque l'on sait que cette fonctionnalité existe mais n'est plus accessible depuis la nouvelle UI.
[^] # Re: Projets d'interface
Posté par nicko . Évalué à 1.
Si c'est breveté, j'en connaît qui vont avoir des ennuis. Foxit (lecteur PDF) et Kingsoft Office (suite bureautique chinoise) l'utilisent. Et sûrement d'autres.
[^] # Re: Projets d'interface
Posté par JGO . Évalué à 2. Dernière modification le 24 juin 2013 à 13:57.
Foxit est « Microsoft preferred PDF reader » (d'après leur site) donc aucun doute qu'ils ont l'autorisation. Ensuite, d'après l'article Wikipédia Ribbon, il n'y a pas de brevet déposé, possiblement parce que cette interface a été inventée par un gros poisson pas facile à intimider : IBM. Même sans brevet, Microsoft vend des licences aux petites compagnies effrayées. Ceux qui ont signé la licence sont obligés d'utiliser le ribbon moche de Microsoft ; le reste du monde est libre de faire aussi bien qu'IBM.
[^] # Re: Projets d'interface
Posté par antistress (site web personnel) . Évalué à 2.
dingue
[^] # Re: Projets d'interface
Posté par pasBill pasGates . Évalué à -1.
Lol, vraiment du n'importe quoi.
On donne tous les APIs pour creer des rubans dans des softs Windows : http://msdn.microsoft.com/en-us/library/windows/desktop/dd316910(v=vs.85).aspx Pas de licence ou quoi que ce soit de necessaire.
[^] # Re: Projets d'interface
Posté par JGO . Évalué à 8. Dernière modification le 24 juin 2013 à 19:55.
Tu peux corriger ou compléter la phrase dans Wikipédia si la source est erronée ou si la situation a changé depuis lors. Selon la référence 41 de l'article, l'utilisation de l'UI en ruban n'est gratuite que si les produits n'entrent pas en concurrence avec ceux de Microsoft.
[^] # Re: Projets d'interface
Posté par collinm (site web personnel) . Évalué à 2.
en gros une interface comme 99% des softs
www.solutions-norenda.com
[^] # Re: Projets d'interface
Posté par iGor (site web personnel) . Évalué à 3.
Personnellement le ruban de la concurrence m'agace passablement. Je m'y suis fait, mais je n'aime pas, d'ailleurs je le cache. Comme la plupart des barres de libO en fait, et je supprime la plupart des boutons aussi. Par contre, j'ai constamment ouvert la fenêtre des styles et le navigateur, ancrées à gauche et à droite.
Ce que j'aime, ce sont les raccourcis claviers.
[^] # Re: Projets d'interface
Posté par karteum59 . Évalué à 7.
Surtout chez la concurrence et malgré leur interface à rubans immonde, il est très facile de faire un document qui présente bien en 3 clics (thèmes/styles), alors qu'il faut à la fois être pas trop manchot et passer du temps pour avoir un truc joli sur LO, dont les thèmes par défaut semblent dater du siècle dernier…
(A mon grand dam, la branche consulting de ma boite est repassée à la MSOffice précisément pour cette raison : parce qu'avoir des livrables qui présentent bien est important pour leur activité (troll inside :) )
[^] # Re: Projets d'interface
Posté par woprandi . Évalué à 4.
Ils ne peuvent pas passer une journée ou deux pour créer un thème qui leur convient ?
[^] # Re: Projets d'interface
Posté par arnaudus . Évalué à 10.
Tu veux dire, prendre une décision rationnelle? Quelle drôle d'idée.
Fournir un document correct par défaut et offrir quelques styles acceptables parmi les premières possibilités sont indispensables pour qu'un logiciel soit utilisé. C'est un peu comme si une boutique mettait n'importe quoi en devanture, et que le vendeur s'étonnait de l'absence de public, alors que l'arrière-boutique est plein de choses intéressantes.
[^] # Re: Projets d'interface
Posté par Shunesburg69 . Évalué à 1. Dernière modification le 18 juin 2013 à 12:19.
Ils ont quand même fait des efforts de ce côté, regardé les modèles pour Impress. Le logo au démarrage et la page de démarrage sont plus agréable, ils refont les fenêtres mal agencées…
Le seul truc que j'ai du mal à voir en peinture c'est leurs icônes pour les logiciels (Writer, Calc, Impress…), ils sont horribles excepté celui de LibreOffice lui-même.
[^] # Re: Projets d'interface
Posté par arnaudus . Évalué à 5.
Je viens de vérifier, dans Writer, le "Header" est plus petit que le "Header 1", les espaces entre les titres et les paragraphes ne sont pas très logiques… C'est loin d'être le rendu idéal…
[^] # Re: Projets d'interface
Posté par woprandi . Évalué à 1.
Certes mais de là à foncer tête baissée dans l'autre direction
[^] # Re: Projets d'interface
Posté par Sophie Gautier . Évalué à 10.
Nous aimerions bien sûr donner la flexibilité nécessaire à tous nos utilisateurs. Mais avant l'interface, il y avait un gros travail à faire sur le code, certains commentaires sont encore en allemand… Le passage au nouveau format .ui facilitera le design de nouvelles interfaces, mais en attendant, il faut que les développeurs portent celles qui existent, ce qui entraîne également une somme de travail supplémentaire aux traducteurs des 117 langues présentes. Tout ceci prend du temps à tous nos petits doigts bénévoles (par exemple, un nouveau jeu d'icône est en cours basé sur le jeu et les specs Gnome, mais un seul bénévole y travaille) et la fondation est encore jeune.
Je pense que lorsque les projets de portage sur une version cloud ou sur les tablettes verront le jour (pas de date! ;) le design des interfaces suivra plus facilement.
Sophie
[^] # Re: Projets d'interface
Posté par ariasuni . Évalué à 7.
Ahlala ces utilisateurs toujours exigeants!
Je suis très content de connaitre les détails des travaux en cours, ça montre qu’il y a beaucoup de main d’œuvre et que LibreOffice continuera de s’améliorer mais si ça n’est pas de façon visible. Je suis d’ailleurs très impressionné par le travail effectué par l’équipe, c’est fou!
En tout cas ce qui est sûr c’est qu’après tout ça LibreOffice pourra évoluer beaucoup plus facilement. Et ça c’est très important, que ça soit pour corriger des bugs, ajouter des fonctionnalités, améliorer les performances ou améliorer l’interface graphique.
Et on voit clairement que LibreOffice est dans la bonne direction.
Néanmoins, j’ai déjà entendu quelqu’un dire qu’elle n’utilise pas LibreOffice parce que c’est moche, et c’est triste d’entendre ça quand on sait tout le travail fournit pour faire évoluer le logiciel. On verra ce que ça donne dans deux-trois versions, c’est vrai que c’est le seul point qui pêche vraiment dans LibreOffice.
Écrit en Bépo selon l’orthographe de 1990
# Symphony?
Posté par Shunesburg69 . Évalué à 1. Dernière modification le 17 juin 2013 à 12:38.
Je me demande si c'est une bonne chose ou non qu'il y ai l'ajout de parties d'IBM Symphony dans le code. Que sait-on sur ce qui a été implémenté ou non, dans LibreOffice 4.1 (à part les Galeries)?
[^] # Re: Symphony?
Posté par Anthony F. . Évalué à 2.
Le code est offert à OpenOffice.org, pas directement à Libre Office (bien que c'en soit un fork).
[^] # Re: Symphony?
Posté par Shunesburg69 . Évalué à 3. Dernière modification le 17 juin 2013 à 15:05.
Oui je sais, mais ils ont implémenté apparemment une partie de ce code pour la 4.1. Je voulais savoir quoi, outre les galeries. (ex: ont-ils pris une partie de l'interface, des filtres d'imports, ou du support VBA…?)
# VBA
Posté par Pierre Jarillon (site web personnel) . Évalué à 7.
Le visual basic (VBA) est souvent utilisé avec Excel. Certains en font une utilisation très avancée et cela constitue souvent un obstacle majeur à la migration vers LibreOffice.
Qu'est-il prévu pour faciliter la migration de ces applications et enlever ainsi l'un des derniers verrous vers la suite libre ?
[^] # Re: VBA
Posté par Shunesburg69 . Évalué à 3.
C'est justement ce point là que j'aurais aimé plus détailler, apparemment LO utilise un autre langage pour les macros, et n'ai pas trop copain avec le VBA. Ce serait bien de savoir ce qui marche ou non actuellement et ce qui est prévu pour cette mouture de LO.
# Grand moment d'humour
Posté par pasBill pasGates . Évalué à 10.
LibreOffice 4.1 va être un nouveau jalon et nous espérons également qu'il fixera la barre en terme de qualité de code, d'améliorations du design et de fondations incrémentalement plus solides pour la meilleure suite bureautique du monde
Le mot 'libre' aurait ete integre a la phrase et je n'aurais rien a dire, mais la… faut revenir un peu sur terre quand meme. C'est une suite qui satisfait nombre de gens, de la a etre la meilleure suite bureautique du monde par contre…
[^] # Re: Grand moment d'humour
Posté par patrick_g (site web personnel) . Évalué à 10.
Le caractère "libre" étant un pré-requis de base dans l'évaluation d'un logiciel, je pense qu'on peut convenir que LO est bien la meilleure suite bureautique du monde ;-)
[^] # Re: Grand moment d'humour
Posté par Shunesburg69 . Évalué à 0.
Comme dit "pasBill pasGates" c'est la meilleur suite bureautique du monde libre, pour ce qui est du monde tout court c'est pas loin mais pas encore ça.
# Points forts
Posté par _jordan_ . Évalué à 3.
Je sais que cette question revient régulièrement mais quels sont, pour vous, les points forts de libre office par rapport à la concurrence (hormis le fait qu'il soit libre) ?
Lorsque j'ai envie d'appuyer libre office je n'arrive pas à répondre à cette question.
[^] # Re: Points forts
Posté par dinomasque . Évalué à 8.
En plus d'être libre il est gratuit et disponible sur la plupart des OS.
Je crois qu'avec ça on a fait le tour de ses avantages.
BeOS le faisait il y a 20 ans !
[^] # Re: Points forts
Posté par FDF (site web personnel) . Évalué à 4. Dernière modification le 18 juin 2013 à 10:32.
Désolé, ça fait trop longtemps que je n'utilise plus que OOO puis LibO pour que je puisse te répondre.
Mais je dirais que les présentations ne se casses pas d'une version à l'autre. J'ai des gars qui sont encore avec OOO et on a pas de problèmes de transfert de fichier de l'un à l'autre.
Alors qu'avant j'avais de gros problèmes entre les versions de Word. Mais peut être est-ce résolu chez Msoft aussi.
[^] # Re: Points forts
Posté par Shunesburg69 . Évalué à 7.
Pour moi ses points forts sont:
- Bon respect des formats
- Vitesse d'ouverture des fichiers
- Gratuités
- Logiciel Libre
- Compatibilité respectable des formats propriétaires
- Bonne réputation
- De nombreuses options introuvable chez la concurrence
- …
[^] # Re: Points forts
Posté par CrEv (site web personnel) . Évalué à 3.
Vraiment ? J'ai souvent l'impression du contraire si on ne parle pas avec de purs libristes
Lesquelles ? (ce serait pour le coup de vrais argument justement)
[^] # Re: Points forts
Posté par antistress (site web personnel) . Évalué à 2.
LibO/OOo sont en effet décriés pour leur look passéiste
[^] # Re: Points forts
Posté par Larry Cow . Évalué à 6.
Je confirme ça, en effet.
Je vois au moins Draw, qui était déjà une tuerie par rapport à ce qui se faisait dans la dernière version de MS Office que j'ai testé (soit 2007, je crois). Reste que c'est trop peu utilisé dans LO/OOo, peut-être justement parce qu'il n'y a pas d'équivalent direct sous MSO.
Mais j'ai vu suffisamment de gens faire leur PAO sous PowerPoint (faute de Publisher) pour apprécier un module de dessin/mise-en-page généraliste.
[^] # Re: Points forts
Posté par Shunesburg69 . Évalué à 1. Dernière modification le 18 juin 2013 à 12:09.
Bonne réputation (dans le libre je veux dire)
De nombreuses options dont "LibreLogo", et d'autres que tous les concurrents n'ont pas ou moins bien "import/export de fichier Visio et Publisher", "Support des langues droites/gauche", des fonctions dans Calc non implémenté encore ailleurs…
[^] # Re: Points forts
Posté par CrEv (site web personnel) . Évalué à 3.
Hum, étant donné que c'est l'une des rares ça reste assez peu étonnant non ?
Et en fait même dans le libre ça bache pas mal (libre|open)office je trouve
Là tu parles d'extension (pour logo).
Le reste, ben ça ne convainc pas beaucoup je trouve. Que ça fasse un import/export de visio… ben oui mais un visio le fait aussi. C'est pas une fonctionnalité qui permet de dire "je vais faire mieux avec LibreOffice".
En fait LibreOffice fait son boulot, c'est vrai. Mais il n'y a rien de transcendant à l'utiliser je trouve. Rien qui puisse dire que c'est mieux.
Bon ok, j'en connais qui utilisent des addons pour gérer par exemple des équations. A priori c'est plutôt bien fait et ça permet de faire des cours de math sympa sous LibreOffice.
[^] # Re: Points forts
Posté par Shunesburg69 . Évalué à 4.
Oui, c'est vrai il fait ce qu'on lui demande et tout ça gratuit.
Pour la dispute Open/LibreO chacun son choix perso je trouve qu'ils traînent trop chez Ooo et que s'ils abandonnaient pour se réassocier à LO se serait bien plus productif, au vu du retard qu'ils ont pris.
[^] # Re: Points forts
Posté par hercule_savinien . Évalué à 7.
Je n'utilise pas LO et je n'utilisais déjà plus OOo depuis un moment.
Donc peut être que ce n'est plus vrai.
Mais à l'époque un avantage d'OOo qui permettait de ridiculiser MS Office et qui impressionnait ses aficionados était qu'il réparait les fichiers .doc (alors que Word moulinait et pondait un truc dégeu).
Le FN est un parti d'extrême droite
[^] # Re: Points forts
Posté par Adrien . Évalué à 6.
Perso j'utilise occasionnellement les suite de bureautique. Voici quelques avantages :
– suite bureautique multiplate-forme : libreoffice est inclut dans les paquets Debian, est dispo sous Windows et MacOS. On peut donc changer de système assez facilement.
– c'est libre et gratuit, donc facilement testable
– je n'ai pas trouvé mieux de dispo dans les paquets pour faire ce que j'ai à faire : quelques diagrammes avec Calc, une présentation de temps en temps, un rapport à relire, faire une affiche vite fait mal fait genre « la conférence est ici ». Calligra est pas trop mal, mais très loin d'être aboutit.
– la compatibilité avec d'autres solutions (Calligra, MS Office) est potable
Bref, MS Office n'est ni libre, ni gratuit, ni dispo dans les paquets. Je n'ai pas vraiment de raison de l'utiliser.
[^] # Re: Points forts
Posté par iGor (site web personnel) . Évalué à 10.
Je pense que c'est en partie dû à une meilleure connaissance de libO par rapport à la concurrence, des vieilles habitudes, et un manque d'objectivité, mais :
Cela dit, il y a plein de choses à sensiblement améliorer avec libO, souvent du côté de l'utilisateur d'ailleurs. Par exemple, faire sa compta ou diagramme de Gantt avec calc, alors qu'il y a des logiciels pour ça, c'est un peu… bête. Et de plus en plus, pour la production de document texte, je trouve qu'un traitement de texte, c'est pas forcément la meilleure solution, mais c'est une autre histoire.
Enfin, il y a même des choses que la concurrence fait mieux, j'en ai pas en tête là, mais ça doit exister…
[^] # Re : Points forts
Posté par _jordan_ . Évalué à 1.
Voici une jolie liste, j'apprends même des fonctionnalités que je ne connaissais pas.
C'est d'ailleurs le seul logiciel de la suite que j'utilise tout le temps car il me convient parfaitement.
Je n'avais pas pensé au côté gratuit car j'utilise la version donnée dans Windows 7 mais Microsoft vient de la retirer et elle ne sera plus distribuée, même avec Windows 8.
[^] # Re: Re : Points forts
Posté par franken . Évalué à 6.
Je suis d'accord, Draw est excellent. On croirait retrouver le MacDraw ou ClarisDraw de la belle époque, qui n'ont jamais eu d'équivalent depuis …
Il est souvent reproché à OOo et LibO le module de présentation (impress); car il comporte moins de masques par défauts, c'est moins facile de vendre du vent facilement sans effort … il faudrait donc travailler là-dessus, même si personnellement l'impress actuel me suffit largement.
Enfin, la gestion des paragraphes, styles, etc. est beaucoup plus saine que sous Word; c'était déjà le cas avec StarOffice. Cependant, les gens sont tellement habitués à subir les caprices de leurs logiciels favoris qu'ils n'adhèrent pas à un comportement rationnel et sain …
Le côté gratuit, ça n'a rien à voir avec le fait que ça soit libre … j'ai plus contribué financièrement à LibreOffice que je n'ai payé de licence à Microsoft …
[^] # Re: Points forts
Posté par Shunesburg69 . Évalué à 0. Dernière modification le 18 juin 2013 à 17:10.
Oui c'est sûr même si LO est mon préféré, on ne peut pas nier le fait que les fichiers créés sous MSoffice sont mieux gérés sur la suite propriétaire (normale vu que c'est eux qui ont créé le format) et le choix de couleur sous les autres Suite on peux choisir la couleur que l'on veut mais sur LO (et Aoo) on doit l'ajouter d'abord dans notre palette pour pouvoir ensuite l'utiliser…
[^] # Re: Points forts
Posté par Guillaume Rossignol . Évalué à 10.
Le pare-feu ?
[^] # Re: Points forts
Posté par Shunesburg69 . Évalué à -1.
Quel parfeu? Il y a un parfeu dans LO?
[^] # Re: Points forts
Posté par Anthony Jaguenaud . Évalué à 5.
C’était pour une référence au pare feu d’open office.
[^] # Re: Points forts
Posté par Shunesburg69 . Évalué à -1.
J'ai pas tout compris mais est-ce aussi dans LibreOffice?
[^] # Re: Points forts
Posté par CrEv (site web personnel) . Évalué à 4.
T'inquiètes, elle non plus.
[^] # Re: Points forts
Posté par Anthony Jaguenaud . Évalué à 1.
En fait, j’hésite entre tu rigoles, ou tu n’es pas au courant… Pour resituer.
Le 2 avril 2009, Cristine Albanel répond en scéance sur une session de l’HADOPI.
La retranscription en direct sur PCinpact. (voir vers 16h31)
Également sur numerama, du coup, quelqu’un s’est lancé dans la bataille pour faire à madame le ministre son pare-feu.
De ce que j’en ai compris, je n’ai pas été plus loin que quelques articles, s’est une sorte de moniteur du pare feu pouvant l’activé et le désactivé. Ce n’est évidemment pas le pare-feu lui même.
[^] # Re: Points forts
Posté par ariasuni . Évalué à 0.
Je le veux!
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Points forts
Posté par woprandi . Évalué à 1.
Il a été supprimé
[^] # Re: Points forts
Posté par Franc SERRES (site web personnel) . Évalué à 3.
Je rajouterais aussi la gestion des bases de données largement meilleure dans LO.
Comme tous ceux qui ont l'obligation d'utiliser la suite bureautique de l'employeur, on nous demande de fournir à cause de nos compétences informatiques, des outils avancés en bureautique.
Pour moi le gros problème professionnel d'une suite MS Office c'est la "vectorisation de la redondance". Cela engendre d’ailleurs l'explosion de la volumétrie espace disque des serveurs (Valorisation non comptabilisé dans les coûts des logiciels propriétaires).
Donc nos employeurs nous demande bien souvent de mutualiser dans une base de donnée pour palier au manque d'un vrai Groupware. Pour Excel et Word c'est acceptable au fonctionnement. Mais pour PowerPoint c'est catastrophique.
Essayez de construire une présentation PowerPoint avec des graphiques qui se mettent à jour en live avec les bases de données à jour des services. Plein de bugs à l'affichage, plein de bugs à la construction et souvent il faut développer pour avoir une petite interactivité.
Et là quand vous utilisez LO c'est le "Paradis". La suite LO est plus adapté à la gestion Groupware pour l'optimisation financière de l'organisation de l'entreprise. C'est mieux optimisé pour le "mutualisé".
Pour moi c'est uniquement le manque de modèles à la Pointe Graphiquement avec difficulté de changer la culture et l'expertise à la Microsoft qui est le frein essentiel.
# La règle, le curseur et l'aimant
Posté par antistress (site web personnel) . Évalué à 3.
Je suis le seul à trouver que le curseur de la règle devrait être aimanté de façon à viser plus facilement une graduation ? C'est pas comme ça sur les autres éditeurs ?
[^] # Re: La règle, le curseur et l'aimant
Posté par Shunesburg69 . Évalué à 3. Dernière modification le 18 juin 2013 à 11:15.
C'est vrai, sur les autres c'est comme ça, mais pour certains c'est gênant cette aimantation, surtout qu'il suffit de cliquer deux fois sur la règle pour avoir une fenêtre pour saisir les valeurs de tabulation qu'on veut.
[^] # Re: La règle, le curseur et l'aimant
Posté par antistress (site web personnel) . Évalué à 3.
Ah oui tiens, je savais pas, merci
# Stabilité, y-es-tu ?
Posté par echant echant (site web personnel) . Évalué à 1.
Bonjour
Je suis toujours étonné pour certains logiciels sophistiqués, comme libreoffice, entre le côté chatoyant des multiples fonctionnalités et le côté déglingue par manque de stabilité. Enfin là l'accent a été mis sur la stabilité et j'espère que cela portera ses fruits.
Je me frotte à libreoffice depuis de nombreuses années. Cette année avec la version 3.5/debian je me suis dis que ça a l'air de bien marché. Je l'ai utilisé pour des textes mathématiques et j'ai vu beaucoup de bugs, comme l'affichage du texte qui ocille entre deux états, des endroits où je ne peux pas mettre de titre (oui oui je sais l'utiliser, c'est bien un bug), mais le pire c'est toutes mes formules mathématiques qui ont disparues :-((((
bou bou, regrets amères. Je n'ai pas trouvé d'outil pour "fsck" un document et le remettre d'aplomb. Bref vive les logiciels clean.
cordialement
[^] # Re: Stabilité, y-es-tu ?
Posté par Shunesburg69 . Évalué à 4.
Si tu veux de la stabilité n'utilise pas la version 3.5 qui n'est plus maintenu et contient de nombreux bugs.
Essayes plutôt la version 4.0.3, elle est plus stable et à une meilleur compatibilité pour tous les formats.
# Mises à jour
Posté par MTux . Évalué à 1.
Il faut toujours se taper le téléchargement du package complet + réinstallation pour faire une mise à jour sur Windows ? Bien que ce soit une suite génial le processus de mise à jour est quand même très lourd…
[^] # Re: Mises à jour
Posté par Shunesburg69 . Évalué à 2.
Je suis tout à fait d'accord avec toi, ce serait bien qu'ils fassent en sorte que les mise à jour soit automatique et en tâche de fond.
Avec le choix entre version stable et version avancé.
[^] # Re: Mises à jour
Posté par woprandi . Évalué à 1.
C'est quand même plus risqué qu'un navigateur de faire ça je trouve.
[^] # Re: Mises à jour
Posté par ariasuni . Évalué à 2.
Je ne vois pas pourquoi, ça serait très bien au contraire.
Écrit en Bépo selon l’orthographe de 1990
# Encore un fork?
Posté par Shunesburg69 . Évalué à 1.
Faut arrêter maintenant de dire que LibreOffice est un fork, non?
Ça fait quand même plus de deux ans et ils ont quasiment tout recodé. Leurs fonctions, options et compatibilités aussi sont différentes. Je crois que depuis la 3.6 ont peux plus vraiment parler d'un fork, même si c'est ce qu c'était au début.
[^] # Re: Encore un fork?
Posté par CrEv (site web personnel) . Évalué à 4.
Tu as des chiffres sur "quasiment tout recodé" ? Parce que 2 ans pour faire ça, en gardant la compatibilité, ça me parait un peu gros.
Et quant bien même ça resterait à mon avis un fork. C'est une branche basée sur OOo, que tu modifies beaucoup ou pas après ne change finalement pas grand chose.
Mais surtout, c'est quoi le problème de dire que c'est un fork ?
[^] # Re: Encore un fork?
Posté par ariasuni . Évalué à 8.
Fork ça peut se traduire par «embranchement», et à moins de recoder de zéro je ne vois pas comment ça ne pourrait plus être un fork d’OpenOffice.Org.
Par contre ça peut être utile de dire que des milliers de choses ont été améliorés (comme en témoigne les nouveautés de cette version).
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Encore un fork?
Posté par Shunesburg69 . Évalué à -3.
Oui c'est vrai LO restera toujours le fork de Aoo (même si tout était recodé) mais pas besoin de le rappeler sans cesse sachant que le code d'Aoo a en grande parti plus rien à voir avec LO. Et le problème c'est que si on rappel à chaque fois que LO est le fork de Aoo les gens vont continuer de les comparer. Et c'est assez lourd qu'en les gens se prennent la tête à dire Aoo c'est mieux où LO ça déchire.
[^] # Re: Encore un fork?
Posté par djano . Évalué à 9.
De toute façon, les gens vont comparer ces 2 suites bureautiques libres puisqu'elle partent d'une base commune, ils vont même les comparer avec Calligra, voire Gnome Office, voire même MS Office et tu vas avoir les mêmes commentaires xxx c'est mieux ou yyy ça déchire. C'est naturel et ca arrive tout le temps, donc je ne vois pas pourquoi ça te chagrine tant que ça, ça va continuer que tu le veuille ou non.
[mode pédant=on]
D'ailleurs, pour la petite histoire, LibreOffice a été forké depuis OpenOffice.org avant même que le code + trademark d'OpenOffice.org ne soit donné a la fondation Apache créant ainsi Apache OpenOffice. Il est donc faux de dire que LibreOffice est un fork d'Apache OpenOffice.
[mode pédant=off]
[^] # Re: Encore un fork?
Posté par shmget . Évalué à 10.
Non Lo ne peux pas etre un 'fork' de AOO
de part le fait que LO a demarré 9 mois avant que l'idée meme de AOO soit annoncé.
LO est un fork the OOo.. tout comme AOO est un fork, plus tardif de OOo
OOo a ete abandonné par Oracle Avril 2011; 7 mois apres le demarrage de LO/TDF.
IBM a poussé Oracle a 'dumper' le code chez Apache. IBM a ensuite demarré une campagne pour en fair un project Apache…
Puis le code a AOO a subit des coupe pour eliminer tous ce qui etait 'copyleft'.. et 15 mois apres la premiere release officielle de LO, AOO a publie AOO 3.4… base sur la beta 3.4 que Oracle avait laisse en friche un peu plus d'un an auparavant.
La seule chose dont bénéficie IBM c'est le tradmark, développé par Sun et la communauté durant la précédente décade, ce qui leur permet de toujours avoir un nombre non négligeable de 'download', malgrés plus de deux ans d'immobilisme.
[^] # Re: Encore un fork?
Posté par woprandi . Évalué à 10. Dernière modification le 19 juin 2013 à 20:52.
Et ? Un fork ça veut dire crée à partir d'un code d'un autre logiciel, ce qui est le cas. Ça sera donc toujours un fork. X.org reste un fork de XFree86 même si ça fait 9 ans que ça diverge
[^] # Re: Encore un fork?
Posté par Jean-Baptiste Faure . Évalué à 4.
Oui, un fork de OpenOffice.org, mais pas de Apache Open Office qui est lui aussi un fork de OpenOffice.org.
# La France participe à Libre Office
Posté par taupette . Évalué à 4.
Libre dans le secteur public : les ministères français, via Mimo, rejoignent la Document Foundation :
http://www.lemagit.fr/economie/2013/06/19/libre-dans-le-secteur-public-les-ministeres-francais-via-mimo-rejoignent-la-document-foundation/
Il y a une interview d'un des responsables de la Document Foundation qui explique comment les ministères participent à Libre Office
[^] # Re: La France participe à Libre Office
Posté par Shunesburg69 . Évalué à 2. Dernière modification le 20 juin 2013 à 11:48.
Pour une fois que les politiques prennent une bonne résolution. Enfin c'est du à leur budget donc on peut pas non plus les féliciter.
[^] # Re: La France participe à Libre Office
Posté par Pierre Jarillon (site web personnel) . Évalué à 6.
Le groupe MIMO existe et fonctionne mais il lui manque des ressources. J'ai même entendu dire qu'ils n'avaient aucun budget alors que l'on trouve des millions d'euros pour acheter des licences à Microsoft.
# Import des PDF
Posté par antistress (site web personnel) . Évalué à 2.
Il parait que la 4.0.4 (donc la 4.1) sait nativement importer les pdf pour les modifier. J'ai essayé avec deux fichiers (dont celui là par ex) (sous Debian Sid 64 bits) sans succès
[^] # Re: Import des PDF
Posté par Shunesburg69 . Évalué à 1.
Chez moi ça marche, mais j'ai pas essayé ton fichier, peut-être est-il protégé?
Le seul défaut, c'est que ça ouvre dans Draw et que l'on peut pas l'enregistrer en odt ou doc.
[^] # Re: Import des PDF
Posté par antistress (site web personnel) . Évalué à 2.
Même en écrivant "test" sous Writer et en exportant en pdf je ne peux pas l'importer ensuite. Tu as peut être installé l'extension ad hoc, non ?
[^] # Re: Import des PDF
Posté par Shunesburg69 . Évalué à 1. Dernière modification le 20 juin 2013 à 11:46.
Non vu que c'est natif j'ai juste installé LO 4.0.3.
D'après mon souvenir c'est comme ça depuis la 3.6
Edit: Non ce n'était pas natif sous 3.6, désolé c'était via une extension.
[^] # Re: Import des PDF
Posté par woprandi . Évalué à 1.
Je vois pas l'intérêt de modifier un PDF, c'est pas prévu pour ça. A quand la disparition des .odt et .doc ?
[^] # Re: Import des PDF
Posté par floriang . Évalué à 6.
Ça peut servir à récupérer un document dont on a plus les sources.
[^] # Re: Import des PDF
Posté par zebra3 . Évalué à 2. Dernière modification le 20 juin 2013 à 11:48.
C'est une extension, il faut installer le paquet libreoffice-pdfimport et ça fonctionne plutôt bien.
Par contre, ça s'ouvre dans Draw donc on ne récupère pas un .doc ou un .xls.
Edit: grillé, j'aurais dû raffraichir ma page :-)
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Import des PDF
Posté par Shunesburg69 . Évalué à 1.
Sous LO 4.0 elle est incluse. Plus besoin de l'installer.
[^] # Re: Import des PDF
Posté par zebra3 . Évalué à 2.
Elle est tout de même dans un paquet à part sous Debian, j'ai dû l'installer manuellement (et je suis en 4.0.3).
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Import des PDF
Posté par antistress (site web personnel) . Évalué à 2.
L'article dit que c'est inclus dans la 4.0.4 (premier post du fil) ?
[^] # Re: Import des PDF
Posté par zebra3 . Évalué à 2.
Décidément, faut que je réapprenne à lire :-/
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Import des PDF
Posté par Sophie Gautier . Évalué à 10.
L'extension est effectivement intégrée pour importer un PDF dans Draw. Le mieux cependant est l'utilisation de PDF hybride, à savoir, après avoir créé un fichier en ODF, la possibilité d'inclure le fichier source dans le PDF. Ce qui permet ensuite de pouvoir retravailler la source et de garder le PDF uniquement pour la visualisation. Pour inclure l'ODF source dans l'export PDF, il faut cocher cette option lors de l'export PDF : Incorporer le fichier Open Document.
Sophie
[^] # Re: Import des PDF
Posté par antistress (site web personnel) . Évalué à 3.
Pas mal l'astuce, merci !
Sinon je confirme que ça ne marche pas sous Debian l'import PDF avec la dernière version (Debian Sid 64 bits)
[^] # Re: Import des PDF
Posté par antistress (site web personnel) . Évalué à 2.
Je viens d'essayer en passant par le menu (la barre d'outil n'offre pas les options). J'ai créé ce fichier hybride, par contre ça ne change rien il faut l'extension (ou la 4.0) pour ouvrir le fichier ?
(Sous Debian le mainteneur me répond qu'il a créé un paquet libreoffice-pdfimport (qui n'est pas une extension donc) à part pour ne pas ajouter de dépendance à poppler)
[^] # Re: Import des PDF
Posté par Guy . Évalué à 1.
Je viens de tester avec ton document. L'import du pdf marche vraiment bien, même s'il reste quelques petits défauts de mise en page.
[debian sid amd64 Version 4.0.4.2 (Build ID: 400m0(Build:2))]
# Merci !
Posté par Sophie Gautier . Évalué à 4.
Un grand merci pour la traduction du blog de Michael, je n'ai pas eu le temps de la faire :) Sophie
[^] # Re: Merci !
Posté par patrick_g (site web personnel) . Évalué à 6.
Merci à toi pour tout ton travail sur LibreOffice :-)
[^] # Re: Merci !
Posté par BlueDian . Évalué à 3.
Merci pour cette passionnante dépêche et les explications portées sur les améliorations actuelles du code (je ne pensais pas qu'il y avait autant de "poussière sous le tapis").
[^] # Re: Merci !
Posté par deasy . Évalué à 2.
Salut, juste pour signaler que le lien vers votre CV au format pdf est mort.
# Nouveaux formats
Posté par Shunesburg69 . Évalué à 3. Dernière modification le 24 juin 2013 à 17:19.
Ils ont ajouté des formats d’import, dont les formats de la suite AppleWorks.
# impossible d'installer les dictionnaires de grammalecte sur libre office 4.1
Posté par jluc69 . Évalué à 0.
Bonjour,
J'ai installé la version 4.1 de libre office et en voulant installé mes dictionnaires, j'ai plusieurs messages d'erreur: "python-loader:: No module named pythonloader, traceback follows
no traceback available" et (com.sun.star.uno.RuntimeException) { { Message = "python-loader:: No module named pythonloader, traceback follows\X000ano traceback available\X000a", Context = (com.sun.star.uno.XInterface) @0 } }
J'ai désinstallée le dictionnaire grammatical de grammalecte et installé langague tool et la, ca marche, mais je n'est pas de dictionnaire et tous est souligné en rouge.
[^] # Re: impossible d'installer les dictionnaires de grammalecte sur libre office 4.1
Posté par Jean-Baptiste Faure . Évalué à 2.
Je ne crois pas que ce soit le lieu pour demander de l'aide sur l'utilisation de LibreOffice.
Cela dit j'ai reproduis le pb avec la version du PPA Ubuntu mais sur la version officielle disponible sur le site LibreOffice ça fonctionne très bien ainsi qu'avec celle que je compile pour mes besoins de test.
Pour demander de l'aide sur LibreOffice : http://fr.libreoffice.org/assistance/
JBF
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.