Bureautique Etherpad Lite

Posté par . Édité par Nÿco, Florent Zara, Benoît Sibaud et patrick_g. Modéré par Xavier Claude.
38
17
avr.
2012
Bureautique

Sonnez hautbois, résonnez musettes, Etherpad Lite existe !

Etherpad était un éditeur (de texte) en ligne permettant de travailler à plusieurs sur un document. Le code fut ouvert par Google quand ils en firent l'acquisition pour l'intégrer à Google Wave (il me semble, ou alors c'était dans Google Docs), dans la foulée une fondation fut créée pour continuer à le faire vivre, et des pads fleurirent un peu partout, malgré la gourmandise du logiciel (les mauvaises langues, dont je ne suis pas, attribueront cette lourdeur au fait que le logiciel ait été écrit en Scala, et donc dépende de Java). Mais il était hors de portée des serveurs dédiés virtuels (VPS) pas chers, et autres mini serveurs.

C'est là qu'entre en scène Etherpad Lite, nettement moins gourmand, il se base sur Node.js, a moins de dépendances ésotériques que son ancêtre, et d'après les développeurs, là où un Etherpad occupait 257 Mo de RAM juste après son démarrage, Etherpad Lite n'en occupe que 16 Mo. Il est disponible sous licence Apache 2.0.

NdM : merci à ♾ El Diablo Robótico ♲ pour son journal.

Fonctionnalités

En terme de fonctionnalités, c'est un éditeur de texte texte, éditer du code est possible, si l'on accepte de se passer de coloration syntaxique, complétion, et autres joyeusetés. Son gros avantage, est qu'il permet de travailler à plusieurs sur un document, en voyant en temps réel les modifications apportées par les autres personnes. Il est possible de l'interfacer avec une base MySQL, et il dispose d'une API qui permet de créer, supprimer, modifier des documents.

Quelques captures d'écran

Etherpad start
Et hop on lance l'application.

1st screen
Écran de création ou d’accès à un pad.

pfffff
À gauche la zone d'édition, à droite la zone de discussion, et en haut la barre de menu avec de gauche à droite, les fonctions d'édition de texte : mise en gras, italique, souligné, barré, listes, changement de l'indentation, défaire et refaire, suppression des couleurs identifiant les auteurs des modifications, à droite

title
les réglages d'affichage du document courant.

title
Les filtres d'import/export de document.

title
Le lien pour partager le document (un QR code, wtf?).

title
Et enfin (le dernier bouton permet d'afficher la liste des participants), l'accès a l'historique du document avec une barre de défilement qui permet de naviguer dans l'historique du document.

  • # Coloration

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

    Suffirait pas d'intégrer un des nombreux coliriseurs en javascript pour avoir la coloration syntaxique?

    (je dis ça mais je sais même pas comment ça marche…)

  • # Styles

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

    Et c'est toujours fait par des gens qui n'ont jamais fait de bureautique propre on dirait. Les styles logiques, ça doit être ringard, la mode est à l'édition manuelle fastidieuse j'imagine.

    • [^] # Re: Styles

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

      Veridique : l'autre jour, en reunion, on nous a presente un nouveau type de wiki, qui se veut plus pratique que les wikis classiques, parce que :

      • Pour créer une nouvelle page : plus besoin de faire un lien artificiel depuis une autre page. Maintenant, il y a un bouton Créer une nouvelle page, qui en fait ne fait rien d'autre que créer une page ayant pour titre Nouvelle page, tout en passant en mode édition pour la modifier.

      • Pour faire des styles (gras/italiques/souligné), plus besoin de **blah**, *blah* ou __blah__: On peut choisir le texte a la main, aller chercher l’icône Mettre en gras a la main, et appliquer nos styles a la main. Bien sur, ces styles ne correspondent pas a un markup particulier : il y a une couche de presentation par-dessus.

      Même si je suis en désaccord avec ces soi-disant avantages, force est de constater que les habitudes et la facilite d’appréhension sont plus persuasifs que la logique chez la plupart des personnes.

      • [^] # Re: Styles

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

        C'est sans rapport. Le fait d'éditer le balisage à la main ou de disposer d'une présentation graphique est indépendant de l'utilisation de styles physiques ou logiques.

        • [^] # Re: Styles

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

          D'un autre côté, ton opposition physique/logique n'est pas super claire. "Libertine 16, rose flashy, centré, gras, italique, souligné, petite étoile à droite, petite étoile à gauche qui clignotent", tu peux appeler ça "Titre de Niveau 3", "Gros titre rose trô chou" ça reste ce que j'appelle une macro. C'est complètement orienté rendu (je pense que c'est ce que tu appelles "physique"), et seule l'utilisation que tu en fais peut être logique (ou pas).

          « La racine carrée de la vérité, c'est l'amour. » A.D Sakharov

          • [^] # Re: Styles

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

            Et quand tu as plusieurs titres de niveau 3 ? Quand tu veux, a posteriori, changer l'aspect de tous tes titres de niveau 3 ? Quand tu veux générer un sommaire ?

            • [^] # Re: Styles

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

              Ah, et aussi, quand tu as les titres suivants : 1, 1.1, 1.2, 1.2.1, 1.2.2, 1.3, 2, 2.1, 2.2, 2.2.1, 2.2.2, 2.2.3, 3, 3.1, 3.2, 3.3 et que tu décides d'ajouter une nouvelle section entre la 1 et la 2 ? Tu renumérotes à la main ?

            • [^] # Re: Styles

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

              Et bien tu emploies la même macro pour tous les éléments identiques, ce qui te permet de ne changer que la définition de la macro. C'est ton usage qui fera la logique et rendra la chose pratique. "Gros titre rose trô chou", ça ne dégage aucune logique, mais employé de manière cohérente c'est aussi puissant que "Titre de Niveau 3". Il n'y a pas de style intrinsèquement "logique" ou "physique", les deux sont du rendu complètement indépendant de la structure du document et la logique est uniquement dans (la rigueur de) leur application. Écrire le contenu de la macro "Titre de niveau 3" au lieu d'un appel à celle-ci n'est pas moins logique (la cohérence du rendu sera la même), c'est juste beaucoup moins pratique.

              La vraie critique à adresser à Etherpad Lite serait donc la simple impossibilité de définir des macros, qui cantonne à une mise en page sommaire pour des "petits" documents (moins une macro est complexe, moins elle est avantageuse à mesure que le document est court). Rien à voir avec une quelconque logique.

              « La racine carrée de la vérité, c'est l'amour. » A.D Sakharov

              • [^] # Re: Styles

                Posté par . Évalué à  2 .

                C'est marrant, il me semble que la plupart des suites bureautiques utilisent des styles : LibreOffice, MS Office, LaTex?, calligra, etc.

                Peut-être que tu raisonne à l'envers de beaucoup de gens : On définit une fonction (titre, texte formaté, citation, etc.) puis on lui applique un style particulier. Tu sembles partir du style particulier pour ensuite définir une fonction à partir de celui-ci.

                La plupart des utilisateurs de suite bureautique fonctionnent il me semble suivant le premier principe, qui est beaucoup plus productif…

                • [^] # Re: Styles

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

                  LaTeX utilise des fonctions, ou macros nommées. Tout l'intérêt est dans le nommage : on n'applique pas des instructions de mise en forme physique mais on appelle des fonctions logiques dont l'implémentation peut être redéfinie au besoin.

                • [^] # Re: Styles

                  Posté par (page perso) . Évalué à  2 . Dernière modification : le 18/04/12 à 15:49

                  LaTeX, que je connais le mieux, emploie des macros que tu fais en général à partir d'autres commandes et/ou environnement. Évidemment qu'on commence d'abord par définir la fonction avant d'appliquer le rendu, mais :

                  1. on pense toujours les deux en même temps par rapport à l'ensemble du document. Tu dis d'abord "tiens, ce serait cool si la liste des invités était un peu chiadée", tu bricoles un truc avec les commandes de base, et ensuite seulement tu encapsules la mise en forme dans un truc propre "\begin{guestlist}…\end{guestlist}". Ça n'a pas de sens de faire comme en programmation des fonctions dans le vide avec juste en tête la valeur qu'elles doivent retourner, car ce que tu veux c'est un rendu.
                  2. tout reste orienté rendu (avec LaTeX, tu peux même avoir des arguments à tes commandes pour modifier facilement tel ou tel aspect). C'est le seul critère unique, il n'y a pas d'autre "logique" et donc pas de distinction physique/logique qui tienne.

                  Je ne suis pas en train de soutenir que structurer son document à la Rache est aussi performant que de le faire avec un minimum de bon sens en employant les fonctionnalités de son logiciel. Je dis juste qu'en définitive la seule logique est la cohérence du rendu, et que tout le reste c'est du piston à coulisse.

                  « La racine carrée de la vérité, c'est l'amour. » A.D Sakharov

                  • [^] # Re: Styles

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

                    C'est le seul critère unique, il n'y a pas d'autre "logique" et donc pas de distinction physique/logique qui tienne.

                    Nawak. S'il n'y avait pas de distinction qui tienne, tu n'utiliserais pas de fonctions que tu définis, mais tu utiliserais les commandes de base à chaque fois, en les recopiant à chaque endroit où tu en as besoin. Et en les modifiant à chaque endroit où tu les as utilisées si tu décides qu'en bleu c'est mieux qu'en vert, tout compte fait.

                    • [^] # Re: Styles

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

                      Tes commandes de base ne sont ni plus ni moins "physiques" que les macros. Si dans un environnement français, je veux avoir une liste à l'anglo-saxonne avec des items à bulles au lieu de tirets, je vais me créer la macro "listbullet", dis-moi un peu en quoi ce sera moins "physique" que "itemize" ? À l'inverse, l'italique en français ("\textit" "physique" de base) c'est déjà au moins trois sens différents : souligné dans le manuscrit, mot étranger, insistance tonique.

                      Les macros, c'est très pratique mais ça ne crée pas de sens et donc pas de logique au-delà du rendu qu'elles encapsulent. Je peux reprendre l'environnement "guestlist" de mon paquet "wedding" et modifier la valeur de la commande \backgroundcolor à noir pour me faire une jolie liste de toutes les exécutions 2012 avec mon nouvel environnement "capitalpunishmentlist". Ce sera une parfaite exploitation des capacités de LaTeX, mais ça n'aura aucune espèce de logique à part celle du rendu.

                      Pour avoir du vrai orienté "logique", il faut aller chercher des trucs comme docbook, qui ne produisent rien par eux-mêmes qu'une description systématique et sémantique du document…

                      « La racine carrée de la vérité, c'est l'amour. » A.D Sakharov

                      • [^] # Re: Styles

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

                        Tes commandes de base ne sont ni plus ni moins "physiques" que les macros.

                        Si, parce que les macros, elles sont nommées et définies une fois, et utilisées plusieurs fois sans recopie de code. À toi de leur donner un nom logique, évidemment.

                        Si dans un environnement français, je veux avoir une liste à l'anglo-saxonne avec des items à bulles au lieu de tirets, je vais me créer la macro "listbullet", dis-moi un peu en quoi ce sera moins "physique" que "itemize" ?

                        Dans un environnement français, tu utilises l'environnement logique itemize, et tu le redéfinis pour qu'il utilise des tirets semi-cadratins comme puce. Excellent exemple d'ailleurs.

                        À l'inverse, l'italique en français ("\textit" "physique" de base) c'est déjà au moins trois sens différents : souligné dans le manuscrit, mot étranger, insistance tonique.

                        « Souligné dans le manuscrit », ce n'est pas une utilisation logique, donc je passe sur cet usage, libre à toi d'analyser cet exemple pour déterminer à quels usages logiques cela correspond. Mot étranger : c'est l'occasion de définir une macro \etranger. Insistance : il y a \emph pour ça.

                        • [^] # Re: Styles

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

                          Si, parce que les macros, elles sont nommées et définies une fois, et utilisées plusieurs fois sans recopie de code. À toi de leur donner un nom logique, évidemment.

                          Je viens de te montrer qu'il n'y avait aucune logique entre les noms. Tu peux construire n'importe quoi à partir de n'importe quoi, sans problème majeur à l'usage. Ce que "signifie" ta macro, c'est son rendu, point barre. Si je crée une classe de document "reptel" pour "répertoire téléphonique" à partir de la classe "article", ça ne voudra pas dire que mes répertoires téléphoniques seront des sortes d'articles. J'utilise simplement les rendus d'une classe pour bâtir ceux d'une autre, le lien s'arrête là.

                          Dans un environnement français, tu utilises l'environnement logique itemize, et tu le redéfinis pour qu'il utilise des tirets semi-cadratins comme puce.

                          Tu détournes l'exemple (en babel french, les listes sont à tirets par défaut), c'est l'inverse que je veux : je peux vouloir mettre certaines listes en valeur avec des bulles, et donc me créer un environnement à cet effet. Il ne sera ni plus ni moins "physique" que itemize. Les fioritures, ça existe, la mise en page n'est pas purement fonctionnelle (et heureusement).

                          « Souligné dans le manuscrit », ce n'est pas une utilisation logique, donc je passe sur cet usage, libre à toi d'analyser cet exemple pour déterminer à quels usages logiques cela correspond. Mot étranger : c'est l'occasion de définir une macro \etranger. Insistance : il y a \emph pour ça.

                          Pour « souligné dans le manuscrit », c'est tout simplement « souligné dans le manuscrit », tu rends comme l'auteur l'a donné, même si tu ne comprends pas pourquoi. Pour \etranger, super, une macro inutile (quand je parlais de piston à coulisse… ) qui voudra juste dire \textit… ou \emph, parce que la différence entre \emph et \textit en LaTeX, c'est pas le sens, c'est juste que \emph se traduit en romain lorsqu'il est déjà dans un texte en italique. De plus, il y a emphase tonique (ex. "tu m'as demandé de le faire") et emphase sémantique (ex. les termes communs employés en tant que concepts philosophiques), il faudrait donc de toute urgence créer un \emphconcept et un \emphtonique pour utiliser la commande de base \emph…

                          « La racine carrée de la vérité, c'est l'amour. » A.D Sakharov

                          • [^] # Re: Styles

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

                            Je viens de te montrer qu'il n'y avait aucune logique entre les noms.

                            C'est toi qui choisis de nommer tes macros de façon logique ou non.

                            Ce que "signifie" ta macro, c'est son rendu, point barre.

                            Exact, mais ta macro existe et a un nom. Rien que cela, c'est utile, ça ajoute une indirection logique qui apporte de la souplesse.

                            Tu détournes l'exemple (en babel french, les listes sont à tirets par défaut), c'est l'inverse que je veux : je peux vouloir mettre certaines listes en valeur avec des bulles, et donc me créer un environnement à cet effet.

                            Effectivement, ça c'est de la mise en forme physique, et ça vaudrait le coup de t'interroger sur la raison pour laquelle tu veux faire cela.

                            Pour « souligné dans le manuscrit », c'est tout simplement « souligné dans le manuscrit », tu rends comme l'auteur l'a donné, même si tu ne comprends pas pourquoi.

                            Très bien, dans ce cas, il est pertinent de nommer cette macro \soulignemanuscrit ou un truc du genre. Des fois que l'éditeur décide que finalement, ce que l'auteur a souligné, il faudrait vraiment le souligner pour respecter le choix de l'auteur, plutôt que de le mettre en italique.

                            Pour \etranger, super, une macro inutile (quand je parlais de piston à coulisse… ) qui voudra juste dire \textit…

                            Que non ! Le jour où ton éditeur décidera que les mots étrangers devraient être en oblique plutôt qu'en italique, tu seras content d'avoir défini une macro dédiée !

                            De plus, il y a emphase tonique (ex. "tu m'as demandé de le faire") et emphase sémantique (ex. les termes communs employés en tant que concepts philosophiques), il faudrait donc de toute urgence créer un \emphconcept et un \emphtonique pour utiliser la commande de base \emph…

                            Si tu fais la différence et qu'elle a vraiment une importance dans ton contexte, il pourrait être pertinent de le faire en effet, mais je doute que ce soit vraiment utile.

                            • [^] # Re: Styles

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

                              Pour l'italique, c'est pas l'éditeur qui décide, c'est le français imprimé qui est comme ça. Le lecteur un peu habitué à cette langue saura parfaitement faire la différence entre les sens selon le contexte, autrement il y a longtemps qu'on aurait changé les conventions.

                              Effectivement, ça c'est de la mise en forme physique, et ça vaudrait le coup de t'interroger sur la raison pour laquelle tu veux faire cela.

                              Parce que j'en ai tout simplement besoin et que c'est un nom qui correspond bien pour la décrire. Dis-moi, à chaque énumération, tu renommes vraiment "enumerate" en "enumerate" juste pour être "logique"? non, tu te contentes du rendu…

                              Pour les numérotations, ça exploite juste un mécanisme de base qu'on appelle un compteur, créable et manipulable directement, je te laisse voir comment c'est implémenté dans article.cls, De même pour la génération du sommaire (ça te permettra de voir que ce que tu appelles "commande de base", c'est déjà de la sacrée macro)…

                              « La racine carrée de la vérité, c'est l'amour. » A.D Sakharov

                          • [^] # Re: Styles

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

                            Au fait, tu numérotes vraiment tous tes titres à la main ? Tu construis vraiment tous tes sommaires à la main ?

                            • [^] # Re: Styles

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

                              C'est un peu un dialogue de sourd qui s'enracine dans l'usage du mot logique.

                              Lorsque vous parlez de "logique" vous parlez "d'abstractions" : LaTeX m'offre des macros me permettant de ne pas me préoccuper de la numérotation des lignes. Je n'écris pas les numéros en "dur".

                              Lorsque MrSpackMan parle de logique il pose la question : y-a-t-il une logique intrinsèque et nécessaire aux macros LaTeX ? Et il répond non : je peux appeler ma macro de création de listes "touchePasAMaPomme", utiliser l'environnement asparaenum pour numéroter des poèmes, qu'importe si ça n'est pas logique, j'ai le rendu attendu et c'est tout ce qui compte.

                              D'où la comparaison avec Docbook de SpackMan.

                              D'où cette question que vous lui posez qui montre que vous ne parlez pas de la même chose.

                              • [^] # Re: Styles

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

                                Lorsque MrSpackMan parle de logique il pose la question : y-a-t-il une logique intrinsèque et nécessaire aux macros LaTeX ? […]

                                Oui, c'est ça. Mais pas seulement pour LaTeX, pour n'importe quel langage orienté rendu. À noter qu'on prend quand même des noms pratiques (et pas logiques) pour le document courant, que ce soit "itembullet" ("de quoi ça a l'air ?") ou "guestlist" ("qu'est-ce que c'est ?"). Les macros c'est un univers où tu peux dire : tomate = clémentine rouge, ou sapin = camion vertical marron et vert à benne triangulaire. Il n'y a aucune logique, juste de la commodité de nommage par rapport à ce qu'on veut rendre.

                                « La racine carrée de la vérité, c'est l'amour. » A.D Sakharov

        • [^] # Re: Styles

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

          Je réagissais sur

          la mode est à l'édition manuelle fastidieuse j'imagine

          ou finalement, mettre un style en emphase via selection/cliquage, c'est pas forcement plus pratique ou rapide qu'en mettant des * autour. Par contre, c'est plus intuitif.

          Et plus généralement, cette possibilité de choisir son style via un clic sur un bouton entraine les gens a choisir le "niveau" d'un titre via ledit clic. Et ça, c'est l'erreur.

          • [^] # Re: Styles

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

            Tu réponds à côté : le fait de disposer d'un rendu visuel ou non, et de disposer de styles logiques plutôt que physiques, sont deux choses indépendantes. Il pourrait y avoir un bouton « mettre en emphase » et un autre « titre 1 », que ce serait tout à fait acceptable.

      • [^] # Re: Styles

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

        Ce serait pas FosWiki par hasard?
        Je me coltine cette giga merde tous les jours au boulot…

      • [^] # Re: Styles

        Posté par . Évalué à  2 .

        Confluence?

  • # Intéressant pour les CR de réunion en live, mais pourquoi pas de titres ?

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

    J'ai très envie d'essayer ça pour la prise de notes collectives en réunion. Mais pourquoi avoir choisi de commencer par implémenter gras, italique, souligné et même barré avant même d'avoir la moindre fonction d'outliner ou au moins des niveaux de titres ? Peut-être que je ne suis pas dans la cible visée…

    • [^] # Re: Intéressant pour les CR de réunion en live, mais pourquoi pas de titres ?

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

      Non, visiblement ces outils ne permettent que de faire de l'édition de texte vite fait mal fait.

    • [^] # Re: Intéressant pour les CR de réunion en live, mais pourquoi pas de titres ?

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

      Ce Use Case serait mieux rempli avec quelque chose comme Google Docs a mon avis. Tel que je vois Etherpad (lite), c'est plutôt une solution de collaboration sur un texte brut avec quelques frivolités comme le gras/italique/souligné. Ça permet de partager une source Latex, par exemple.

      Pour se faire un outliner, on peut utiliser un langage de balisage comme Markup. Et la c'est typiquement une utilisation potentielle très pratique qui manque a l'interface : la possibilité d’écrire son texte en Markup par exemple, et de prévisualiser la page HTML associée. Oui, l'export HTML existe, mais la source pour l'export n'est pas le contenu brut du texte mais également sa présentation, ce qui casse tout l’intérêt d'un langage de balisage.

      Mais tout ça, c'est juste quelques lib javascript, donc ça devrait être modifiable sans trop de difficultés =]

  • # Helas, c'est du node.js

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

    Et node.js, c'est un peu pas cool vu qu'il y a un fork en bundle de divers choses, comme la libv8 de chrome, openssl

    https://github.com/joyent/node/tree/079b81358bf464b621146a90eeee9cd5d6631c56/deps

    Du coup, ça fait râler certaines distributeurs :

    https://bugzilla.redhat.com/show_bug.cgi?id=732552

    Alors bien sur, je comprends bien que le fork d'openssl dans le code est la pour le support des plateformes plus primitives, comme mac os x ou windows, qui n'ont pas de paquets. Je comprends que pour un truc aussi innovant qu'une boucle d’événement ( pour libeio ), il est trop dur de garder une API stable.

    Mais je persiste à dire que c'est pas très bon sur le long terme.

  • # Latex ?

    Posté par . Évalué à  1 .

    Bonjour à tous,

    ce projet a l'air intéressant. J'en profite pour demander à mes camarades libristes s'ils connaissent une solution de travail collaboratif web permettant d'éditer du \LaTeX.

    Merci d'avance.

Suivre le flux des commentaires

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