Un side-project en prod : ShareYourSpeed

Tic-Tac

Un pendule est présent sur la scène. Son mécanisme raisonne dans la pièce.

J'ai réalisé un LiveSplit pour Linux, voici le code source de ShareYourSpeed. Hm… Je vais trop vite.

LiveSplit est un logiciel qui compte le temps passé. Il est très prisé des joueurs et des joueuses qui réalisent des speedruns - terminé rapidement un jeu vidéo selon des conditions.

Le logiciel permet de comparer le temps d'un précédent essai à l'essai actuel et ainsi se repérer dans le temps. suis-je en avance ? Suis-je en retard ?

L'essai (la run) est divisée en segment (en splits). On a ainsi le temps passé sur le ou les segment.s et sur la run. Pratique pour comparer le temps avec les autres speedrunners (j'ai utilisé le terme Anglais, ça inclut aussi bien les joueurs et les joueuses).

En termes d’utilisation simple, nous avons :

• démarrage de la run à partir d'un raccourci clavier.

• validation du split et passage au suivant avec un autre raccourci.

Le souci de LiveSplit ? C#. Un langage qui a besoin d'un environnement spécifique pour fonctionner (le runtime .Net).

Mon souci ? Je suis sur Linux. Le runtime .Net n'est pas installé nativement et il est difficile pour LiveSplit de gérer les raccourcis clavier. Il faut dire que gérer les différentes configurations n'est pas mince affaire. Même avec l'aide de Wine, un outil qui ajoute une couche d'abstraction pour faire fonctionner des applications nativement développer pour WIndows sur Linux, ne résous pas le problème.

Si moi, avec ma casquette de développeur, j'ai du mal à faire fonctionner un chronomètre, je reconnais que cet outil ne met pas destiné. C'est ainsi que ShareYourSpeed a débuté.

L'app, le service et le daemon

J'ai commencé par développer l'application en C++ (dossier app/). Une IHM en GTK, un parsing des fichiers LSS (c'est du XML) et les fameux raccourcis clavier. C'est à ce moment-là que j'ai compris qu'une application ne suffisait pas.

Si tout était intégré dans mon application principal, je risquais de perdre sa responsabilité : afficher le déroulement d'une run à partir d'un fichier LSS. GTK, comme tout outil constructeur d'IHM, fournit des signaux. Si j'envoie un signal spécifique, une action peut être connectée au signal reçu. C'est à ce moment-là où j'ai construit mon daemon (dossier daemon/).

Je ne voulais pas quelque chose de compliqué, je reste en C++, j'utilise une librairie spécifique qui écoute les événements de /dev/input (la librairie libevdev) et j'envoie des signaux dès que la touche est interceptée. Mon application se connecte aux signaux de mon daemon et fait évoluer l'IHM en conséquence.

Lancer le daemon et l'application à la main (dans un terminal), c'est possible, mais fastidieux. C'est ainsi que deux nouveaux dossiers sont apparus :

• systemd/ : un fichier service qui gère le daemon via systemctl.

• desktop/ : un fichier desktop qui permet d'avoir un raccourci de l'application dans la liste des applications.

Ensuite des petits scripts en plus pour faciliter l'installation de tout cet ensemble que je vous laisserai parcourir :

• build.sh : compile, installe et copie des fichiers à certains emplacements.

• clean.sh : supprime le dossier build qui résulte du build.sh.

• install-deb.sh : installe les paquets requis pour les distributions qui héritent de l'écosystème Debian.

Ma distribution principale est Fedora, voici l'installation des paquets requis avant le build.sh :

        
dnf install -y cmake \
  g++ \
  pkg-config \
  libevdev-devel \
  json-devel \
  tinyxml2-devel \
  libevdev-devel \
  gtkmm4.0-devel
        
    

Pour le reste, je vous laisse découvrir. J'ai les fonctionnalités que je voulais, mais je n'ai pas encore une version assez stable pour lui mettre un tag de version. Toutefois, la première étape de passer d'un side-project à quelque chose qui peut être présentable est passé et j'en suis assez fier.

Je continue la documentation et le développement de l'application bien sûr !

FF : Fun Facts

Je ne suis pas développeur C++ : juste un développeur qui aime bien construire une architecture logicielle sans se soucier du langage. Si vous êtes expérimenté, vous verrez surement des mauvaises pratiques du MISRA ou du CLang-tidy, à vraie dire, je n'ai pas su trancher dans certains cas (c'est beaucoup trop haut-niveau dans le bas-niveau).

Je suis un speedrunneur fantôme (Lost Ember : Glitchless - je ne publie pas encore ma run) : je me suis basé sur ma propre utilisation de LiveSplit lorsque j'avais un Windows 10. Ainsi les auto-splitter et les intégrations vers speedrun.com ne sont pas encore implémentés. Ça va venir avec le temps.

Le pendule continue son balancement, comme il a toujours su.