4 giugno 2010

TV Killed the Radio Star - parte 1

Come alcuni di voi di certo non sanno, è stato proposto un cambiamento nel modo in cui potrà in futuro essere inteso lo GNOME Desktop. I dettagli li trovate qui (e se non capite la differenza rispetto a prima, vuol dire che non conoscete GNOME e dovreste smetterla di dispensare consigli agli altri), i miei commenti... beh, lasciamo stare che è meglio.

Sulla base di ciò, se la nuova proposta va in porto, centinai e centinaia di applicazioni verranno di fatto incluse "ufficialmente" tra le GNOME Apps. Saranno tutte ugualmente valide? Soprattutto, cosa possono fare i rispettivi sviluppatori per migliorarle? Proviamo a rispondere a queste domande con un esempio pratico e sufficientemente dettagliato (e spero utile).

Avrei potuto scegliere come esempio il terribile Gwibber (che ce ne sarebbero di cose da additare), ma visto che sarebbe diventato solo un elenco di lamentele, ho preferito rivolgere l'attenzione a un altro programma, più utile alle nostre italiche genti: Tv-Player.

Per chi non lo avesse mai sentito prima, si tratta di un programma che permette di vedere gli stream offerti dalle televisioni via internet, prima tra tutte mamma Rai, senza passare per il browser e magari plugin di dubbia fama (come quello della Rai basato su silverlight/moonlight).

Funziona? Sì (mamma Rai permettendo). È una GNOME App "well behaving"? Proviamo a vedere.

Prima premessa: tecnicamente, per dichiarazione stessa degli sviluppatori, tv-player NON è un'applicazione GNOME, ma semplicemente GTK+.
Seconda premessa: non andrò ad aprire bug, per il semplice fatto che sono pigro :P
Terza premessa: questo non è un controllo di qualità del codice, ma solo la segnalazione di alcuni "standard" che magari tv-player non rispetta (nella versione che io ho installata, ovviamente)

File .desktop

Partiamo dal file .desktop, che poi è quello che serve per far sapere all'utente che l'applicazione è installata.

OK, lo ammetto, l'ho fatto apposta, solo per mostrare a quanti piccoli dettagli bisogna stare attenti in un file così piccolo:
  • non localizzabile - tramite intltool è possibile contrassegnare alcune chiavi dei file .desktop come traducibili (usando un file .desktop.in da cui poi intltool genera il file .desktop finale), qui si ha un file .desktop fisso nella pietra
  • chiave Version - dovrebbe essere non richiesta dalla specifica freedesktop.org, ma qui è addirittura usata male (non serve a indicare la versione dell'applicazione, ma della specifica per i file .desktop); se avessero verificato con l'utilità a riga di comando desktop-file-validate si sarebbe potuto ovviare questo piccolo problema
  • percorso assoluto per l'eseguibile - il nome dell'eseguibile basta e avanza, inserire il percorso qui impedisce di installare in altri percorsi (mai sentito /usr/local?); ci sono modi per inserire un percorso (con gli autotool, non so come in Python), ma dovrebbe essere gestito nella fase configure+make (confrontare i sorgenti di alcuni moduli ufficiali di GNOME - per ora)
  • icona - quanto fatto da tv-player è ammesso, ma è un modo vecchio, desueto e brutto di gestire l'icona che identifica l'applicativo; il file della icona dovrebbe essere installato nel tema hicolor (/usr/share/icons/hicolor/DIM/apps) e qui si dovrebbe indicare solo la named icon, senza percorso ed estensione, in modo da poter rendere l'icona temizzabile (importante per i temi a contrasto elevato, per esempio)
  • assenza della chiave GenericName e della suggerita X-GNOME-FullName - per informazioni leggere qui; tra l'altro "TV Player" è un nome "generico", sarebbe opportuno trovare un nome figherrimo che permetta una qualche forma di branding, specie nella prospettiva del passaggio a GNOME Shell (ricordo le slide di un talk, forse di MPT, che parlavano anche della scelta del nome, solo che non le ritrovo... lazyweb, un aiuto?)
  • avviso di avvio - mancherebbe anche la chiave StartupNotify, per fare in modo che la forma del cursore cambi, passando alla "clessidra" nel tempo che intercorre dal clic di avvio all'apparizione della finestra, ma in questo caso sarebbe necessario all'applicazione comunicare l'avvenuto caricamento e visualizzazione della finestra stessa.

Icone

Il mantra da seguire, in questo caso è: una brava applicazione non installa icone che non possano essere temizzate, una brava applicazione installa le "sue" icone in un "suo" percorso.

Tranne, come detto prima, l'icona dell'applicazione che dovrebbe essere istallata all'interno del tema hicolor - e men che meno in /usr/share/pixmaps, che deve morire :)

Una buona descrizione di perché e come correggere questo problema può essere trovata presso la pagina del GNOME Goal relativo fatto tempo fa.

Per le altre icone di TV Player solo qualche dubbio e suggerimento:
  • Perché mai installare icone proprie per il volume? Esistono delle named icon apposta nella specifica di freedesktop (le varie audio-volume-*), non sono tra le stock delle GTK+ ma...
  • ...ma, prima o poi le icone stock delle GTK+ andranno a morire, si spera nelle prossime versioni 3.x, per cui tanto vale usare quelle sia per il volume, sia per le altre icone presenti (per cui non gtk-delete, ma edit-delete, per esempio); questo ovviamente farà dipendere l'applicazione da gnome-icon-theme, ma è tutto da guadagnare, in prospettiva per il futuro.
Ah, se proprio volete o dovete inserire una icona "application-specific" (ossia una icona che non è tra quelle presenti in gnome-icon-theme e definita nella specifica indicata poco sopra), il modo "well behaving" di farlo è descritto qui.

Hidden file

Ultima annotazione, per oggi, riguarda un'altra specifica freedesktop e un'altra delle raccomandazioni da seguire per una brava applicazione GNOME: evitare di creare nella HOME degli utenti cartelle o file .$APPLICAZIONE.

Esiste infatti uno standard ben definito e documentato che dice come e dove piazzare i vostri file aggiuntivi per dati, configurazione, cache (e pare altro in futuro).

Le glib (e credo anche i relativi binding in Python) offrono delle comode funzioni per astrarre e gestire il tutto, evitando ogni forma di hardcoding dei percorsi assoluti o relativi. Motivazioni, vantaggi e altre indicazioni possono essere trovate qui, nella pagina wiki del relativo GNOME Goal.

Rispettando questo standard freedesktop è possibile evitare la proliferazione tipo disco di Petri di cartelle .$APPLICAZIONE nella home degli utenti, utilizzando le funzioni messe a disposizione di glib si guadagna la possibilità di rendere facilmente multipiattaforma la propria applicazione (che andrà a creare e controllare file e cartelle, senza preoccuparsi troppo del come, nella posizione giusta). Agli utenti, poi si permetterà di avere la possibilità di eseguire backup facili e non superflui, scegliendo per esempio di ignorare la cartella $HOME/.cache il cui contenuto è per definizione volatile e non fondamentale.

Trucchi, segreti e commenti

Se avete seguito tutti i link proposti prima vi sarete accorti di come anche molte applicazioni al momento ufficiali di GNOME ancora non seguono le indicazioni date. È pur vero che diverse di quelle applicazioni esistono da una decina d'anni, per cui è possibile che si tratti di strascichi ancora da correggere o tagliare via.

TV Player dovrebbe invece essere un'applicazione molto giovane, che avrebbe potuto rispettare sin da subito queste direttive o suggerimenti. Forse l'assenza di un unico punto di raccolta delle informazioni, il dover seguire con perdita di tempo personale diverse discussioni, mailing list, siti, blog, planet e quant'altro in modo da avere una visione d'insieme chiara è l'ostacolo più grande per chi sviluppa applicazioni di "terze parti". Esisterebbero la Integration Guide e la Platform Overview, ma in effetti sono documenti un po' datati; allo stesso modo sul wiki sono magari disponibili notizie più aggiornate, ma senza essere organizzate in un corpus organico.

Come preannunciato dal titolo questa è solo la prima parte, nella prossima (chissà quando mai apparirà, lo sapete che sono pigro e facilmente distraibile, specialmente in questo periodo d'inizio d'estate in cui cominciano a riapparire le te... vabbè, quelle cose lì che creano distrazione, mo' non è necessario specificare cosa sono, no?) andremo a spulciare la UI in cerca non già di un completo re-design (mica mi chiamo MPT, io) ma di altri aspetti e difetti che tolgono punti a questa applicazione.

2 commenti:

janvitus ha detto...

Penso che intendano come applicazioni esterne di seconda classe le applicazioni aggiuntive che sono ospitate sullo GIT di GNOME. Niente in contrario a ritenerle tutte di prima classe, l'importante è che seguano le HIG e le specifiche della Freedesktop. Basta leggere la motivazione del rigetto delle libappindicator proposte per l'inclusione nella 3.0, e ci mancherebbe...

Turycell ha detto...

Un articolo splendido, complimenti.