Damit es in jedem Installationsformat gleich aussieht, liefern wir GTK mit
Wenn dieselbe App je nach Distribution etwas anders aussieht, liegt das meist nicht an der App, sondern an der auf dem System installierten Toolkit-Version. Ab beta.2 bringen alle vier Installationsformate dieselben Bibliotheken mit.

Linux-Apps können selbst bei demselben Build je nach Distribution unterschiedlich aussehen. Schalter sehen anders aus, die Abstände in Dialogfenstern stimmen nicht, und manchmal öffnet sich ein Fenster gar nicht. Das liegt daran, dass auf jedem System ein anderes Toolkit installiert ist.
Auch mote hat bisher zwei verschiedene Builds gepflegt. Das .deb-Paket verwendete das GTK des Systems, während AppImage, Tarball und Flatpak die benötigten Bibliotheken selbst mitbrachten.
Ab beta.2 haben wir die Builds zu einem einzigen zusammengeführt.
Unterschiedliche Installationsarten, dieselbe App
Jetzt enthält auch das .deb-Paket GTK 4.22 und libadwaita 1.9 unter /opt/mote. Unabhängig von den auf dem System installierten Bibliotheken kann es unter Ubuntu 22.04 und Debian 12 mit apt install installiert werden. Aussehen und Verhalten entsprechen ebenfalls AppImage, Tarball und Flatpak.
Die mitgelieferten Bibliotheken haben wir auf die GNOME-Laufzeitumgebung von Flatpak abgestimmt. Es handelt sich um GLib 2.88, Pango 1.56, HarfBuzz 11, cairo 1.18 und fontconfig 2.16. Damit die App auch auf älteren Distributionen ausgeführt werden kann, bauen wir sie selbst in einem Container mit glibc 2.35.
Das Ziel besteht darin, die Zahl der zu prüfenden Kombinationen zu reduzieren. Wenn das GTK des Systems verwendet wird, unterscheidet sich das Toolkit je nach Ubuntu-Version. 24.04 verwendet 4.14, 24.10 verwendet 4.16 und 25.04 verwendet 4.18. Bei jeder Änderung an einer einzigen Stilzeile müssen all diese Kombinationen überprüft werden. Jetzt müssen wir nur noch die Installationsarten prüfen.
Wir haben auch darüber nachgedacht, das .deb-Paket abzuschaffen. Auf Ubuntu-Desktops ist apt jedoch der vertrauteste Installationsweg. AppImage startet etwa 140 ms langsamer und benötigt FUSE. Der Tarball bietet keine automatischen Updates, und Flatpak benötigt Ausnahmen von der Sandbox sowie eine Laufzeitumgebung von etwa 1 GB.
Deshalb haben wir das .deb-Paket nicht abgeschafft, sondern sein Inneres verändert.
Konsistenz für 14 MB
Das hat seinen Preis. Die Größe des .deb-Pakets ist von 4 MB auf 34 MB gestiegen. Beim Öffnen desselben Dokuments ist auch der PSS-Speicherverbrauch von 115 MB auf 129 MB gestiegen. Das liegt daran, dass die in der App enthaltenen Bibliotheken nicht mit anderen GTK-Apps geteilt werden können.
Die Leistung ist erhalten geblieben. Die p95-Zeit vom Tastendruck bis zur Anzeige auf dem Bildschirm ist von 4,82 ms auf 4,07 ms gesunken. Auch der Median der Zeit bis zur ersten sichtbaren Ansicht ist mit einem Rückgang von 306 ms auf 303 ms etwas schneller geworden. Wenn die App nur geöffnet bleibt, zeichnet sie wie zuvor keine Frames.
Für 14 MB zusätzlichen Speicher erhalten wir auf jeder Distribution dieselbe App.
Die Aktualisierung des mitgelieferten Toolkits ist eine regelmäßige Aufgabe, die ungefähr einmal pro Jahr anfällt. Wenn die GNOME-Laufzeitumgebung von Flatpak aktualisiert wird, aktualisieren wir zugleich auch die mitgelieferte Version. Dann bilden die acht Zeilen im Labor das Tor für diese Aktualisierung.
Über den Geschmack entscheidet mote, über die Barrierefreiheit der Benutzer
Auch die Markeneinstellungen haben wir neu geordnet. Für die Akzentfarbe und die UI-Schriftart werden die Standardwerte von mote verwendet und gleichermaßen auf die libadwaita-Widgets angewendet. Wer stattdessen den Desktop-Einstellungen folgen möchte, kann die beiden Schalter unter Einstellungen → Erscheinungsbild deaktivieren.
Die Einstellungen zur Barrierefreiheit folgen dagegen immer der Entscheidung des Benutzers. Die App überschreibt weder die Textskalierung noch die HiDPI-Einstellungen. Wer große Schrift aktiviert hat, sieht auch in mote große Schrift. Auch der Dunkelmodus kann direkt auf System, Hell oder Dunkel eingestellt werden.
Die koreanische Eingabe haben wir in acht Umgebungen geprüft
Wenn sich das Toolkit ändert, muss zuerst die Eingabemethode geprüft werden. Wir haben die koreanische Eingabe in acht Umgebungen getestet, die sich aus den Installationsarten sowie ibus und fcitx5, X11 und Wayland und Ubuntu 22.04 und 24.04 zusammensetzen. Alle Tests wurden bestanden.
Auch die Tests haben wir so überarbeitet, dass sie nicht mehr von Prüffunktionen für die Entwicklung abhängen. Jetzt installieren wir die tatsächlich ausgelieferten Dateien und prüfen anschließend, ob die Zusammensetzung koreanischer Zeichen ordnungsgemäß funktioniert.

Der sicherste Weg, überall dieselbe App bereitzustellen, besteht darin, zunächst die Bedingungen zu reduzieren, die sich unterscheiden können.