↩ Accueil

Vue lecture

NOALYSS : campagne de financement

spark développe NOALYSS, serveur de comptabilité et ERP totalement libre (GNU GPL2) depuis plus de 20 ans. Cette dépêche est une conversion de son journal. Noalyss a fait partie des solutions comptables présentées dans un article-bilan récent concernant la comptabilité d'entreprise.

Afin de rester à jour, il faut développer la facturation électronique, obligatoire en Belgique à partir de 2026 qui doit suivre le format UBL3.0 et pour développer cela, il faut du financement. Et malheureusement le modèle économique du libre, ne génère pas énormément d’argent pour la majorité des projets. Une campagne de financement est donc lancée pour NOALYSS.

Si NOALYSS récolte suffisamment de fonds, il sera possible de tout conserver en libre, sans avoir à réaliser un module payant. Cela concerne le module facturation (génération de factures) mais aussi Document (vidéo d'une saisie rapide de factures) afin de pré-compléter l’opération d’achat.

Nous comptons aussi améliorer NOALYSS dans le mouvement, par exemple pour avoir la double authentification (avec courriel, OTP), l’export en fichier Calc.

En échange d’un versement, une facture pour « Développement e-invoice » sera envoyée afin que les contributeurs puissent le déduire fiscalement ; seuls les auto-entrepreneurs, indépendants, PME, etc. pourront le déduire de leurs impôts comme frais professionnels : ils paient un développement de logiciel, qui sera déclaré et taxé comme revenus chez nous. Une page présente la procédure.

Voilà donc à vos bons cœurs de libristes :-)

Commentaires : voir le flux Atom ouvrir dans le navigateur

  •  

Campagne de dons : Yunohost a besoin de vous !

Cher·es ami·es, cher·es camarades, nos amours, nous lançons aujourd’hui une campagne d’appel à dons.

Car vous en avez probablement conscience : si notre activité est essentiellement bénévole et que YunoHost est offert à qui veut l’employer, notre activité a un coût. Or sur cette trajectoire et à ce rythme, nous ne pourrons couvrir que la moitié de nos dépenses projetées pour boucler notre budget.

page d'accueil Yunohost

Notre situation financière n’est pas alarmante à ce stade : la générosité de notre communauté nous permet d’ores et déjà de financer notre infrastructure. Mais nous aimerions être en capacité de faire mieux : prendre soin du collectif, maintenir et développer des fonctionnalités, nous rencontrer et faire connaître YunoHost.

Dans le cadre de cette campagne de dons, nous avons réalisé deux pages pour expliquer comment nous utilisons l'argent et ce que nous souhaiterions réaliser cette année :

N’hésitez pas à relayer ces messages, voire à rédiger les vôtres et nous les partager : votre aide est la bienvenue ! Qu’il s’agisse de témoigner de votre usage, de parler de votre implication voire de faire un don, tous les coups de main sont très appréciés !

Grand merci pour vos contributions et votre enthousiasme !

Commentaires : voir le flux Atom ouvrir dans le navigateur

  •  

QuickJS version 2025-04-26 et QuickJS-NG version 0.10

Finalement Fabrice Bellard est comme tout le monde, lui aussi numérote ses versions avec des dates, c'est plus simple. Voici donc la version annuelle de QuickJS (licence MIT), son moteur JavaScript incorporable et compact (le binaire Linux 64 bits fait 757 kiB). QuickJS est compatible avec ECMAScript 2023 — sauf pour les appels tails que les auteurs ne trouvent pas indispensables — et passe presque toute la suite de tests ECMAScript (en sélectionnant ES2023).

En 2023, pour revivifier un développement un peu dormant, la fourche QuickJS-NG a été lancée (par un des contributeurs de Jitsi). QuickJS-NG est intéressant pour ceux qui veulent utiliser cmake et compiler le projet sous Windows avec le compilateur C Microsoft. Il intègre aussi le support de quelques fonctionnalités récentes de la norme JavaScript que QuickJS ne supporte pas encore. (Je cite Fabrice Bellard). Les différences ne sont pas énormes. La version 0.10 est toute neuve.

Ci-après, Fabrice Bellard m'a très gentiment expliqué les principaux changements de QuickJS.

Changements les plus importants dans QuickJS 2025-04-26

Les explications viennent de Fabrice Bellard :

  • La suppression d'extensions non standardisées que j'avais ajoutées pour avoir des nombres flottants en précision arbitraire et la surcharge des opérateurs. Précision historique : j'ai créé QuickJS au début afin d'avoir une calculatrice avec une syntaxe compatible JavaScript. L'idée était de pouvoir manipuler des entiers ou des nombres flottants en précision arbitraire, des polynômes ou des matrices tout en utilisant une syntaxe familière. D'où des extensions au langage JavaScript présentes dans QuickJS. Mais ces extensions étaient compliquées et source de bugs, donc j'ai décidé de les supprimer. La calculatrice est maintenant un projet à part1.
  • L'implémentation des BigInt se reposait sur la librairie libbf que j'ai supprimée avec les extensions non standardisées. Il y a donc une nouvelle implémentation des BigInt, plus rapide et plus simple.
  • La réimplémentation des "weak references" avec le support de fonctions présentes dans ES2023. QuickJS-NG les supportait déjà mais avec une implémentation qui utilise plus de mémoire, est moins efficace et surtout potentiellement incorrecte en présence de cycles.
  • La concaténation de petites chaînes de caractères est plus rapide grâce à l'utilisation de "ropes". Beaucoup de programmes fabriquent de longues chaînes de caractères en concaténant des petites chaînes de caractères avec une grosse s = ""; for(i=0;i<n;i++) s += "a". C'est une méthode déconseillée car inefficace, mais les moteurs JavaScript comme V8, SpiderMonkey ou JavaScriptCore l'optimisent donc elle est très utilisée.
  • Ajout des numéros de colonne dans les erreurs. QuickJS-NG le faisait déjà mais la méthode ne me convenait pas. Celle utilisée dans QuickJS est plus simple et (normalement) plus précise.
  • Les nombres flottants sont maintenant analysés et convertis en chaînes de caractères sans utiliser la librairie C. Cela est nécessaire pour être complètement compatible avec la norme JavaScript et accroître la portabilité du code.

Principaux changements de QuickJS-NG 0.10

  • Implémentation de Array.fromAsync
  • supporte os.Worker sur Windows
  • ajout du mode de build parserless
  • ajout de os.exePath()
  • ajouts des hooks Promise
  • correction des Promise non gérés
  • nouvelle implémentation de BigInt par Fabrice Bellard (voir ci-dessus)
  • et divers…

Sous-projets

QuickJS héberge des bibliothèque C qu'on peut utiliser pour d'autres projets :

  • libregexp : une bibliothèque Regexp petite et rapide, totalement conforme aux spécifications Javascript ES2023.
  • libunicode : une petite bibliothèque Unicode supportant les conversions de casse, la normalisation unicode, les requêtes unicode scriptées, les requêtes unicode de catégorie générale et toutes les propriétés unicode binaires.
  • dtoa : une petite bibliothèque pour l'impression et l'analyse syntaxique en float64.

Téléchargements

Les binaires sont dispos avec jsvu (JavaScript Version Updater, de Google) ou esvu (ECMAScript Version Updater, projet communautaire), ainsi qu'en téléchargement depuis les sites respectifs. Fabrice Bellard a aussi préparé des binaires QuickJS construits avec la Libc Cosmopolitan pour Linux, Mac, Windows, FreeBSD, OpenBSD, NetBSD tant sur les architectures ARM64 que x86_64.


  1. NumCalc n'est pas encore indépendant de QuickJS, mais c'est le but. Pour l'instant la nouvelle calculatrice (bfcalc) n'est disponible qu'en ligne de commande. 

Commentaires : voir le flux Atom ouvrir dans le navigateur

  •  

LXQt 2.2.0

Le bureau LXQt est sorti le 17 avril 2025 en version 2.2.0. Comme prévu depuis la version 2.0, le développement est centré sur le confort : améliorations du support Wayland et ergonomie.
Pour mémoire, LXQt est un environnement de bureau fondé sur Qt, issu du rapprochement de deux projets, Razor-qt et LXDE, et publié sous licence GPL.

Le support de Wayland est encore meilleur, particulièrement en multi-écrans où on utilise des noms d’écrans plutôt que des nombres (appelez vos écrans mieux ça fera sourire Miou-Miou). En outre vous pourrez utiliser les dernières versions stables des compositeurs Wayland.

Niveau ergonomie, le gestionnaire de fichiers PCManFM-Qt accepte les terminaux personnalisés, le terminal QTerminal est encore plus lisible et tous les deux améliorent plein de petits trucs puisque c’est dans les détails que ça se cache. Dernier point notable, les utilisateurs de portables peuvent créer des profils d’énergie pour mieux gérer la batterie.

Pendant ce temps-là LXDE est abandonné.

Commentaires : voir le flux Atom ouvrir dans le navigateur

  •  

Sortie de Lazarus 4.0, l'IDE pour Free Pascal

Le 5 mai, jour qui se prête aux manipulations numériques, l'environnement de développement Lazarus est sorti en version 4.0. Lazarus est écrit en Pascal et permet de développer en Pascal Objet, c'est à dire en Delphi. Il accompagne le compilateur libre Free Pascal.

Le langage Pascal est toujours très utilisé, l'index TIOBE de mai 2025 le classe en neuvième position (et ça progresse), loin devant PHP ou Rust. Et si on en parle peu malgré ses qualités c'est peut-être parce qu'il n'est pas porté par de grandes corporations.

Lazarus 4.0 est dispo sur Linux, *BSD, Macos, Windows, il y a même des paquets debian pour RapsberryPi. Il est compilé avec FreePascal 3.2.2. La LCL (Lazarus component library) fournit des widgets graphiques multi-plateformes pour

  • Linux/FreeBSD (GTK2, Qt4, Qt5 and Qt6)
  • Windows depuis Windows 2000 (y compris WinCE)
  • macOS (Cocoa, Carbon, GTK2, Qt4, Qt5, Qt6)

Commentaires : voir le flux Atom ouvrir dans le navigateur

  •  

QEMU 10.0

Comme tous les ans, Qemu sort une nouvelle version majeure. Le numéro n'implique donc pas de grands bouleversements. Il s'agit plutôt d'une base stable qui va être maintenue et améliorée pendant quelques années. Ainsi, les versions 7, 8 et 9 ont eu des mises à jour en mars 2025.

Comme d'habitude, les architectures ARM et Risc-V se taillent la part du lion et sont enrichies de nouvelles architectures. Les accès aux stockages sont partout plus rapides, et l'espace utilisateur accède toujours mieux au matériel.

Qemu est devenu une pièce importante dans le monde des serveurs et des développeurs. En tant qu'émulateur il permet de développer, compiler ou lancer un programme sur un processeur ou une machine différente. Couplé à KVM, XEN ou VMWare, il permet une virtualisation performante.

Quoi de neuf ?

L'article de Next résume bien les changements sur ARM et Risc-V. C'est technique, n'étant pas connaisseur je vous y renvoie.

x86 bénéficie de changements globaux à toutes les architectures avec quelques ajouts spécifiques pour des processeurs Intel. Mon petit doigt impatient de tester me souffle que ça sera plus rapide avec des accès "multithread1" aux périphériques de stockage (virtio-scsi et virtio-blk). L'accès direct au matériel en espace utlisateur continue de s'améliorer (VFIO, fonctions virtuelles d'entrées-sorties).

Les autres changements concernent l'émulation des architectures HPPA et S390.

Attention aux trucs enlevés

À chaque version ou presque, des morceaux sont enlevés. Si vous faites dans l'exotique, ne vous précipitez pas sur la dernière version sans consulter la liste des Removed features.

Documentation d'introduction pour QEMU et la virtualisation

En guise de conclusion, voici quelques pistes pour ceux et celles qui débutent avec la virtualisation sous Linux et/ou QEMU. Différentes distributions Linux ont de la documentation sous licence libre. Loin d'être exhaustif, voici quelques choix :


  1. Qu'on me pardonne ce mot, je simplifie pour faire court! 

Commentaires : voir le flux Atom ouvrir dans le navigateur

  •  

Kivy : un cadriciel graphique unique en Python

Kivy est un cadriciel (framework) graphique, permettant de développer des interfaces tactiles (ou utilisable à la souris) sur toutes les plateformes, y compris mobiles. Il s'accompagne d'une suite de logiciels très pratiques que nous allons présenter ici.

logo Kivy

Sommaire

Kivy : boîte à outils graphique multi-plateformes

Kivy permet de créer des interfaces graphiques naturellement adaptées aux écrans tactiles (mais qui restent utilisables sur un environnement de bureau traditionnel, à la souris et sans écran tactile). Il est écrit principalement en Python mais les parties critiques sont écrites en Cython, ce qui lui permet d’avoir de bonnes performances.

Une interface Kivy peut s’écrire de deux façons (ou, plus couramment, par une combinaison de ces deux façons) : en Python directement, ou via kv, une syntaxe déclarative dont nous parlons plus bas.

Pour vous donner une idée, voici un exemple de hello world repris du site officiel de Kivy :

from kivy.app import App
from kivy.uix.button import Button

class TestApp(App):
    def build(self):
        return Button(text='Hello World')

TestApp().run()

Ce qui donnera :
capture d’écran du hello world

Une interface est composée de « widgets » agencés via des « layouts ». Certains widgets permettent de facilement mettre en place des composants communs de nos jours, comme par exemple le widget Carousel :
capture d’un widget Carousel

D’autre part, Kivy fournit des outils qui simplifient la vie du développeur ou de la développeuse, en particulier un système de propriétés (à ne pas confondre avec les propriétés Python) qui permet de mettre automatiquement l’interface à jour quand elles sont modifiées, ou de facilement attacher une fonction de rappel (« callback »), voir plus bas pour un exemple simple. On peut aussi citer un mécanisme d’animations très pratique et efficace.

kv : interface graphique en déclaratif

kv est un langage permettant de décrire des interfaces, il met à profit les propriétés mentionnées plus haut et l’interface va se mettre à jour automatiquement quand des propriétés utilisées dans kv sont modifiées.

Reprenons le hello world vu plus haut, et faisons-le avec kv:

Widget:
    Button:
        text: "Hello World"

Plutôt simple non ?
Le code kv est généralement mis dans des fichiers séparés avec l’extension .kv.

Les propriétés

Kivy a donc un concept de propriété, qui permettent la liaison de données bidirectionnelles (two-way data binding), ou en d’autres termes de facilement avoir l’état mis à jour entre le code python et l’interface décrite dans le fichier kv. C’est à l’usage très pratique et facile.

Un exemple va sans doute aider à comprendre.

Commençons par faire un environnement virtuel Python avec Kivy:

$ mkdir demo

$ cd demo

$ python -m venv env

$ source env/bin/activate

$ pip install kivy

Ensuite créez le fichier demo.py suivant :

from kivy.app import App
from kivy.uix.boxlayout import BoxLayout
from kivy.properties import NumericProperty

class CompteurWidget(BoxLayout):
    compteur = NumericProperty(0)

    def increment(self):
        self.compteur += 1

class DemoApp(App):
    def build(self):
        return CompteurWidget()

DemoApp().run()

Et maintenant, dans le même répertoire, ajoutez le fichier demo.kv suivant, ce dernier sera automatiquement découvert par Kivy parce qu’il s’appelle comme notre application (DemoApp) sans le suffixe App et en minuscule :


<CompteurWidget>:
    orientation: 'vertical'
    padding: 20

    Label:
        text: str(root.compteur)
        font_size: 30

    Button:
        text: "Incrémenter"
        on_press: root.increment()

Il ne nous reste plus qu’à lancer le programme :

python demo.py

Et à admirer :

capture d’écran du programme de démo

Le label se met automatiquement à jour quand le compteur compteur est incrémenté.

La lectrice ou le lecteur assidu de DLFP pourra faire un TapTempo en exercice.

Note: Ne vous arrêtez pas au fait que l’UI est un peu "moche" par défaut, il y a des extensions beaucoup plus attractives (cf. KivyMD plus bas), et il est très facile de personnaliser l’interface et d’en faire une très belle en modifiant un peu ses fichiers .kv.

Plyer : accéder facilement aux fonctionnalités matérielles de votre appareil

Plyer est une bibliothèque permettant d’accéder à nombre de fonctions utiles de manière indépendante de la plateforme. Ainsi vous avez une API commune pour afficher une notification, demander l’état de la batterie, faire vibrer l’appareil, faire de la synthèse vocale de texte (« text-to-speech »), ouvrir un fichier avec le dialogue natif de la plateforme, etc.

Bien que développé par la même équipe que Kivy, ce paquet est utilisable indépendamment et est donc particulièrement utile pour n’importe quel projet multi-plateformes. Référez-vous à la page du projet pour avoir un tableau des fonctionnalités supportées selon les plateformes, et à la documentation pour plus de détails.

Python For Android : utiliser Python… sur Android

Si vous souhaitez distribuer votre application sur Android, vous allez devoir avoir une version de Python compilée pour cette plateforme, ainsi que de tous les paquets nécessitant une compilation.

C’est le rôle de Python pour Android, qui est une collection d’outils qui s’appuient sur l’Android SDK pour permettre d’utiliser Kivy ou d’autre paquets Python sur Android, et ainsi faire votre propre distribution Python.

Si vous utilisez un paquet qui n’est pas en pur Python (c’est-à-dire qu’il y a des parties à compiler) et qui n’est pas encore disponible ou qui l’est mais dans une version trop ancienne, vous pouvez écrire ou mettre à jour des « recettes » (recipes en anglais) qui indiquent comment compiler. Référez-vous à la documentation pour voir comment faire.

Notez toutefois qu’il y a une pénalité à utiliser du Python par rapport à une application dans un langage compilé : il faut charger l’interprète au démarrage, et au tout premier lancement de votre application (et uniquement au premier) il y a aura une phase de décompression de vos fichiers. En dehors de ces petits inconvénients, ça fonctionne très bien.

Là encore, le projet est indépendant de Kivy et peut être utilisé avec un autre cadriciel.

Kivy for iOS : déployez sur les appareils Apple

À l’instar d’Android, l’équipe de Kivy fournit les outils pour faire votre distribution Python pour iOS.

Il vous faudra posséder une machine Apple pour les utiliser, à cause des restrictions imposées par cette plateforme (ceci n’est pas spécifique à Kivy pour iOS, mais s’applique à tous les outils pour développer sur iOS).

Ainsi avec une seule base de code (et après avoir passé un peu de temps pour configurer correctement les outils de compilation), vous pouvez déployer votre application Kivy/Python sur toutes les plateformes majeures (hormis le web, pour lequel il existe d’autres options comme Brython, Pyodide ou PyScript, mais c’est un sujet pour une autre dépêche).

Pyjnius : utiliser l’API Java Android depuis Python

Parfois l’utilisation de Plyer mentionné plus haut et de la bibliothèque standard Python ne suffisent pas, et vous avez besoin d’accéder à l’API d’Android, mais cette dernière est faite pour être utilisée avec Java ou Kotlin.

Pour pouvoir utiliser l’API d’Android depuis Python, PyJNIus est disponible. Ce paquet permet d’accéder aux classes Java comme à des classes Python en utilisant JNI (« Java Native Interface » ou « Interface Native de Java »).

Ce paquet fournit une méthode autoclass qui convertit automatiquement une classe Java en Python, c’est très facile à utiliser et souvent suffisant pour les cas simples.

KivyMD, des widgets Material Design

KivyMD n’est pas un projet officiel de l’équipe Kivy, mais un projet tiers dédié à la création d’un ensemble de Widgets thémables adoptant Material Design.

Image d’exemple de KivyMD issue de la documentation

L'image ci-dessus est issue de la documentation de KivyMD, vous trouverez également des démos vidéo sur le dépôt du projet.

Quelques limitations

Une petite note sur mon expérience personnelle (Goffi). Kivy est un excellent cadriciel, et l’équipe est accueillante et réactive : c’est un projet que je recommanderais en général. Ceci dit, dans mon cas particulier (un client XMPP ayant de nombreuses fonctionnalités), j’ai quelques limitations qui me poussent actuellement à chercher des alternatives, notamment basées sur Qt (PyQt et PySide) :

  • l’accessibilité est un problème majeur. L’équipe y travaille, mais aujourd’hui les applications Kivy ne sont pas accessibles. C’est notamment dû au fait que l’interface utilisateur est entièrement gérée par Kivy, au lieu d’utiliser des composants natifs, et c’est un point complètement bloquant pour moi.
  • il n’y a pas de webview ou de rendu HTML natif, ce qui est bloquant parce que je fais du rendu de blogs.
  • le rendu de texte est incomplet, notamment sur les plateformes mobiles. C’est compliqué de faire un rendu riche avec des émojis, par exemple, un gros problème pour une application de messagerie de nos jours.
  • le support des portails Freedesktop est inexistant : il faut faire l’implémentation à la main, alors qu’il est natif sur des cadriciels majeurs comme GTK ou Qt. Je pense par exemple à l’ouverture ou l’enregistrement de fichier. Les portails sont particulièrement nécessaires si on veut voir son application sur Flatpak. Plus de détails sur ce ticket.
  • le support Wayland existe, mais lors de mes tests sur des distributions GNU/Linux sur Pinephone, il n’a pas fonctionné et je n’ai pas pu afficher l’application.
  • le chargement de l’interprète Python prend un certain temps, ce qui rend le lancement de l’application sur plateformes mobiles telle qu’Android et probablement iOS (que je n’ai pas testé) un peu lent. Sachant que sur ces plateformes l’application peut être tuée à n’importe quel moment auquel cas il faut tout relancer, cela peut mener à une mauvaise expérience utilisateur. Ceci dit, avec une distribution optimisée (en enlevant les paquets non utilisés), et sur les téléphones actuels qui sont très puissants, le problème est sans doute moindre.

Notez que je n’ai pas eu l’occasion de travailler avec Kivy récemment, peut-être que ces remarques ne sont plus à jour. Merci d’indiquer en commentaires s’il y a eu de l’évolution sur ces points.

Aussi, mon cas d’utilisation est très demandant (rendu HTML, affichage de texte performant, etc). Dans la plupart des cas, Kivy remplit sans problème toutes les cases (sauf l’accessibilité, qui reste son problème le plus important à mon sens).

Conclusion

Comme vous pouvez le voir, un travail considérable a été effectué sur Kivy et son écosystème, et il en sort un cadriciel performant, pratique, et qui peut potentiellement fonctionner sur la plupart des plateformes. Kivy est agréable à utiliser, et dispose d’une communauté très active et disponible.

Ce cadriciel mérite de s’y attarder, et est une option sérieuse si vous voulez développer un projet rapidement pour une ou plusieurs plateformes.

Une note d’histoire

Cette dépêche a été commencée le 04 octobre 2018 à 14:19 (au premier jour de la Pycon FR 2018, à Lille, où une partie de l’équipe de Kivy était présente). Je crois que c’est haut la main la dépêche qui est restée le plus longtemps dans l’espace de rédaction. Comme quoi, tout vient à point à qui sait attendre, comme dirait l’autre.

Merci à toutes les personnes qui ont participé à la correction de la dépêche.

Commentaires : voir le flux Atom ouvrir dans le navigateur

  •  

WoPiX, un serveur WOPI libre, indépendant, simple et léger

Un serveur WOPI (Web application Open Platform Interface) permet à un logiciel client de modifier un fichier stocké sur un serveur. C'est la couche indispensable pour qu'OnlyOffice, LibreOffice (Collabora Online) et d'autres suites bureautiques puissent être utilisés sur le web. Ainsi, lorsque vous réclamez l'ouverture d'un document depuis votre navigateur web, vous vous connectez à la suite bureautique en ligne avec une URL particulière, contenant, entre autres, le nom du fichier à ouvrir. La suite bureautique peut alors discuter avec le serveur WOPI pour récupérer le document. Les lectures, écritures et modifications d'un document sont gérées par le serveur WOPI, à la demande de la suite bureautique. Le protocole a été créé par Microsoft en 2012, la révision 14.5 de WOPI est sortie le 18 février 2025.

Les serveurs WOPI libres de Nextcloud, Seafile, Tracim… ne sont pas indépendants. Comme je voulais utiliser Collabora Online sans déployer un NextCloud complet, j'ai écrit un serveur WOPI très simple. Il est utilisé depuis plus d'un an sans problème et il est libre. Il est écrit en Java.

J'ai commencé ce développement car je travaille sur deux lieux privés différents avec un ordinateur à chaque endroit, un NAS dans l'un d'eux et je communique entre les deux machines à l'aide d'un dépôt git sur le NAS. Ça fonctionne relativement bien pour des fichiers qui n'ont pas vocation à rester ouverts dans des applications, mais pour des fichiers ODS ou ODT qui restent ouverts, c'est plus compliqué car je me retrouve souvent avec des versions concurrentes sur les deux machines. J'ai donc regardé du côté des suites de collaboration en ligne.

À une époque , je me servais d'Etherpad et de son équivalent tableur Ethercalc. Mais ces logiciels manquent de fonctionnalités, surtout le tableur. Problème supplémentaire : j'ai déjà beaucoup de fichiers aux formats LibreOffice.

Ça tombe bien, il y a la suite LibreOffice online, éditée par Collabora Online (CODE). Le problème — comme souligné par une dépêche — c'est qu'une fois CODE installé, tu te retrouves à poil avec rien qui marche : il faut un serveur utilisant le protocole WOPI.

Pour éviter d'installer tout un NextCloud, j'ai écrit un petit serveur WOPI. C'est du Java avec Spring Boot. Le serveur est très simple, sur le principe que plus un système est simple, moins il a de chances de tomber en panne.

Par exemple, il n'y pas de droits d'accès et on ne peut pas avoir plusieurs utilisateurs simultanés. Il faudrait mettre en œuvre le système de verrous et le système de droits d'accès (faire reposer les droits d'accès sur les droits du système de fichier, implique d'avoir un utilisateur sur la machine pour chaque utilisateur du logiciel). Cela n'a pas été implanté parce que je suis le seul utilisateur sur ma machine. Mais ce ne serait pas long à développer.

Le serveur une fois lancé expose des services REST, accessibles par la suite bureautique, mais aussi un service https qui permet d'afficher la liste des fichiers. Cette liste de fichier est cliquable et permet de se connecter à Libre Office avec la bonne URL. C'est la raison des paramètres proxyHost et code URL de l'application : être en mesure de générer la bonne URL.

Liste des fichiers

Le code est prévu pour avoir plusieurs backends à l'aide d'une interface. Le seul mis en œuvre pour l'instant c'est un stockage sur disque local (avec auto discovery : on lui donne un répertoire et il expose tout les documents du répertoire).

Il consomme peu de ressources, la charge dépendra plus de Collabora Online ou d'OnlyOffice. Le serveur WOPI se contente de lire un fichier à l'ouverture et de l'écrire de temps en temps (comme lors des enregistrements automatiques).

Il n'est pas testé avec OnlyOffice. En principe WOPI est une norme et ça devrait fonctionner.

On peut le lancer avec java -jar. C'est du Spring Boot. On pourrait utiliser systemd. De mon côté, je l'ai mis dans un container docker qui lance la commande suivante

java -Dlogging.level.root=INFO \
     -Dlogging.level.org.wopiserver=INFO \
     -Dserver.port=8880 \
     -jar /opt/app/app.jar \
     --baseDir /mnt/docs \
     --disableTLSCheck \
     --codeURL https://172.17.0.8:9980 \
     --proxyHost 192.168.124.252

Le code de WoPiX est dispo sur github et je suis ouvert à toute requête :-)

Commentaires : voir le flux Atom ouvrir dans le navigateur

  •