Per garantire lo stesso aspetto con qualsiasi formato d’installazione, abbiamo deciso di includere GTK
Il motivo per cui la stessa app appare leggermente diversa a seconda della distribuzione non è quasi mai l’app, ma la versione del toolkit installata nel sistema. A partire dalla beta.2, tutti e quattro i formati di installazione includono le stesse librerie.
Su Linux, anche la stessa build di un’app può apparire diversa a seconda della distribuzione. Cambia l’aspetto degli interruttori, la spaziatura delle finestre di dialogo risulta irregolare e, a volte, le finestre non si aprono nemmeno. Questo accade perché ogni sistema ha installato un toolkit diverso.
Anche mote ha gestito finora due tipi di build. Il pacchetto .deb usava GTK di sistema, mentre AppImage, tarball e Flatpak includevano direttamente le librerie necessarie.
A partire dalla beta.2, abbiamo unificato le build.
Il metodo di installazione cambia, ma l’app è la stessa
Ora anche il pacchetto .deb include GTK 4.22 e libadwaita 1.9 in /opt/mote. Può essere installato con apt install su Ubuntu 22.04 e Debian 12, indipendentemente dalle librerie installate nel sistema. Anche l’aspetto e il comportamento sono gli stessi delle versioni AppImage, tarball e Flatpak.
Abbiamo allineato le librerie incluse al runtime GNOME di Flatpak. Si tratta di GLib 2.88, Pango 1.56, HarfBuzz 11, cairo 1.18 e fontconfig 2.16. Le compiliamo direttamente in un container con glibc 2.35, così che l’app possa essere eseguita anche sulle distribuzioni meno recenti.
L’obiettivo è ridurre il numero di casi da verificare. Quando si usa GTK di sistema, la versione del toolkit cambia con ogni versione di Ubuntu. La 24.04 usa la 4.14, la 24.10 usa la 4.16 e la 25.04 usa la 4.18. Ogni volta che si modifica una sola riga di stile, bisogna controllare tutte queste combinazioni. Ora basta verificare i diversi metodi di installazione.
Abbiamo anche valutato la possibilità di eliminare il pacchetto .deb. Su Ubuntu Desktop, però, apt è il metodo di installazione più familiare. AppImage impiega circa 140 ms in più ad avviarsi e richiede FUSE. Il tarball non dispone di aggiornamenti automatici, mentre Flatpak richiede eccezioni alla sandbox e un runtime di circa 1 GB.
Perciò, invece di eliminare il pacchetto .deb, ne abbiamo cambiato il contenuto.
Abbiamo acquistato coerenza al prezzo di 14 MB
C’è un prezzo da pagare. Le dimensioni del pacchetto .deb sono aumentate da 4 MB a 34 MB. Aprendo lo stesso documento, anche la memoria PSS utilizzata è passata da 115 MB a 129 MB. Questo perché le librerie incluse nell’app non possono essere condivise con altre applicazioni GTK.
Le prestazioni sono rimaste invariate. Il tempo p95 tra la pressione di un tasto e la visualizzazione sullo schermo è diminuito da 4,82 ms a 4,07 ms. Anche la mediana del tempo necessario per mostrare la prima schermata è leggermente migliorata, passando da 306 ms a 303 ms. Quando l’app resta semplicemente aperta, continua a non disegnare fotogrammi, proprio come prima.
In cambio di 14 MB di memoria in più, abbiamo ottenuto la stessa app su qualsiasi distribuzione.
L’aggiornamento del toolkit incluso è un’attività periodica da svolgere all’incirca una volta all’anno. Quando viene aggiornato il runtime GNOME di Flatpak, aggiorniamo insieme anche le versioni incluse. In quel momento, le otto righe del laboratorio diventano il passaggio obbligato per l’aggiornamento.
I gusti li decide mote, l’accessibilità la decide l’utente
Abbiamo anche riordinato le impostazioni del marchio. Il colore di accento e il carattere dell’interfaccia usano i valori predefiniti di mote e vengono applicati allo stesso modo anche ai widget di libadwaita. Se preferisci seguire le impostazioni del desktop, basta disattivare i due interruttori in Impostazioni → Aspetto.
Le impostazioni di accessibilità, invece, rispettano sempre le scelte dell’utente. L’app non sovrascrive il ridimensionamento del testo né le impostazioni HiDPI. Chi ha attivato il testo di grandi dimensioni vedrà caratteri grandi anche in mote. Anche per la modalità scura è possibile scegliere direttamente tra sistema, chiara e scura.
Abbiamo verificato l’immissione del coreano in otto ambienti
Quando cambia il toolkit, la prima cosa da controllare è il metodo di input. Abbiamo verificato l’immissione del coreano in otto ambienti ottenuti combinando metodi di installazione, ibus e fcitx5, X11 e Wayland, Ubuntu 22.04 e 24.04. Tutti i test sono stati superati.
Abbiamo modificato anche i test affinché non dipendano dalle funzioni di verifica destinate allo sviluppo. Ora installiamo i file effettivamente distribuiti e controlliamo che la composizione dei caratteri coreani funzioni correttamente.
Il modo più sicuro per creare la stessa app ovunque è cominciare riducendo le condizioni che possono variare.