Un design system da un’unica sorgente: come «Nitida» unisce GNOME Shell e GTK 4 in CardinalOS

Novembre 2026 · Redazione CODLAB

Risposta breve: Nei desktop Linux tradizionali la barra di sistema (GNOME Shell) e le finestre applicative (GTK 4 / libadwaita) leggono regole grafiche separate. Per CardinalOS, attualmente in sviluppo, la veste «Nitida» raccoglie colori, spaziature, raggi e tipografia in una sorgente JSON unica, genera deterministicamente i formati di destinazione nel repository di design e viene integrata per fasi.

1. La vera causa degli stacchi visivi: due sorgenti della verità

Un esempio concreto chiarisce come nascono gli stacchi grafici su molti desktop compositi: la barra superiore può adottare un grigio diverso rispetto alla finestra delle Impostazioni, il menu rapido può usare raggi d’angolo e margini differenti dal gestore file, e il passaggio tra modalità chiara e scura non aggiorna sempre ogni pannello lungo la stessa scala tonale.

La ragione è architetturale: GNOME Shell disegna la cornice dell’ambiente grafico — barra superiore, panoramica Attività, notifiche e finestre modali di sistema — con un proprio motore CSS (St / Clutter), mentre le applicazioni moderne si appoggiano a GTK 4 e alla libreria libadwaita. Entrambi gli strati sono solidi, ma leggono variabili cromatiche e metriche da file e convenzioni distinte. Quando si ritoccano a mano due fogli di stile separati, le modifiche rischiano di disallinearsi.

Accanto al lavoro preparatorio per CardinalOS, abbiamo sperimentato la separazione tra sorgente dichiarativa e fogli generati nel repository prototipale pubblico CodLab Thema (elencato nella pagina Progetti e Prodotti). In un repository interno di design dedicato, «Nitida» sviluppa oggi questo principio per CardinalOS.

2. Un unico file JSON dichiarativo invece di fogli di stile duplicati

Nel repository di design di «Nitida» le scelte visive risiedono in un unico file dichiarativo (nitida.json) anziché in modifiche sparse nei fogli di stile, articolato tra decisioni progettuali e set di token derivati:

• Decisioni, griglia metrica e fondi neutri (decisioni): Regole di contrasto, scala delle spaziature su multipli della griglia da 4 pixel (spazi: 4, 8, 12, 16, 20, 24, 32, 40, 48 px), raggi d’angolo, tipografia e i cinque livelli neutri di sfondo tela, laterale, superficie, rialzo e incavo per chiaro e scuro.
• Ruoli cromatici e di stato derivati (colori e contrasto_elevato): Gerarchie di testo e bordi (testo, testo2, testo3, bordo) insieme a nove famiglie di accenti calibrate (predefinito red «Cardinale») con chiavi come pieno, su, testo, tenue, selezione e anello nelle varianti chiara, scura e ad alto contrasto.

Lo script deterministico genera.py compila nitida.json senza valori numerici cablati producendo i formati di destinazione del cantiere:

1. Per GNOME Shell, genera.py emette i fogli St sotto shell/ (inclusi i fogli dedicati ai fattori del testo e la coppia movimento.css / movimento-ridotto.css) oltre a veste.json.
2. Per GTK 4 / libadwaita e le superfici correlate, la stessa esecuzione emette le regole di focus da tastiera e spaziatura sotto gtk/, gecko/ (per Cardinal Mail) e i temi browser sotto firefox/ e chrome/.

In tutti i formati di destinazione generati nel repository ogni colore, spazio e anello di focus da tastiera deriva dallo stesso file; il collegamento completo di tutte le uscite alle superfici vive del futuro desktop procede per fasi.

3. Giudici separati per contrasto e cascata CSS

Un’estetica sobria non deve tradursi in testi sbiaditi. Molte interfacce minimaliste usano grigi troppo tenui per etichette e metadati, faticosi da leggere su un comune monitor d’ufficio alla luce del giorno.

Nella pipeline di «Nitida» generazione e verifica restano separate: mentre genera.py si limita a scrivere i file di uscita, script di verifica indipendenti sotto giudici/ (in particolare armonia.py e cascata.py) controllano i valori di nitida.json e i fogli emessi rispetto alle formule WCAG (con lo stesso metodo descritto per il web in Verificare l’accessibilità prima del deploy):

• Testo primario e secondario sui cinque fondi neutri: Rapporto verificato almeno a 7,0 : 1 in modalità standard (10,0 : 1 per il secondario ad alto contrasto).
• Testo terziario, testo d’accento e colori semantici di stato: Almeno 4,5 : 1 rispetto alle superfici previste (7,0 : 1 ad alto contrasto), così da mantenere leggibili anche le note secondarie.
• Anello di focus da tastiera (anello) e bordi dei controlli (bordo): Verificati ad almeno 3,0 : 1 sulle superfici definite secondo WCAG 1.4.11; questa verifica copre le coppie di token del repository, mentre il collaudo di ogni singolo controllo in tutte le future applicazioni precede il rilascio pubblico.

Se una modifica in nitida.json scende sotto una di queste soglie o introduce sovrapposizioni nella cascata St, i giudici sotto giudici/ segnalano l’errore.

4. Movimento misurato: fogli generati e regola progettuale per il movimento ridotto

Sul desktop un’animazione è utile solo quando aiuta a capire dove ci si trova — ad esempio passando da uno spazio di lavoro all’altro. Transizioni lunghe, rimbalzanti o continue affaticano la vista e disturbano chi soffre di sensibilità vestibolare.

Nel repository di design di «Nitida» questo criterio è oggi realizzato nei formati generati: accanto a shell/movimento.css con durate brevi tratte da nitida.json, genera.py emette il foglio dedicato shell/movimento-ridotto.css che azzera quelle transizioni della Shell a 0 ms, insieme ai valori di movimento in veste.json. Come regola progettuale per CardinalOS, sia la Shell tramite enable-animations = false in GSettings sia le viste web e di supporto tramite prefers-reduced-motion: reduce dovranno disattivare i movimenti decorativi; poiché oggi è armata solo un’anteprima parziale non firmata, la verifica su ogni superficie viva del desktop resta da completare prima del rilascio — mentre la nostra mascotte Mochi qui su codlab.de applica già questa regola.

5. Dieci applicazioni pianificate nella Famiglia Cardinal

Un design system dimostra la propria utilità nel passaggio quotidiano da uno strumento all’altro. Per CardinalOS sono pianificate dieci applicazioni coordinate nella Famiglia Cardinal: Cardinal Write, Cardinal Sheets, Cardinal Slides, Cardinal PDF, Cardinal Mail, Cardinal Chat, Cardinal Photo, Cardinal Film, Cardinal Studio e Cardinal Host.

Anziché riscrivere da zero motori complessi già maturi, CodLab costruisce su basi open source collaudate, mantiene ben visibili i crediti agli autori upstream e allinea progressivamente barre superiori, pannelli laterali, dialoghi e icone ai token di «Nitida». Oggi Cardinal Photo è installata sulla macchina di sviluppo e sei candidati complessivi sono predisposti nell’ambiente di sviluppo, mentre altre applicazioni — tra cui Cardinal Slides e Cardinal Studio — sono in verifica di integrazione, firma e licenze. Un nome sul sito indica quindi un obiettivo pianificato in lavorazione, non un pacchetto già rilasciato.

6. Confini tecnici onesti: cosa copre oggi «Nitida» e cosa resta aperto

Progettare sistemi affidabili significa dichiarare con chiarezza stato effettivo e limiti tecnici:

• Stato attuale dello sviluppo (novembre 2026): Né CardinalOS né «Nitida» sono ancora consegnati come immagine pubblica installabile. Il generatore JSON e i giudici di contrasto girano in modo deterministico nel repository di design; sul desktop esiste oggi soltanto un’anteprima parziale non firmata per pannelli e superfici vetro, mentre dock, panoramica Attività, cornici delle finestre, blocco schermo, GTK globale e l’integrazione completa della famiglia restano aperti.
• Toolkit autonomi di terze parti: Su un desktop Linux aperto l’utente può installare qualsiasi pacchetto Flatpak o container. Le applicazioni che disegnano l’interfaccia con un toolkit proprio senza leggere i token GTK 4 — come diverse app Electron, launcher di gioco o software tecnici specialistici — mantengono il proprio aspetto nativo senza ricolorazioni forzate.
• Colori semantici delle singole app: Dove un programma definisce colori specifici di avviso o identità, «Nitida» è progettata per evitare sovrascritture cieche che potrebbero alterare segnali importanti per l’utente.

Puoi consultare le catture dalle sessioni GNOME isolate di sviluppo nella pagina dedicata a CardinalOS su codlab.de e registrarti per ricevere l’avviso di disponibilità su cardinalos.org.