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
Et hop on lance l'application.
Écran de création ou d’accès à un pad.
À 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
les réglages d'affichage du document courant.
Les filtres d'import/export de document.
Le lien pour partager le document (un QR code, wtf?).
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.
Aller plus loin
- Etherpad Lite (1464 clics)
- API d'Etherpad Lite (164 clics)
- Node.js (79 clics)
- Etherpad (Fondation) (174 clics)
- Journal à l'origine de la dépêche (86 clics)
# Coloration
Posté par Gui13 (site web personnel) . É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 🚲 Tanguy Ortolo (site web personnel) . É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 rakoo (site web personnel) . É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 🚲 Tanguy Ortolo (site web personnel) . É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 Ignatz Ledebur . É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).
[^] # Re: Styles
Posté par 🚲 Tanguy Ortolo (site web personnel) . É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 🚲 Tanguy Ortolo (site web personnel) . É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 Ignatz Ledebur . É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.
[^] # Re: Styles
Posté par Adrien . É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 🚲 Tanguy Ortolo (site web personnel) . É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 Ignatz Ledebur . Évalué à 2. Dernière modification le 18 avril 2012 à 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 :
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.
[^] # Re: Styles
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
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 Ignatz Ledebur . É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…
[^] # Re: Styles
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
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.
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.
« 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 Ignatz Ledebur . Évalué à -1.
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à.
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).
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…
[^] # Re: Styles
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
C'est toi qui choisis de nommer tes macros de façon logique ou non.
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.
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.
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.
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 !
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 Ignatz Ledebur . É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.
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)…
[^] # Re: Styles
Posté par 🚲 Tanguy Ortolo (site web personnel) . É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 jbbourgoin (site web personnel) . É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 Ignatz Ledebur . Évalué à 0.
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.
[^] # Re: Styles
Posté par rakoo (site web personnel) . Évalué à 1.
Je réagissais sur
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 🚲 Tanguy Ortolo (site web personnel) . É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 Gui13 (site web personnel) . Évalué à 3.
Ce serait pas FosWiki par hasard?
Je me coltine cette giga merde tous les jours au boulot…
[^] # Re: Styles
Posté par djano . Évalué à 2.
Confluence?
# Intéressant pour les CR de réunion en live, mais pourquoi pas de titres ?
Posté par Jean-Marc Liotier (site web personnel) . É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 🚲 Tanguy Ortolo (site web personnel) . É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 B16F4RV4RD1N . Évalué à 2.
cf mon commentaire ici : https://linuxfr.org/users/booga/journaux/etherpad-lite#comment-1341789
Les titres niveaux 1 et 2 sont pris en compte dans l'export, donc j'imagine que ce code a une raison d'être : fonctionnalité future, ou cachée ? À moins que cela ait été codé vite fait mal fait…
J'adorerais avoir plusieurs niveaux de titre dans etherpad.
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: Intéressant pour les CR de réunion en live, mais pourquoi pas de titres ?
Posté par rakoo (site web personnel) . É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 =]
[^] # Re: Intéressant pour les CR de réunion en live, mais pourquoi pas de titres ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Qui, jusqu'il y a peu de temps, ne disposait pas non plus de styles logiques, que de styles physiques. À l'époque, Google Docs était à peu près au niveau d'Etherpad actuellement, je dirais.
# Helas, c'est du node.js
Posté par Misc (site web personnel) . É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 loloemr . É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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.