Pour garantir la même apparence quel que soit le format d’installation, nous avons décidé d’embarquer GTK

Sous Linux, une même version d’une application peut avoir une apparence différente selon la distribution. La forme des interrupteurs change, les marges des boîtes de dialogue se décalent et, parfois, une fenêtre refuse même de s’ouvrir. C’est parce que le toolkit installé diffère d’un système à l’autre.

mote maintenait lui aussi deux types de builds. Le paquet .deb utilisait le GTK du système, tandis que l’AppImage, le tarball et le Flatpak embarquaient directement les bibliothèques nécessaires.

Depuis la beta.2, nous avons réuni ces builds en un seul.

Des modes d’installation différents, mais une application identique

Désormais, le paquet .deb embarque lui aussi GTK 4.22 et libadwaita 1.9 dans /opt/mote. Il peut être installé avec apt install sous Ubuntu 22.04 et Debian 12, quelles que soient les bibliothèques présentes sur le système. Son apparence et son comportement sont également identiques à ceux de l’AppImage, du tarball et du Flatpak.

Les bibliothèques embarquées sont alignées sur l’environnement d’exécution GNOME de Flatpak. Il s’agit de GLib 2.88, Pango 1.56, HarfBuzz 11, cairo 1.18 et fontconfig 2.16. Elles sont compilées directement dans un conteneur utilisant glibc 2.35 afin que l’application puisse aussi fonctionner sur les distributions plus anciennes.

L’objectif est de réduire le nombre de cas à vérifier. Lorsque l’on utilise le GTK du système, le toolkit varie selon la version d’Ubuntu. La 24.04 utilise la version 4.14, la 24.10 la version 4.16 et la 25.04 la version 4.18. À chaque modification d’une simple ligne de style, il faut vérifier toutes ces combinaisons. Désormais, il suffit de vérifier les modes d’installation.

Nous avons aussi envisagé de supprimer le paquet .deb. Mais sur le bureau Ubuntu, apt reste le mode d’installation le plus familier. L’AppImage met environ 140 ms de plus à démarrer et nécessite FUSE. Le tarball ne dispose pas de mises à jour automatiques, tandis que Flatpak nécessite des exceptions au bac à sable ainsi qu’un environnement d’exécution d’environ 1 Go.

Nous avons donc modifié l’intérieur du paquet .deb au lieu de le supprimer.

Nous avons acheté la cohérence au prix de 14 Mo

Cela a un coût. La taille du paquet .deb est passée de 4 Mo à 34 Mo. Lors de l’ouverture du même document, la mémoire PSS est elle aussi passée de 115 Mo à 129 Mo. Cela s’explique par le fait que les bibliothèques embarquées dans l’application ne peuvent pas être partagées avec d’autres applications GTK.

Les performances ont été préservées. Le délai p95 entre la saisie d’une touche et son affichage à l’écran est passé de 4,82 ms à 4,07 ms. Le temps médian d’affichage du premier écran s’est également légèrement amélioré, passant de 306 ms à 303 ms. Comme auparavant, l’application ne dessine aucune image lorsqu’elle reste simplement ouverte.

En échange de 14 Mo de mémoire supplémentaires, nous avons obtenu la même application sur toutes les distributions.

La mise à niveau du toolkit embarqué est une tâche régulière effectuée environ une fois par an. Lorsque l’environnement d’exécution GNOME de Flatpak est mis à niveau, la version embarquée l’est en même temps. À ce moment-là, les huit lignes du laboratoire servent de passage obligé pour cette mise à jour.

mote définit ses préférences, l’utilisateur définit l’accessibilité

Nous avons également clarifié les réglages de la marque. La couleur d’accentuation et la police de l’interface utilisent les valeurs par défaut de mote, qui s’appliquent de la même manière aux widgets libadwaita. Si vous préférez suivre les réglages du bureau, il suffit de désactiver les deux interrupteurs dans Paramètres → Apparence.

En revanche, les réglages d’accessibilité suivent toujours les choix de l’utilisateur. L’application ne remplace ni le facteur d’échelle du texte ni les paramètres HiDPI. Les utilisateurs ayant activé les grands caractères les retrouvent également dans mote. Le mode sombre peut lui aussi être réglé directement sur Système, Clair ou Sombre.

La saisie du coréen a été vérifiée dans huit environnements

Lorsqu’un toolkit change, il faut commencer par examiner les méthodes de saisie. Nous avons vérifié la saisie du coréen dans huit environnements combinant les modes d’installation, ibus et fcitx5, X11 et Wayland, ainsi qu’Ubuntu 22.04 et 24.04. Tous les tests ont réussi.

Nous avons également corrigé les tests afin qu’ils ne dépendent plus de fonctions de vérification réservées au développement. Désormais, nous installons les fichiers réellement distribués, puis nous vérifions que la composition des caractères coréens fonctionne correctement.

Le moyen le plus sûr de proposer la même application partout consiste à commencer par réduire les conditions susceptibles de varier.