La fondation The Document Foundation vient d'annoncer la sortie la version 3.4 de LibreOffice.
Cette version a poursuivi son nettoyage, entamé lors de la version 3.3 en enlevant pas moins de 5 000 lignes de code obsolète et inutilisé, ou en traduisant une grande partie des commentaires en allemand vers l’anglais. Cette nouvelle version ne se limite pas à ces changements comme nous allons le voir en détails dans la suite de la dépêche.
Selon la nouvelle convention adoptée cela signifie que la suite bureautique est prête à être téléchargée par les utilisateurs expérimentés mais qu'il faudra attendre la version 3.4.1 pour les entreprises ou pour les utilisateurs prudents.
Sommaire
- Writer
- Calc
- Impress / Draw
- Performances
- Interface graphique
- Divers
- Officialisation de la fondation
- LibreOffice et OpenOffice.org : toute une histoire
Writer
- Dans le but d’améliorer le respect de la norme des documents ODF, il est maintenant possible d’associer des couleurs et un style particulier aux colonnes, ainsi qu’aux lignes de séparation des notes de bas de page.
- L'extension Graphite autorisant un rendu typographique plus soigné, a été complètement ré-écrite, ce qui en a amélioré la stabilité et augmenté la vitesse d’exécution d'un facteur dix. Cette technologie, développée sous licence libre par la SIL Foundation, permet d'incorporer dans les polices elles-mêmes des scripts de mise en forme adaptée au contexte de rédaction. On peut ainsi bénéficier, entre autres de : ligatures anciennes, reconnaissance des fractions, numérotation textuelle automatique et alignée à droite etc.
Calc
- Le déplacement ou la copie d’une feuille est maintenant accessible via le menu « Édition ».
- Le module de gestion des références extérieures au document courant a été revu dans le but d’en améliorer les performances et de corriger certaines erreurs. Ainsi, les liens OLE sont convertis en liens externes quand on ouvre un fichier Excel®, alors qu’ils étaient ignorés auparavant.
- Les tableaux dynamiques croisés gèrent maintenant un nombre illimité de champs. Les performances ont également été améliorées.
Impress / Draw
- L'export en HTML est amélioré par l'ajout des diapos en mode galerie d'images au format vignette dans la table des matières.
Performances
- Certains formats d’encodage du texte rarement utilisés sont maintenant dans une bibliothèque à part qui ne se charge que si nécessaire, permettant d’économiser 1 Mio de RAM.
- Une configuration inadéquate de la gestion des polices sous GNU/Linux a été corrigée permettant d’économiser jusqu’à 800 Kio de RAM selon le nombre de polices installées.
- Le module d’importation et d’exportation en ODF « plat » (extension « .fodt ») a été réécrit en C++ (au lieu de Java), pour en améliorer la vitesse. (Il ne s’agit, bien sûr, pas du mode d’enregistrement par défaut des documents mais d’un mode facilitant certaines manipulations du document).
Interface graphique
- Unity, sous Ubuntu, commence à être pris en compte, ainsi que le menu global (i.e comme sous Mac OS X).
- Certaines polices, au sein de la liste déroulante des polices, bénéficient d’un aperçu quand leurs formes ne sont pas explicitées par la modification de leurs noms (OpenSymbol, polices arabes… aperçu).
- Sous GNU/Linux, le rendu du texte est maintenant géré par Cairo permettant d’offrir un rendu global cohérent, et l’intégration du thème avec GTK+ a été améliorée.
- La fonction « recherche » (activable avec Ctrl + F) se comporte maintenant comme celle de Firefox (aperçu).
- Pour les documents protégés par un mot de passe, il est désormais possible de le modifier une fois le fichier ouvert.
Divers
- Il est maintenant possible d'installer la version 3.3 et 3.4 sur une même machine. Cependant les fichiers de configuration sont partagés et interdisent le lancement simultané des deux versions.
- Le format de StarOffice (l’ancien format utilisé par la suite à l’époque où elle portait encore ce nom) n’est plus disponible qu’en lecture seule, ce qui allège la taille du filtre, ainsi que celui du menu d’enregistrement.
Officialisation de la fondation
On s’aperçoit que les changements apportés à cette version ne sont pas des plus transcendant mais tout ceci s'explique par le fait que la Fondation est attelée à son officialisation. En effet, après les 50 000€ récoltés, les formalités administratives avancent et la structure même de la fondation a le choix de s’implanter dans une de ces trois villes Allemandes :
- Berlin
- Wiesbaden
- Munich
LibreOffice et OpenOffice.org : toute une histoire
La nouvelle que tout le monde attendait est arrivée : Oracle® vient de se séparer d'OpenOffice.org !
Fin de l'histoire. Ah… non ?
The Document Fondation n'est pas la communauté qui en sera chargé puisqu'Oracle a décidé de laisser sa suite à la Fondation Apache ! Cette décision a été fortement influencé par IBM® dont la suite Lotus Symphony est basé sur OOo.
La question que tout le monde se pose est — bien évidement — pourquoi The Document Fondation n'a pas récupéré le bébé pour ensuite les fusionner ? C'est là qu'on comprend pourquoi IBM a poussé Oracle sur la Fondation Apache : son nom reste utilisable et permettrait aux entreprises de continuer à maintenir une version d'OOo sans avoir à installer autre chose.
En dehors des entreprises, qu'en est-il des particuliers ? La majeure partie des distributions GNU/Linux ayant remplacé OOo par LibreOffice ; il semble évident que la transition se fasse toute seule (On pourra noter qu'une partie des utilisateurs vont également migrer vers des solutions dans les nuages comme Google Docs).
La Fondation Apache conserve donc OOo sous la licence éponyme tout comme les brevets qu'Oracle avait sur certaines parties du code. La licence Apache étant compatible avec la GPLv3 on peut s'attendre à ce qu'OOo change de licence permettant à LibreOffice d'en importer le code facilement.
Bon, mais il va se passer quoi maintenant ?
On se retrouve pour l'instant avec deux suites et plusieurs scénarios peuvent se produire à court-terme : IBM et sûrement quelques entreprises peuvent vouloir garder OOo sous Licence Apache et continuer à participer au code. LibreOffice faisant de même de son côté. Cependant il est clair que l'avenir du libre sur le long terme n'est pas à se tirer dans les pattes ni à manquer de visibilité vis-à-vis des solutions propriétaires ; ainsi une seule des deux émergera au-dessus de l'autre (à moins qu'elles ne fusionnent).
Néanmoins, ne nous y trompons pas, un grand pas a été fait et on doit continuer à insuffler une vie à l'avenir de la suite bureautique phare du monde libre pour qu'elle puisse enfin déployer ses ailes et s'épanouir par elle-même !
Aller plus loin
- Site Officiel (1160 clics)
- Notes de version (313 clics)
- Calendrier des sorties (166 clics)
- Oracle se sépare d'OOo (276 clics)
- Présentation en images des nouveautés (347 clics)
- Avis de Chris Kanaracus sur la séparation d'OOo et d'Oracle sur PCWorld (152 clics)
# c'est bôôôôoo !
Posté par ᴼ ᴹᴬᴺᴺ . Évalué à 7.
J'aime
Sinon pour les numérotations de version je suis perplexe, on veut dire que les grosses versions maintenues longtemps sont en *.1 tandis que celle qui finissent pas .0 sont encore de sortes de super-beta, pourquoi ne pas les appeler autrement (numéro majeur avec un suffixe/préfixe) histoire d'avoir des numéros rond pour les versions à faire installer à M. Toutlemonde.
Je trouve ça compliqué.
207829⁶+118453⁶=193896⁶+38790⁶+14308⁶+99043⁶+175539⁶
[^] # Re: c'est bôôôôoo !
Posté par swilmet . Évalué à 4.
Il y a un bôôô schéma (le deuxième) qui explique la numérotation.
Il faut donc distinguer les releases en « X.X » (pour tester à plus grande échelle) et « X.X.X » (pour la production).
Une release « X.X.0 » est équivalent à « X.X ».
C'est un peu tordu, mais quand on y réfléchi, c'est comme ça pour beaucoup de logiciels. Parfois il faut même attendre plusieurs dizaines de versions mineures pour que ce soit suffisamment stable en production (qui a dit Asterisk ?).
[^] # Re: c'est bôôôôoo !
Posté par imr . Évalué à 7.
Il ne dit pas que ce n'est pas rationnel, il dit que c'est dommage que le numéro le plus compliqué soit celui pour les gens comme tout le monde; selon le schéma:
libreoffice N beta rc > testeurs
libreoffice N.X > power users
libreoffice 3.X.X > individual. corporate
[^] # Re: c'est bôôôôoo !
Posté par claudex . Évalué à 10.
Les gens comme tout le monde, ils cliquent sur Obtenir la dernière version et ils s'en foute que le numéro ait 3 ou 4 chiffres.
« 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: c'est bôôôôoo !
Posté par imr . Évalué à 9.
Les gens comme tout le monde, ils cliquent sur Obtenir la dernière version et ils s'en foute que le numéro ait 3 ou 4 chiffres.
Qu'est ce qui est le plus difficile à retenir? LibreOffice3 ou libre0ffice 3.4.3 ?
Qu'est ce qui représente le mieux la dernière version, le progrès ? LibreOffice4 après LibreOffice3 ou LibreOffice 3.4.4 après LibreOffice 3.4.3 ?
Pour quelqu'un qui ne lit pas et ne lira jamais une page explicative sur un numéro de version, déjà qu'il ne lira probablement pas la doc non plus?
Après, si la définition de "les gens comme tout le monde", c'est "des gens comme moi" c-a-d des gens qui connaissent linux, la différence entre libre office et open office, entre les différentes licences et qui sont intérressés par le versionnage et qui peuvent passer leur samedi à en discuter, alors ok, c'est pareil.
Mais pour moi, d'après ce que j'en vois autour de moi, les "gens comme tout le monde", ce sont des gens qui appellent internet leur navigateur et m'appelle pour me dire "internet est cassé" quand ils ont un problème d'usage avec leur navigateur. A cause de ces gens, la manière de nommer les applications est importante, et la simplicité du versionnage aussi. Et rien n'empêche d'avoir le vrai versionning de la release disponible à coté pour le support technique.
[^] # Re: c'est bôôôôoo !
Posté par claudex . Évalué à 3.
Pour ces gens là, il ne verront jamais que l'écran de démarrage sur lequel il est écrit Libreoffice 3, donc ça ne change rien pour eux.
« 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: c'est bôôôôoo !
Posté par foutaises . Évalué à 2.
"Les gens pensent, les gens disent..."
Au final, on peut faire penser tout et son contraire aux "gens".
Bref, ne tombons pas dans la facilité d'imaginer ce qu'ils pensent et de dire que c'est avéré.
[^] # Re: c'est bôôôôoo !
Posté par swilmet . Évalué à 1.
Monsieur tout le monde utilise ce qu'il y a d'installé sur son ordi (pour le boulot par exemple), ou bien il télécharge à partir du premier lien venu.
Pour LibreOffice c'est toujours la version 3.3.2 qui est mise en avant.
Donc monsieur tout le monde s'en fiche un peu que ce soit la version A.B.C ou X.Y.Z.
Maintenant si la version 3.4.0 s'était appelée 3.4 RC truc, il y aurait moins de « power users ». Ça a beau être le même code, mais le fait qu'il y ait moins d'article sur le web (comme cette dépêche) fait qu'il y a moins de rapports de bugs, et donc ça ne fait que retarder la stabilisation.
Et puis de toute façon LibreOffice a choisi de sortir des releases à intervalles régulières, basées sur le temps et non sur les fonctionnalités ou la stabilité.
# ville allemande
Posté par Internaciulo . Évalué à 6.
s/Weisbaden/Wiesbaden/
[^] # Re: ville allemande
Posté par BAud (site web personnel) . Évalué à 2.
corrigé :) merci.
# Fusion des 2 projets.
Posté par Astaoth . Évalué à 2.
Je n'ai pas compris, pourquoi est-ce que les 2 projets ne sont pas fusionnés en conservant le nom "OpenOffice.org" ?
Ainsi, les entreprises auraient juste à maintenir OOo (comme dit à la fin de la dépêche), et ceux qui n'ont pas suivit l'affaire (entreprises et particuliers) et qui ont toujours un OpenOffice.org installé ne seraient pas perdus et continueraient à utiliser le même logiciel.
Emacs le fait depuis 30 ans.
[^] # Re: Fusion des 2 projets.
Posté par claudex . Évalué à 4.
Parce que les politiques de gestion de projet ne sont pas les même entre la TDF et la fondation Apache.
« 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: Fusion des 2 projets.
Posté par barmic . Évalué à 6.
La fondation Document souhaite continuer en GPLv3. La fondation Apache n'utilise que la licence Apache qui est incompatible avec la GPL. Ça signifie que tout le code de la fondation Apache peut être fusionné à ceux de LibO, mais l'inverse n'est pas vrai.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Fusion des 2 projets.
Posté par swilmet . Évalué à 4.
Ce n'est pas très clair ce que tu dis.
Si j'ai bien compris, on peut intégrer du code sous licence Apache dans du code sous GPL, mais pas l'inverse, c'est ça ?
[^] # Re: Fusion des 2 projets.
Posté par claudex . Évalué à 6.
C'est ça, parce que la licence Apache n'est pas copyleft contrairement à la GPL.
« 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: Fusion des 2 projets.
Posté par swilmet . Évalué à 5.
Ah oui OK.
En fait c'est expliqué ici. Avant les versions d'Apache 2.0 et de la GPL 3, les deux licences étaient complètement incompatibles.
[^] # Re: Fusion des 2 projets.
Posté par claudex . Évalué à 4.
Oui, c'est comme la BSD 4 clauses, avec la clause de publicité (la troisième de http://en.wikipedia.org/wiki/BSD_licenses#4-clause )
« 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
# Nouvelle interface
Posté par davandg . Évalué à 10.
Ils bossent pas sur une nouvelle interface ? J'avais vu des mockups, je ne sais pas ce qu'ils sont devenus, quelqu'un à des infos ?
[^] # Re: Nouvelle interface
Posté par CrEv (site web personnel) . Évalué à 2.
je crois qu'une première démo de la nouvelle interface devrait être disponible ... en même temps que DNFE
(il y avait eu un appel à mockups je crois, mais depuis...)
[^] # Re: Nouvelle interface
Posté par coid . Évalué à 3.
Suite aux critiques massives sur les premiers mockups, Renaissance a eu du plomb dans l’aile, et il a finalement été décidé d’évoluer lentement, par retouches successives.
Ensuite, le rachat par Oracle et le fork de LibreOffice n’ont pas arrangé les choses. Le projet n’est sans doute pas complètement mort, mais ce n’est pas la priorité de LibreOffice actuellement. Pour l’instant, ils se concentrent sur la mise ne place de l’infrastructure, le nettoyage du code et une plus grande facilité de compilation. Quand tout sera un peu mieux rationalisé et mis en place, ça redémarrera probablement.
D’ici 6 mois (estimation personnelle), la Document Foundation aura trouvé ses marques, et on peut supposer que les choses intéressantes vont commencer à sortir, notamment parce que les nouveaux dévs se seront familiarisés avec le code.
Enfin, tout ça n’est vrai que si la bataille pour la communauté avec la fondation Apache ne dégénère pas.
# Cohabitation
Posté par madhatter (site web personnel) . Évalué à 2.
Mouais...
En dehors d'un soucis de confusion pour le pékin moyen (et encore, c'est surtout un problème de communication et d'identité à mon avis), je ne vois pas trop le problème à ce que les 2 cohabitent et encore moins ce qui les amènerait à se tirer dans les pattes.
C'est le cas pour des tas de projets libres et ça se passe très bien.
Au contraire, étant donné qu'elles sont libres toutes les 2, elles vont pouvoir s'entraider l'une l'autre tout en restant compatibles.
De plus, je pense que c'est un domaine dans lequel il y a encore pas mal d'évolutions possible, notamment dans la manière de penser la conception d'un document, pour qu'elles ne se télescopent pas.
There is no spoon...
[^] # Re: Cohabitation
Posté par barmic . Évalué à 8.
Il pourrait y avoir une véritable émulation entre les deux suites. On voit par exemple que ça a fait beaucoup de bien à Firefox d'avoir des concurrents.
En plus s'ils pouvaient en profiter pour créer des sous projets communs comme une externalisation des filtres d'entrée/sortie histoire d'avoir exactement les même sur les deux et de permettre à d'autres suites d'en profiter ce serait vraiment bénéfique à tout le monde (sachant que les filtres n'ont aucune bonne raison d'être en GPL vu qu'on veut qu'ils soient utiliser dans le maximum d'outils).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Cohabitation
Posté par Thomas Douillard . Évalué à 7.
Il y a assez de potentiel de développement pour se permettre un luxe pareil sur une quantité de code aussi importante ?
Si c'est pour avoir deux suites qui divergent en divisant par deux la vitesse de développement de chacune c'est pas forcément une bonne idée.
[^] # Re: Cohabitation
Posté par barmic . Évalué à 5.
Si le développement est trop lourd pour eux, ils n'auront qu'a trouver des points sur les quels collaborer, ça permettras à Abiword et KOffice d'en profiter.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Cohabitation
Posté par madhatter (site web personnel) . Évalué à 1.
On peut se poser la question en effet.
Pour autant, sur 2 gros projets comme le sont le noyau Linux et le noyaux BSD, ça fonctionne plutôt bien. Ils ont des objectifs différents mais se rejoignent sur certains point et bénéficient l'un l'autre des parties qui peuvent leur être favorables.
There is no spoon...
[^] # Re: Cohabitation
Posté par claudex . Évalué à 5.
De quel noyau BSD tu parles?
« 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: Cohabitation
Posté par Thomas Douillard . Évalué à 8.
Et les BSD-istes se plaignent que Linux va trop vite dans ses changements, et ça trolle pour savoir si certains softs ne gagneraient pas à être conçus en utilisant les spécificité de Linux sans se soucier de savoir si elles sont implémentées dans les BSDs.
Clairement ça ne marche pas aussi bien que ça. La comparaison entre nombre de contributeurs entre les noyaux BSD et Linux doit être éloquente. Un projet commme Libre/Open Office a t'il le même potentiel en terme de développeurs potentiel que l'addition des Linux et BSD ? J'en sais rien - je vois pas trop des individuels se lancer dedans, par contre des contributions d'entreprises c'est pas impossoble.
[^] # Re: Cohabitation
Posté par madhatter (site web personnel) . Évalué à -3.
Bien que je sois d'accord avec toi, tu rentres dans le détail là.
Même si c'est loin d'être parfait, je peux installer n'importe quelle distribution GNU/linux majeure (entre autre Debian, Fedora, RedHat, Gentoo) ou n'importe lequel des 3 principaux BSD (Free, Open et Net) sur un serveur destiné à la production dès demain, ça fonctionnera sans problèmes.
C'est en ça que j'estime que "ça marche". ;)
There is no spoon...
[^] # Re: Cohabitation
Posté par windu.2b . Évalué à 7.
Tu peux aussi installer un Windows sur ton serveur, et ça marchera aussi (enfin, je suppose...). Est-ce à dire que la collaboration Linux/*BSD avec MS fonctionne bien ?
# Travail collaboratif
Posté par Maxime (site web personnel) . Évalué à 10.
Je me surprend de plus en plus souvent à lâcher LibreOffice pour Google Docs car ce dernier me permet de travailler simplement à plusieurs tout en pouvant accéder à mes fichiers depuis n'importe où.
C'est pour moi un avantage énorme et je pense que c'est le futur. Malheureusement, je ne pense pas qu'il soit souhaitable que tous nos documents soient hébergés par Google, et même s'ils n'ont pas de mauvaises intentions.
LibreOffice possède encore l'avantage d'être largement plus complet que Google Docs, il ne lui manque que cet aspect collaboratif selon moi. Il serait vraiment énorme de pouvoir créer un nouveau document, que mes collègues puissent venir éditer le même fichier que moi un peu comme sur Google Docs, qu'on puisse faire des annotations et y répondre facilement, etc.
Êtes-vous au courant d'initiatives qui essayent de répondre à ce besoin ?
[^] # Re: Travail collaboratif
Posté par FabienC . Évalué à 2.
UNG semble être prometteur de ce coté : http://www.freecloudalliance.org/ung-Home.Page
[^] # Re: Travail collaboratif
Posté par patrick_g (site web personnel) . Évalué à 2.
Il me semble que dans Abiword il y a une fonction de travail collaboratif non ?
[^] # Re: Travail collaboratif
Posté par Maxime (site web personnel) . Évalué à 5.
Ouaip, j'allais en parter dans mon premier commentaire mais j'ai préféré ne pas orienter directement sur des solutions XMPP pour recueillir d'autres pistes avant.
Avec XMPP, il est facile d'imaginer (surtout quand on a déjà vu :P) que le protocole prenne en charge les communications pour l'édition en live à plusieurs, et il suffirait que les clients se disent : ok on enregistre sur tel serveur FTP ou directement sur le serveur XMPP s'il a un certain plugin, ou couplé à un système de stockage en ligne de fichiers.
[^] # Re: Travail collaboratif
Posté par Anonyme . Évalué à 4.
Il existe etherpad. C'est pas aussi complet qu'une suite bureautique mais pour du texte c'est déjà bien. Si tu veux une démo, il y a le quadpad de la Quadrature du Net.
[^] # Re: Travail collaboratif
Posté par Maxime (site web personnel) . Évalué à 4.
Page d'accueil du site : "Google has acquired AppJet Inc. and its EtherPad collaboration product and technology."
[^] # Re: Travail collaboratif
Posté par claudex . Évalué à 9.
Et? Quand Google rachète une société, ça rend le code non-libre?
« 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: Travail collaboratif
Posté par Maxime (site web personnel) . Évalué à 9.
Non, je trouve ça plutôt drôle c'est tout. Je demande une alternative à Google Docs et on me propose un projet fait par une entreprise rachetée par Google.
Fallait pas chercher plus loin :).
[^] # Re: Travail collaboratif
Posté par Professeur Méphisto . Évalué à 4.
«_Fallait pas chercher plus loin :)._»
Si justement, cherchons plus loin... Google a-t-il racheté l'entreprise pour tuer un concurrent dans la grande tradition microsoftienne ou avec des intentions plus louables ?
[^] # Re: Travail collaboratif
Posté par ZeroHeure (site web personnel) . Évalué à 10.
Eh bien quand on gratte encore un peu plus loin, la perspective change:
1. c'est Google qui a libéré le code source d'Etherpad, après avoir racheté la boite (Appjet);
2. ils l'ont racheté après avoir lancé GoogleWaves, pour lequel Etherpad semblait un gros atout;
3. je crois que Google a laissé les développeurs créer l'Etherpad foundation, avec les utilisateurs;
4. Etherpad a été créé par des anciens de Google - des bons éléments à récupérer!
Bref, je ne fais pas d'angélisme avec Google, mais comme le rappelle Benjamin Bayart (FDN) dans ses conférences: pour l'instant, sans doute grace à ses fondateurs, Google joue le jeu. La question c'est jusqu'à quand? On peut penser que la "reprise en main" du conseil d'administration par l'un des deux fondateurs vise jouer le jeu encore plus longtemps.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Travail collaboratif
Posté par Papey . Évalué à 1.
Pirate Pad a repris le flambeau.
[^] # Re: Travail collaboratif
Posté par B16F4RV4RD1N . Évalué à 2.
on utilise openoffice à mon travail, et malheureusement pour certains documents partagés on a dû passer par google docs, c'est pratique mais qu'est-ce que c'est buggé et parfois pénible par ailleurs... entre l'interface qui repasse de temps en temps en anglais ou espagnol, le compte qui se délogge, la lenteur de l'interface, la latence de chargement...
En revanche c'est vraiment pratique d'avoir un historique des révisions (et voir qui l'a fait, même si en réalité on n'a fait qu'un compte google par service), de pouvoir travailler sur le même document au même moment (on peut même quasi faire de la discussion instantanée dans une case de tableur...)
En bref on voudrait la même chose, mais en local et avec openoffice sur des fichiers ods
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Travail collaboratif
Posté par Guillaume Denry (site web personnel) . Évalué à 3.
C'est toujours le même problème : comment faire quelque chose d'aussi pratique et grand public lorsqu'on ne dispose pas de structure centralisée...
Même si Google Docs devenait soudainement libre se poserait le problème de la disponibilité 24/24, de la pérennité des données, etc.
Bref, tout cela tourne toujours autour de la confidentialité.
[^] # Re: Travail collaboratif
Posté par devnewton 🍺 (site web personnel) . Évalué à 0.
J'utilise une solution pas grand public mais bien pratique quand même: j'écris mes documents en HTML.
C'est lisible partout, ça s'édite avec un simple éditeur de texte, ça s'imprime et se convertit en PDF facilement, c'est facile à versioner et à publier.
Je pourrais utiliser un outil plus adapté (latex, docbook, ...), mais ça me permet de rentabiliser mon apprentissage: ma connaissance du HTML est réutilisable pour créer des sites web ou des applications web.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Travail collaboratif
Posté par madhatter (site web personnel) . Évalué à 2.
Pourtant, il y a bien un mode "révision" sur OOo/LibO qui permet de faire ça sur les odt et ods (j'ai pas essayé pour les présentations), avec l'historique des modifs par auteur...
There is no spoon...
[^] # Re: Travail collaboratif
Posté par Maxime (site web personnel) . Évalué à 3.
Il fait quoi exactement ce mode révision ? Car s'il faut encore s'échanger les fichiers en faisant attention à toujours posséder la dernière version, ce n'est pas du tout ce que je recherche.
[^] # Re: Travail collaboratif
Posté par thamieu . Évalué à 4.
Unhosted voudrait bien concrétiser cela mais il semble manquer de programmeurs...
https://github.com/unhosted/unhosted/wiki/Google-Docs-Killer
Petite présentation très bien réalisée : http://vimeo.com/21387223
# 1Mo de gagné! Youpiiii!
Posté par Maclag . Évalué à -4.
Y'a que moi qui ait failli rire en voyant le gain en mémoire monumental: 1Mo (+800ko sous Linux). Wahouh!
C'est pas pour dénigrer le travail fait là-dessus, et je me doute qu'à l'échelle de l'élement/bout-de-code/appelez-ça-comme-vous-voulez, c'est significatif, mais écrire ça comme si c'était une révolution...
Il prennent combien en RAM LO et OOo sur vos machines?
Quand je veux perdre du poids, je commence pas par me couper les cheveux...
[^] # Re: 1Mo de gagné! Youpiiii!
Posté par barmic . Évalué à 10.
Il est rare de voir un résultat chiffré à ce genre d'optimisation. Il est très probable que pour alléger LibO il faille passer par pleins d'optimisations de ce genre plutôt que de perdre tout d'un coup.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: 1Mo de gagné! Youpiiii!
Posté par Maclag . Évalué à -3.
Encore une fois, je ne veux pas dénigrer le travail accompli sur cette portion de LibO.
Mais regardons les choses en face: on ne va pas faire 100 journaux pour parler de l'optimisation chiffrée de l'empreinte mémoire 1Mo à la fois!
Ne serait-il pas préférable de mentionner qu'un travail d'allégement a commencé?
Parce que la formulation laisse penser que c'est un énorme progrès global et franchement, ça me ferait peur...
[^] # Re: 1Mo de gagné! Youpiiii!
Posté par Maxime (site web personnel) . Évalué à 10.
On fait pas un journal par amélioration de 1 Mio. Il y a déjà un journal, on en profite pour le dire.
[^] # Re: 1Mo de gagné! Youpiiii!
Posté par barmic . Évalué à 7.
On va continuer à faire ce que l'on a toujours fait. Une dépêche par version (au minimum) avec le changelog de dans. Si le projet LibO pense que c'est important de le noter pourquoi le taire ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: 1Mo de gagné! Youpiiii!
Posté par Maclag . Évalué à 3.
Ah, je ne sais pas si je me fais mal comprendre, ou si c'est vraiment moi qui suis bizarre.
Quand on lit la dépêche, la première chose sur laquelle on tombe dans "Performances", c'est: on a gagné 1Mo de RAM sur un logiciel qui en bouffe facilement 100 ou 200 (au moins chez moi, ça dépend évidemment aussi de ce que j'ouvre! peut-être ai-je un problème particulier? il me semble que OOo est assez réputé pour sa bloatitude).
Quelle impression ça donne à quelqu'un qui n'y connaît pas grand chose?
Ce que moi je perçois:
La principale amélioration de perf de LibO, c'est d'avoir réduit son empreinte mémoire de 0.5 à 1%. Vivement les futures améliorations, sachant que quand on s'attaque à un sujet compliqué, en général, on avance très vite au début, et le ratio effort/effet augmente exponentiellement.
Pourquoi ne pas formuler ça de façon un peu plus humble et mettre en avant que ce n'est qu'un début et que ça concerne seulement un petit bout de LibO, et que on ne peut pas globalement parler d'allègement perceptible de la suite par l'utilisateur dans une utilisation quotidienne?
[^] # Re: 1Mo de gagné! Youpiiii!
Posté par barmic . Évalué à 4.
Pourquoi tu viens dire ça ici pas directement à ceux qui ont fait l'annonce ? (les développeurs de LibO)
La dépêche ne fait que répéter ce qui est dans le changelog.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: 1Mo de gagné! Youpiiii!
Posté par Maclag . Évalué à 2.
Ben... si on peut pas faire de commentaire, pourquoi publier le changelog sur Linuxfr?
Il est vrai que l'un n'empêche pas l'autre, et je devrais aller voir sur le site officiel si j'y suis.
Mais le fait est que je lis ça ici (et j'en suis bien content d'ailleurs) et que je ne suis même pas allé sur leur site officiel.
Au cas où ce ne serait pas clair: ce n'est pas une critique contre les auteurs de la dépêche que je formule. C'est une remarque sur le fait que ce "1Mo de gagné!" en première ligne pourrait porter à confusion et laisser croire que c'est un exploit extraordinaire (ou dit autrement: on n'ira pas beaucoup plus loin).
Que ce soit écrit de cette manière sur le site officiel ou changé pour la dépêche, est-ce que ça a tellement d'importance?
[^] # Re: 1Mo de gagné! Youpiiii!
Posté par windu.2b . Évalué à 10.
Exact : pour un geek, il est plus efficace qu'il se rase la barbe...
# java <=> c++/python/etc...
Posté par mig . Évalué à 7.
Je ne suis pas certain que les échanges de codes entre les 2 projets seront si important que ça.
Le socle technique de la fondation libreoffice semble être plus proche de la culture libre classique (c++, python, perl) alors que du coté apache on poussera clairement vers une utilisation totale de java. Malgré l'apparente réconciliation entre libreoffice et openoffice, je crois que nous aurons 2 logiciels forts différents à moyen terme.
[^] # Re: java <=> c++/python/etc...
Posté par Joris Dedieu (site web personnel) . Évalué à 3.
Je suis d'accord avec toi. Il est très probable qu'IBM pousse pour plus de java et que finalement les deux projets prennent des directions différentes.
Ceci dit vu la monstruosité du code, ce serait très étonnant qu'ils n'en profitent pas pour coller une bonne partie du code dans des libs indépendante sous une licence compatible avec les deux
projets.
Finalement le problème de Ooo est que le code n'est pas structuré pour permettre une évolution rapide. Je pense que ce travail là au moins, les deux projets le partageront.
[^] # Re: java <=> c++/python/etc...
Posté par barmic . Évalué à 6.
Apache ne fait pas nécessairement de Java, hein ? Regarde le serveur web du même non ou CouchDB.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: java <=> c++/python/etc...
Posté par djano . Évalué à 6.
Les développeurs d'OOo auront une influence bien plus grande sur les langages utilisés que la fondation Apache. La fondation n'a pas vocation a dicter le choix des langages utilisés dans les projets qu'elle héberge. SpamAssasin est écrit en Perl et Apache n'a pas demandé de le réécrire en Java. De même le serveur Apache HTTPD est toujours en C et personne de sensé ne veut le passer en Java.
Maintenant si une entreprise comme IBM fournit des développeurs Java pour OOo, alors peut être que Java va prendre un plus grande place. Tout dépendra des contributeurs et du groupe qui gère OOo.
# Alors ?
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 1.
LibreOffice permet-il enfin, après je ne sais combien d'années, d'exporter en PDF sans mettre les slides cachés ?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.