Une nouvelle version de Gnumeric vient de sortir après presque deux années de développement. Pour rappel, Gnumeric est le tableur de la suite bureautique du projet Gnome, il utilise le format de fichier ODS (comme OpenOffice.org ou LibreOffice) et permet l'importation depuis différent formats tels que celui de Microsoft Excel).
Les principales nouveautés sont :
- Gnumeric utilise maintenant Gtk+ 3.x.
- La licence est maintenant GPLv2 ou GPLv3.
- Un meilleur support d'ODS.
- Des graphiques améliorés.
- Une précision améliorée. Par exemple, les erreurs d'arrondis lors de l'évaluation de formules telles que SUM(1;1E-20;-1) donne maintenant 1E-20.
- Gnumeric est légèrement plus rapide et occupe un peu moins de mémoire pour les gros classeurs.
- Le temps de démarrage a été diminué en incorporant un certain nombre de ressources dans le code.
- La batterie de tests a été améliorée ce qui permet d'identifier plus aisément un certain nombre de problèmes en relation avec les fichiers XLS, XSLX et ODS.
- Les nombres peuvent être formatés avec une unité SI.
- Gnumeric supporte maintenant l'introspection, ce qui permet de l'utiliser depuis des scripts.
Gnumeric 1.12.x nécessite la nouvelle version 0.10.x de GOffice, une version récente de libgsf et Gtk+-3.0 et toutes ses dépendances.
Aller plus loin
- Gnumeric (607 clics)
- Sources de Gnumeric (135 clics)
- Sources de GOffice (131 clics)
# Encore vivant !
Posté par Stéphane Klein (site web personnel) . Évalué à 3.
Je suis surpris de voir que ce projet continue à évoluer… je pensais qu'il était plus ou moins mort.
[^] # Re: Encore vivant !
Posté par Jean Bréfort (site web personnel) . Évalué à 3.
Et si ! Même si cela manque un peu de sang neuf.
[^] # Re: Encore vivant !
Posté par Argon . Évalué à 10.
Moi je suis ravi. Je ne fais pas grand chose de compliqué et j'utilises désormais Gnumeric et Abiword bien plus rapide et moins lourd que LibreOffice. Je suis très content de cette alternative.
de même que nous profitons des avantages que nous apportent les inventions d'autres, nous devrions être heureux d'avoir l'opportunité de servir les autres au moyen de nos propres inventions ;et nous devrions faire cela gratuitement et avec générosité
[^] # Re: Encore vivant !
Posté par freem . Évalué à 10.
J'ai un souvenir de gnumeric amusant.
Je travaillais dans une boîte, ou un commercial avait fait (ou emprunté à un de ses anciens collègues, je ne sais plus et je m'en fout) une feuille excel et m'avais demandé d'ajouter une fonctionnalité dedans.
Excel était incapable de lire les formules (alors qu'excel les avait créées, quand même! Via l'IHM d'ailleurs, à voir la tronche du bordel…) et le seul moyen que j'aie eu pour lire ces damnées formules (pour les copier dans un éditeur de texte histoire d'y voir clair) avait été d'utiliser gnumerics.
Depuis, je n'ai que des compliments pour cet outil, bien que je ne m'en serve a peu près qu'une ou deux fois par an. Léger, plus efficace que l'outil de microsoft sur le format de microsoft, libre, que demander de plus?
Félicitations pour la sortie en tout cas (au cas ou un contributeur passerait ici).
[^] # Re: Encore vivant !
Posté par Maclag . Évalué à 5.
Des anecdotes comme ça, y'en a à la pelle.
Moi j'ai récupéré un document MS Word corrompu pendant un crash lié à une sauvegarde du travail en cours… avec OpenOffice bien sûr, vu que MS Word déclarait ensuite le fichier corrompu et inutilisable. J'ai fait un heureux ce jour là!!
[^] # Effectivement…
Posté par Arthur Accroc . Évalué à 9.
Effectivement, quand MS Office décrète qu’un document est corrompu, assez souvent on arrive à le récupérer avec un autre logiciel, quelquefois avec un peu de perte au niveau de la mise en forme, mais pas forcément plus que pour un document pas corrompu.
Je suppose que pour les fonctions de conversion d’un autre logiciel, un document MS Office corrompu ne doit pas être tellement plus bizarre qu’un pas corrompu…
À l’inverse, je ne me rappelle pas avoir vu Open/LibreOffice déclarer un document corrompu ; cela dit, je n’en ai pas un usage très lourd.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Effectivement…
Posté par freem . Évalué à 9.
Peut-être, tout bêtement, que les autres logiciels considèrent que, de toute façon, tout document venant d'un logiciel faisant partie de MS office, est corrompu, alors un peu plus ou un peu moins…
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Plantages…
Posté par Arthur Accroc . Évalué à 6.
Disons encore moins qu’à l’original avant corruption. Je conseille fortement de vérifier le contenu.
Là, je me pose deux questions :
– ai-je une chance que l’utilisateur auquel j’ai affaire réussisse des sauvegardes manuelles sans faire de fausse manip et donc créer plus de problèmes (il y a des gens qui manipulent les fichiers au pif ; surtout ceux qui n’ont pas grandi avec l’informatique, mais je pense que ceux qui grandiront avec les nouvelles interfaces qui masquent la réalité du système de fichiers vont présenter les mêmes symptômes) ?
– ai-je une chance qu’il fasse l’effort ?
Et en général, je ne perds pas mon temps.
Il est intéressant de considérer les cas rencontrés dans les dernières années.
Le symptôme le plus fréquent est le plantage au démarrage :
– OpenLDAP qui décrète que sa base est corrompue (une fois tous les deux ans plus en cas d’arrêt brutal du système),
– LibreOffice à cause d’un fichier de configuration corrompu (rare, sachant que j’ai quand même une certain nombre d’utilisateurs),
– Xfce qui jette l’utilisateur à l’ouverture de session à cause d’une fichier de configuration corrompu (rare aussi, sachant que je l’ai mis par défaut à mes utilisateurs),
– Gnome 3.0 qui jette l’utilisateur à l’ouverture de session (deuxième ouverture avec mon compte de test ; je n’ai pas insisté).
Dans les deux ou trois premiers cas (pour le 4ᵉ, je n’ai pas fait d’investigation), il s’agit de la corruption d’un fichier géré avec Berkeley DB (la base de donnée qui réussit à se corrompre même si l’on n’y accède qu’en lecture) ou hdb (pas plus fiable, mais au moins performante).
Moralité : si vous investissez de votre temps à développer un logiciel de qualité, ne gâchez pas sa stabilité avec Berkeley DB !
Et puis s’il ne s’agit que d’options non cruciales d’un logiciel pour utilisateur final, mieux vaut encore les réinitialiser que de bloquer le lancement du logiciel avec un message cryptique pour l’utilisateur lambda.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Plantages…
Posté par reno . Évalué à 2.
Après quand tu as Firefox qui sync tout le temps sur le disque les utilisateurs se plaignent parce que ça ralenti tout.
Imagine plusieurs applications qui sync en permanence pour éviter toute corruption plus un disque dur de portable et là ouille ça rame.
Bref je pense que le problème de base c'est que les disques dur n'ont pas suivi l'évolution du matériel et que tout contournement est forcément "pourri": tuer les perfs ou avoir des corruptions?
Ça c'est du choix!
Vive les SSD!
[^] # Corruptions
Posté par Arthur Accroc . Évalué à 1.
Beaucoup de corruptions n’ont rien à voir avec les disques durs, mais sont d’origine logicielle :
– les corruptions des documents MS Office (les voies de MS Office sont impénétrables) ;
– les corruptions de Berkeley DB.
Recette pour corrompre la base d’OpenLDAP (je ne sais plus si c’est avec Berkeley DB ou hdb, mais ça « marche » peut-être même avec les deux) :
– démarrer OpenLDAP normalement ;
– l’arrêter — même proprement — aussitôt, avant qu’il ait fini son démarrage.
C’est fait ! Au démarrage suivant, il va gueuler que la base est corrompue et qu’il faut la restaurer, et refusera de démarrer. Que du bonheur…
Alors les auteurs d’OpenLDAP ont viré LDBM parce que c’était nul, il y avait un fort risque de corruption en cas d’écriture concurrente.
Dans la réalité, pour un annuaire contenant en gros un millier d’utilisateurs et sur plusieurs années, je n’ai jamais eu le problème (les utilisateurs ne passent pas leur temps à changer leur mot de passe).
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Plantages…
Posté par barmic . Évalué à 3.
Une autre solution c'est de les choses intelligemment comme pour une base de donné ou un fs. On utilise un format (par exemple) qui permet de revenir sur c'est pas si la dernière écriture n'est que partiel (principe dis du « tout ou rien » ou commit/rollback, bref tu es transactionnel). Pour ça par exemple tu peux utiliser un système de db avec des transactions, ouvrir le fichier uniquement en mode apend, etc
Firefox fait beaucoup de sync pour que l'utilisateur ne perde presque rien en cas de plantage c'est pas tout à fait pareil.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Plantages…
Posté par freem . Évalué à 2.
Sinon, j'ai lu un excellent article de boost * sur "exception safety" qui parle justement de ce type de problèmes.
Très intéressant dans la théorie, mais, très coûteux en dev dans la pratique, la technique du commit/rollback.
Technique qui, je précise, n'est pas liée aux bases de données dans les termes de cet articles.
Ben, si… pourquoi il pourrait planter? Parce qu'il supporte mal les exceptions. Enfin, attention ici, parce que les mécaniques liées aux plug-in sont très complexes à gérer de façon portable en C ou C++, vu que quand le système balance une sigsegv, on à pas le droit de faire un catch dessus, alors si un plug-in chargé fait une division par 0… bam! l'appli plante, car un plug-in n'est rien d'autre qu'une librairie, et c'est dont l'appli qui fait cette fameuse division.
[^] # Re: Plantages…
Posté par barmic . Évalué à 2.
Je n'ai pas voulu dire que les transactions sont liées aux bases de données. Mais il faut reconnaître qu'une base de données adresse le problème de la persistence des données de manière plutôt efficace : la cohérence (les propriétés ACID ou CDP), mais aussi la performance en lecture comme en écriture.
Imaginons que Firefox et l'ensemble des plugin que tu utilisent soient tous exempte de bug. Ça n'empecherais pas de manger un sigkill par exemple. Le OOM peut faire la fête à ton logiciel sans qu'il n'y ai le moindre bug sur la machine. Et dans tout les cas, tu peut toujours avoir une panne de courant. C'est des cas qui arrivent dans la vraie vie et qui ne sont pas des bugs, qui ne sont pas liés à un langage ou un autre qui nécessitent d'être traité.
Intéressant l'article de boost faudra que je prenne du temps pour le lire entièrement.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Plantages…
Posté par freem . Évalué à -1.
Hum, en fait, ici, il faut insérer une nuance, je panse (oh, ça rime huhu… ps: la faute est volontaire et.. gargantuesque)
Pour redevenir sérieux…
si un plugin mange un sigkill, gérer le sigkill de façon portable deviens juste… infernal.
Pourquoi? Parce que le sigkill, s'pas une exception, s'pas un bug du logiciel, mais, une demande de l'utilisateur. L'OS étant un utilisateur comme un autre, naturellement… faire la distinction est de mauvais goût, et amène à des bugs.
Qui est le dev pour aller contre l'OS, après tout? Ou de son utilisateur?
L'OOM dont tu parles, en revanche, c'est bel et bien une exception. Rarement gérée, mais exception tout de même, on peut s'en sortir si on la gère.
D'ailleurs, elle est liée à un bug, que ce soit de notre application, d'une autre, ou de l'OS. La gérer serait donc… élémentaire, si on veut un système parfait. Maintenant… a chaque allocation, supporter l'oom? C'est faisable, mais, combien de lignes de code pour une situation qui n'apparaitra jamais? Oh, allez, presque jamais… perso, j'en ai jamais vu qui ne soient pas dues à un autre bug… moui, une boucle infinie est "si vite arrivée"… par contre, les allocations trop grosses, ça… j'ai pas encore vu, mais je suis encore jeune, et j'ai pas eu la chance de bosser sur des systèmes à forte concurrence. Et pourtant… quand j'alloue, je vérifie le retour…
Si quelqu'un contredit ce dernier point, je le prie de citer une librairie qui fasse ce job, j'ai justement décidé de réécrire un soft libre avec un mécanisme de plug-in… j'ai déjà assez galéré pour que la 1ère fonctionnalité, le dessin, fonctionne, alors épargnez-moi de refaire la mécanique de plug-in 20 000 fois, merci. Je suis réellement preneur, vu que je n'ai aucun retour (bon, ok, logiciel en alpha, avec très peu de fonctions de bases, ça explique le manque de retours… mais c'est décourageant, j'ai envie de lâcher et de passer à un logiciel qui me serve plus… d'autant qu'opengl, c'est la croix et la bannière à comprendre!)
La différence est de taille… Sachant que, de façon classique, un plug-in est une bibliothèque, il est réellement complexe de dire, de façon portable, que si une bibliothèque doit mourir, l'appli en entier ne le doit pas.
A noter, tout de même, que ce problème est apparu avec les MDI (Multi Document Interface). Avant, il n'y aurait pas eu de souci puisque chaque logiciel n'aurait géré qu'une chose. On aurait donc tué qu'une seule chose.
La faute à qui? A l'utilisateur, pour le coup, qui refuse de comprendre que foutre un piston en l'air fout la machine entière en l'air, si c'est un PC. Dans le cas d'une voiture, c'est tout à fait différent, c'est tellement plus complexe, la mécanique… ben tiens!
Au passage, ne pas supporter l'exception OOM est un bug. Que toutes les applis ont, certes.
Mourir parce qu'on nous demande de mourir (sigkill) n'est pas un bug, mais une obéissance à l'OS.
D'ailleurs, on voit les processus qui bug: ils n'obéissent pas quand on les tue!!!
Pour l'article de boost, en très gros, il détaille plusieurs formes de résistances à l'exception, plus ou moins coûteuses en temps, en fonction des besoins.
Je ne me permettrait pas de le résumer, ce serait l'insulter, parce qu'il est déjà très compact et explicite… pour un programmeur orienté objet.
Mais, en très gros, il présent différents niveaux niveaux de support:
Dans la pratique, récupérer d'une exception nécessite une bonne compréhension des chemins d'exécution. Ce dont peut de dev, je crois, peuvent se targuer, et surtout pas moi… c'est pour ça que quand je fais un programme, à la moindre situation ou j'ai un doute, je fais un test, et je balance une exception.
Le programmeur idéal ne pondrai que des fonctions de niveau 3, et donc on pourrait se permettre de les ignorer et les passer en simple avertissements. La réalité, c'est que si un fichier de config vital, il existe pas, ben on va pas l'inventer, sauf à être mono plateforme!
Ou alors, qu'on m'explique, ça m'intéresse pour autorealm, parce que toutes les exceptions que je lève jusque la, je vois pas comment les récupérer… d'ailleurs, mon souci, c'est juste d'avoir des crash qui disent pourquoi ça merde, parce que c'est déjà mieux que la moyenne…
La preuve, que ceux qui n'ont jamais eu d'application qui plante sans dire pourquoi lèvent la main! Et merde, j'y vois plus rien, baissez donc les bras… et puis d'ailleurs, pourquoi j'en lève 10, alors que j'en ai que deux?
[^] # Plus marrant…
Posté par Arthur Accroc . Évalué à 2. Dernière modification le 30 décembre 2012 à 03:36.
J’ai vu plus marrant : l’installateur de la Fedora qui ne plante pas, juste il s’arrête en plein milieu de l’installation (ou encore plus drôle : de la mise à jour !) et il ne fait plus rien.
Pas planté (il ne rend pas la main, mais on peut accéder sans problème aux autres consoles du système), pas en boucle infinie (le CPU n’est pas chargé), juste il attend on ne sait quoi jusqu’à la Saint Glinglin.
Pendant ce temps-là, ton système est à moitié installé et tu ne peux rien faire.
Heureusement, pour la Fedora 18, l’installateur change « pour améliorer l’expérience utilisateur »… Nul doute que le nouvel installateur sera bien meilleur que l’ancien : déjà, il retarde la sortie de la distribution d’au moins deux mois. L’installateur précédent ne commençait à mettre le souk avant qu’une fois lancé… beaucoup plus limité. Là on atteint la quintessence : le logiciel qui plante toute ta distrib avant même que tu ne puisses la télécharger !
Malgré ce coup de gueule, un grand merci à tous les développeurs de la Fedora, qui en ont fait une distribution excellente (une fois installée) pendant bien des années (au moins de la 6 à la 14).
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Plantages…
Posté par barmic . Évalué à 3.
Pour commencer un point important. Le SigKill n'est pas une demande de l'OS pour ce suicider. Le SigKill est un meurtre pur et simple. Mais ce n'est pas pour ça que tu n'a rien à faire pour le supporter. Un programme qui mange un sigkill doit pouvoir être relancé (tu rigole mais c'est pas le cas de tout les logiciels) si possible avec le moins de perte de données possible. C'est pour ce genre de choses que firefox multiplie les flush de tampon.
Tu parle de l'exception, je pensais à l'OOM Killer quand le système n'a plu de mémoire et balance un uppercut au logiciel qui lui semble le plus approprié.
Pour ce qui est de l'exception, c'est principalement parce qu'il n'y a pas grand chose de possible et grand chose à faire dans le cas où tu n'arrive pas à faire ton allocation. Tu ne peux plus allouer de mémoire donc à moi de pouvoir libérer de la mémoire, il n'y a pas grand chose à faire mis à part se débrouiller pour garder un état cohérent sur disque (et éventuellement envoyer un message à l'utilisateur mais toujours sans allocation).
Pour ce qui est des plugins tu vois une façon de faire, via des bibliothèques partagée, mais tu peut très bien les avoir en mode managé c'est plus limité mais tu as un contrôle bien plus important et tu peut très bien t'en sortir même en cas de plantage de celui-ci (bien sûr le sigkill si ça reste dans le même processus tu peut toujours rien y faire). Tu peut aussi les exécuter dans des processus séparés là tu peut faire tout ce que tu veux dedans (tu es dans un mode natif) et tu peut survivre à un sigkill, mais tu perd en performance si tu as besoin de beaucoup de communication entre tes processus.
Bref tout ça pour dire qu'il y a du choix et que le choix se fait en fonction du besoin. Minix par exemple ne plante pas si l'un de ses driver plante, il se contente de le relancer.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Plantages…
Posté par freem . Évalué à 2. Dernière modification le 02 janvier 2013 à 17:30.
J'ignorais l'existence d'OOM killer.
Ce ne serait pas plutôt que l'appli se mange une exception OOM, ne la traite pas, et donc en meurt? Ah, non, désolé, j'oublie parfois que les exceptions
ne semblent existern'existent qu'en POO…Pour les plug-in, je ne suis pas sûr de comprendre ce que tu veux dire par mode managé? Tu pourrais détailler (ou balancer un p'tit lien), parce que je suis assez intrigué, je n'ai vu aucune référence à cette méthode quand j'ai fait quelques recherches C++ sur le sujet.
Peut-être que ça fait référence à des langages à VM, style Java ou .NET?
Côté lancement de processus séparé: oui, perte de perf, mais sinon, comment ça marche? Double fork puis chargement du plug-in?
Ca me semble pas portable du tout en plus de la lourdeur…
[^] # Re: Plantages…
Posté par barmic . Évalué à 3.
Je laisse patrick_g en parler :
https://linuxfr.org/news/le-noyau-linux-2636-est-disponible#long2
C'est des modes non natifs, donc oui ça peut être avec des machines virtuelles comme Java, .Net ou python, mais aussi des langages de scripts comme le lua. Dans c'est cas, tu contrôle ce qui se passe dans le code et une erreur dans celui-ci peut tout à fait être gérée. Un autre moyen avec un mode managé peut être d'utiliser OSGi.
C'est du natif donc la portabilité tu ne l'a pas. Pas la peine d'un double fork, ensuite pour le plugin ça dépend de ce que tu as défini comme en étant un. Tu peut très bien dire qu'un plugin est un programme qui suis un protocole sur son entrée et sa sortie standard comme pour les CGI par exemple.
Pour l'utilisation d'une dll dans un processus séparé, il faudrait voir ce que font firefox et chrome avec flash par exemple.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Plantages…
Posté par freem . Évalué à 2.
Hum… c'est mon cas… enfin, j'essaie de faire de la qualité, et c'est pour ça que le dev prend un temps fou (au bout de presque un an, toujours pas utilisable pour un utilisateur réel, sachant que je "réécrit" un logiciel écrit en delphi pour le rendre portable…).
Pour le coup, niveau configuration j'ai opté pour un fichier pour l'appli, et deux arborescences de fichiers différentes pour l'interface (une pour les menus, une pour les toolbars amovibles, sachant que chaque item invoque l'action plug-in).
Si tu as des avis la-dessus, je suis preneur…
Sachant que, bien entendu, le coût que j'ai accepté de payer sur mon temps personnel, je doute très fortement qu'une entreprise ou même la plupart des logiciels libres acceptent de le payer, vu qu'on risque toujours de se planter, et dans ce cas, on s'expose au risque de perte de milliers d'heures de boulot tout de même (ben oui, 3H/jour pendant 1 an, on tape déjà le millier… j'en suis pas encore la, mais je dois bien être à 500-600 heures, pour un résultat non productif, si j'inclue les heures de recherche et d'apprentissage purs. ).
Mon humble avis:
Si vous développez un logiciel de qualité, commencez par vérifier chaque paramètre de configuration. Si le paramètre lu ne correspond pas, balancez une exception, qui explique d'où elle viens, et ce qui la cause.
Le jour ou vous aurez fini votre fonctionnalité, faites un tour dans vos exceptions (grep -lr throw devrait faire le taf) et implémentez des try…catch.
Du coup, je te contredis: dans un premier temps, les laisser planter tout le système est une bonne idée, ça permet de se concentrer sur l'ajout de fonctionnalités et l'amélioration des messages d'erreurs, qui sont au moins aussi importants que la stabilité.
Bien sûr, cette technique porte de meilleurs fruits si on se base sur des fichiers de texte brut, car l'utilisateur peut alors régler le problème… lui-même, sans télécharger de logiciels.
Faut pas oublier que les dev sont pas des bêtes de somme, surtout dans le libre ou la plupart font ça sur leur temps perso, et n'ont que peu voire aucun retour tant que le logiciel n'est pas utilisable. (Je ne peux pas parler de la phase du logiciel utilisable puisque le mien ne l'est pas encore…)
Le problème, c'est qu'un logiciel de qualité, ça prend plus de temps à être utilisable qu'un truc mal codé, et pendant ce temps, le moral du dev joue énormément.
[^] # Re: Effectivement…
Posté par Argon . Évalué à 2.
Quand quelque chose s'est mal passé une fenêtre au démarrage de Open/LibreOffice propose une réparation des documents. J'ai vu ça plusieurs fois sur la version Windows et la réparation a toujours très bien fonctionné. En revanche je ne sais pas ce qu'il fait exactement.
de même que nous profitons des avantages que nous apportent les inventions d'autres, nous devrions être heureux d'avoir l'opportunité de servir les autres au moyen de nos propres inventions ;et nous devrions faire cela gratuitement et avec générosité
[^] # Re: Encore vivant !
Posté par scand1sk (site web personnel) . Évalué à 2. Dernière modification le 25 décembre 2012 à 14:53.
Autant Abiword est encore trop buggé et pauvre pour être vraiment utilisable (de toutes façons j'utilise maintenant LaTeX même pour des documents relativement simples), autant Gnumeric est un excellent tableur, léger, efficace et stable. Je l'utilise presque quotidiennement. La création de graphes est particulièrement bien foutue.
L'interopérabilité avec LibreOffice et Excel laisse quand même à désirer. À quand le format ODS par défaut ?
[^] # Re: Encore vivant !
Posté par Jean Bréfort (site web personnel) . Évalué à 4.
Le format ODS par défaut pose un certain nombre de problèmes, la norme ne définissant pas tout. De plus, le format gnumeric est plus simple à manier à de nombreux points de vue et de sauvegarder tout ce que Gnumeric supporte, ce qui n'est pas toujours le cas d'ODS. Maintenant si quelqu'un veut avoir ods par défaut, c'est possible en allant charcuter le fichier plugin.xml dans le répertoire du plugin openoffice : il suffit d'ajouter priority="100" après id="odf" et le tour est joué.
# petite nuance
Posté par steph1978 . Évalué à 7.
ce n'est pas son format natif. son format natif est un xml compressé en gzip.
peut être aurait-il fallu dire "gère".
Quoi qu'il en soit, cette nouvelle version est une excellente nouvelle. Gnumeric est souvent le seul tableur utilisable sur des vieux portables ou des petits notebooks.
# Icônes à rafraichir
Posté par O'neam Anne . Évalué à 2.
Sans vouloir faire mon enfant gâté, je pense que les créateurs du thème d'icône Gnome amélioreraient beaucoup l'aspect du logiciel en fournissant de nouvelles icônes respectant les conventions Tango et plus proches du reste des icônes de Gnome. Là, les icônes spécifiques à Gnumeric accusent leur age, et jurent un peu au milieu des icônes génériques plus modernes.
LinuxFr, parfois c'est bien de la MERDE : https://linuxfr.org/users/c2462250/journaux/ecriture-inclusive-feministes-et-wikipedia#comment-1793140
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.