L'IDE XML, un logiciel libre qui manque

Pourquoi il faudrait avoir un IDE XML libre, ma tentative d'en créer un, un appel à contribution.

Le logiciel libre, c’est super. Pour des raisons éthiques, politiques, techniques, etc. Je ne vais pas jouer au RMS dans ce billet, je l’ai déjà fait sur ce blog au sujet d’une merveilleuse alternative à Minecraft1. Mais si l’on veut batailler contre le logiciel privateur2, il faut avoir une alternative d’abord. Contrairement à la politique où l’alternative peut être installée3 après la victoire, dans le domaine logiciel, l’alternative s’implémente avant.

Des logiciels libres bien voire excellents (bien qu’on puisse les railler, Gimp étant coutumier du fait, à tort ou à raison), il y en a plein. Apache, VLC, et compagnie. Mais il y en a peu au travail. Utiliser des logiciels libres à domicile ne me suffit pas. Force est de constater que ce qu’on fait au travail façonne ce qu’on fait chez soi. J’utilise Microsoft Office au travail et LibreOffice chez moi4. Si le travail s’invite chez moi, je finirais par enregistrer en DOCX par défaut, au travail comme chez moi. Si on veut que le logiciel libre libère autre chose que des développeurs5, et deux trois individus par çi par là, il faut gagner sur les deux plans6 (#Yakafokon).

Non-transition : au travail comme chez moi, j’ai besoin d’un IDE XML libre. Ça n’existe pas.

Aussi excellents et extensibles soient-ils, Emacs, Vim, Gedit, Kate et compagnie ne sont pas des IDE XML. On peut configurer Vim comme il faut, installer le mode majeur nxml sur Emacs7, mais Emacs ou Vim demeurent des éditeurs de texte, avec des extensions qui font ce qu’elles peuvent. Constat d’ailleurs exprimé ailleurs8:

la production des données structurées est un processus lent et lourd parce qu’on utilise des editors qui ont été conçus comme des editors [sic] XML tout court, successivement intégrés avec des extensions TEI. Mais, on n’a pas encore conçu des editors [sic] expressément adaptés aux exigences de la transcription/édition textuelle.

Sans parler du fait que manipuler du code, fut-il en HTML ou en XML, pour l’immense majorité des gens, c’est effrayant, agaçant et difficile. C’est tout l’intérêt des interfaces WYSIWYM : simplifier le travail sans sacrifier la structuration.

XML est à la fois un format d’échange de données et un espéranto pour composer des documents structurés9. Quand on veut échanger des données, générer du XML par un programme, éditer manuellement peut suffire. Mais quand on emploie XML pour créer des documents, à un moment donné, sans pour autant perdre totalement le code de vue10, on a besoin d’une interface WYSIWYM, d’outils XPath, de validation de schéma au fil de l’eau, de profils de transformation XSLT.

De tels IDE, je n’en trouve pas dans le logiciel libre. C’est difficile, mais faisable pourtant : Oxygen (privateur) ou XMLmind (privateur) ont ce genre de fonctionnalité. LyX (libre) a conçu une interface pour LaTeX. XML Copy Editor a une partie de ces fonctionnalités, mais reste très limité.

On aurait pourtant à y gagner. Avec un tel outil, on pourrait contribuer à limiter l’usage des traitements de texte (et donc les divers problèmes qu’ils posent); cela pourrait être une pièce nécessaire à une chaîne éditoriale multisupport libre11; cela pourrait remplacer des IDE utilisés dans l’édition technique / industrielle.

Si t’es pas content, contribue12.

C’est ce que j’essaie de faire avec <marginaliaEditor/>. Le moins qu’on puisse dire, c’est que c’est pas facile. J’essaie de faire un IDE qui aurait au moins une vue du code semblable à ce que peut proposer XMLmind.

C’est basiquement un logiciel de bureau, donc j’emploie un couple classique Python et PyQt13. Avoir un éditeur de code est assez simple avec QScintilla, mais pour la vue du Code voire pour le WYSIWYM, il faut créer des widgets personnalisés — peut-être même partir d’un bas niveau de classe de widget.

Le tout est pas trop laid, pas entièrement fonctionnel, et même un peu bricolé14, mais je pense que sur le long terme, ça pourrait aller. J’en suis pas à dire « au lieu d’utiliser Oxygen, utilise <marginaliaEditor/> » comme on pourrait conseiller Thunderbird au lieu d’Outlook. Pour le moment, je vise XML Copy Editor, c’est déjà beaucoup à mon niveau.

Ce qui n’est pas sans rappeler une histoire :

Un jour un incendie se déclare dans la forêt. Alors, tous les animaux s’enfuient devant le danger de mourir brûlés. Tous ? Non !
Un petit colibri va au lac voisin, prend une goutte d’eau dans son bec, revient et la jette dans la fournaise. Et ainsi, il fait des allers et des retours, en jetant une minuscule goutte d’eau dans le feu.
Un tatou, qui partait aussi mais qui était derrière tous les autres animaux car il n’était pas rapide dans la course, s’arrête un instant, regarde l’étrange manège du colibri et lui dit : « petit colibri, que tu es bête. Crois-tu que tu vas éteindre l’incendie toi, tout seul ? ».
Et le colibri de répondre : « sûrement pas gros bêta, mais je fais ma part ».

On pourrait dire que j’essaie de faire ma part, mais je n’aime pas l’histoire du colibri qui apporte de l’eau contre l’incendie. C’est une fable individualiste et désengageante. Les animaux qui se moquent du colibri ont raison, en un sens : il ne suffit pas de faire sa part. Il faut faire de plus grandes parts à plusieurs15.

Donc oui, ce billet est basiquement un appel à contribution. Même si vous n’êtes pas programmeur. Même si j’aime programmer, je ne suis pas programmeur non plus. Des remarques sur l’ergonomie, sur ce que vous voudriez voir dans <marginaliaEditor/>, tout ça, des remarques jusqu’au code, tout est bon à prendre.


Notes

  1. À l’époque, Mojang et donc Minecraft n’avait pas été racheté par Microsoft. Notch déclarait que la GNU GPL était « draconnienne » et pensait élever un jour Minecraft dans le domaine public. Occasion ratée, mais avec la somme qu’il a touchée, et l’ambiance délétère d’alors, il est compréhensible qu’il ait ravalé ses principes.

  2. Bon, ok, je fais mon Stallman, certains disent « propriétaire ».

  3. Certains théoriciens pensent plutôt que l’alternative se construit avant, pendant et après, mais là je pense surtout à l’électoralisme.

  4. Encore qu’il y a également LibreOffice d’installé sur nos postes. Mais le format d’échange et de travail reste le DOCX, puis le PDF, quand c’est stabilisé.

  5. Écouter à ce sujet BAYART Benjamin, « Le logiciel libre, et après ? », Rencontres Mondiales du Logiciel Libre 2004. Soit dit en passant, Benjamin Bayart critique le fait de créer des « clones » de logiciels privateurs, ce qui est en partie ce que je fais. Il faut envisager les clones avant tout comme des passerelles. Après tout, on ne passe pas d’un coup de Windows à Arch Linux avec un tilling window manager, on va d’abord sur des interfaces plus semblables, mais toujours légèrement différentes. Est-ce que développer des clones nuit au développement de logiciels véritablement différents dans leur approche, et de ce fait peut-être plus attractifs, je ne sais pas trop…

  6. Ce genre de remarque n’a rien d’original, le logiciel libre a eu dès le départ l’ambition de redevenir la modalité par défaut d’usage de logiciels.

  7. Pas testé : utilisateur de Vim, je ne trouve pas Emacs utilisable. Et écrire une extension pour Emacs avec cette horreur de LISP, non merci.

  8. Quoi que dans l’article cité, les éditeurs de code sont visés sans distinction privateur / libre.

  9. Le premier qui parle de JSON a perdu. Et il devra encoder de façon rigoureuse un bestiaire du 13e siècle en JSON pour voir si XML est dépassé.

  10. Avoir accès au code XML est toujours utile.

  11. Bien sûr, une chaîne éditoriale multisupport n’a pas à utiliser forcément XML. Elle pourrait employer du Markdown, ou un autre format de balisage de document. Je suis partisan du XML parce qu’on pourrait assez aisément multiplier les types d’export à partir de XML. Avec Markdown, les métadonnées comme le titre, l’auteur, la date, etc, sont des extensions qui doivent être traitées différement (avec Pandoc Markdown, c’est généralement sous forme d’un préambule YAML); on n’a pas cette différence avec XML. Il faut certes choisir le schéma, mais une fois que c’est fait, obtenir une métadonnée ou un élément du document, c’est pareil.

  12. Je trouve ce genre de réponse passablement condescendante et sectaire. On répond basiquement à un utilisateur de bonne volonté « ta gueule, apprends à coder ». Je suis d’accord sur le fait que le logiciel libre a aussi pour but d’émanciper les utilisateurs. Mais émanciper les utilisateurs, ce n’est pas nécessairement les transformer en « power users ». Dire « débrouilles-toi » à un utilisateur n’est pas la meilleure pédagogie.

  13. La mode semble être de faire des applications de bureau avec des composants HTML / Javascript, avec Electron, par exemple. Mais faut-il vraiment coder par dessus un navigateur pour éditer un document ?

  14. Après, je ne suis pas nécessairement un bon programmeur. En même temps, c’est pas (exactement, entièrement) mon métier.

  15. Alias l’organisation du travail, de quelque nature soit-il.


2 commentaires.

Bidule - à 10:49:31

Youhou ! Je te soutiens à fond par la force de la pensée parapsychique et psychologique ! Paix et bouquins pour tou·te·s !

Marcellin - à 08:55:19

@Bidule : Oooh, Bidule, je vois ton commentaire maintenant :) Merci !