Se il motto di Hyppocampus e' "everything is a query" (ovvia parafrasi del classico "everything is a file"), il motto di Synapse (la componente grafica di Lobotomy) potrebbe diventare a breve "everything is a metadata".
Nell'ultimo periodo, profittando delle ferie (che oramai stanno per volgere al termine... Sigh...), ho avuto modo di pensare a lungo e di far collimare vecchi pensieri con nuove intuizioni, giungendo a conclusioni forse azzardate ma interessanti.
Oggi, l'applicazione: un pezzo di software dedicato ad un certo tipo di file, provvedendo alla visualizzazione e agli strumenti per la manipolazione. Qualche volta agisce anche quando non direttamente usato dall'utente (il client di posta scarica la posta, il player audio riproduce gli mp3 nella playlist...). E' fine a se' stessa, occupa memoria, deve essere debuggata, ha un aspetto ed un approccio diverso da tutte le altre applicazioni.
Come si puo' migliorare?
La prospettiva che meglio si adatta alla mia visione corrente e' quella del paradigma MVC, applicato a tutto il sistema operativo: il "model" viene interpretato da Hyppocampus, che indicizza e conserva in un formato quasi universale (quello dell'elemento arricchito da metadati) qualsiasi cosa; il "controller" e' un set di librerie (peraltro in buona misura gia' esistenti) che astraggono funzionalita' di vario genere (GStreamer, Phonon, WebKit...), e di demoni di sistema che provvedono alle varie attivita' di aggiornamento (scaricare la posta ed i feed RSS ad intervalli regolari e simili); infine, il "view" e'... il pezzo forte di questo post ;-)
Qualsiasi elemento indicizzato in Hyppocampus reca con se' i dati ad esso relativi. Questi dati devono essere presentati all'utente. Cosa c'e' di meglio che un CSS? Non mi riferisco alle ultime features previste/proposte/promesse per QT4, che permettono al piu' di personalizzare esteticamente una applicazione che comunque agisce sempre nello stesso modo, ma a definizioni (espresse in XML, XHTML, o qualcosa di molto simile) che permettono di formattare i contenuti sul video.
Esempio: il client di posta. Assunto che le operazioni di fetch e copia delle mail nel filesystem avvengano ad opera di un demone che, come gia' detto, rientra nella categoria "controller" del sistema, non mi resta che mostrare queste mail all'utente. Tutta l'applicazione e' rinchiusa in un template che recita: "recupera da Hyppocampus tutti gli elementi di tipo MAIL, ordinali cosi', mostra qui il metadato SOGGETTO, qua AUTORE e li' DATADICREAZIONE, quelli con il metadato LETTO con valore 1 falli traslucidi, quando uno viene cliccato mostra qua il valore del metadato CONTENUTO, e metti in cima questi due pulsanti per inviare un nuovo messaggio e rispondere a quello selezionato". Le icone da usare, i colori e gli effetti grafici addizionali diventano compito di Synapse, che interpreta ed applica il foglio di stile e conserva in se' tutte le preferenze dell'utente.
Gli stessi principi potrebbero essere adottati per una serie di programmi con cui tutti abbiamo a che fare: il player multimediale, l'aggregatore RSS, l'editor di testi... Synapse funge sempre e comunque da filemanager, semplicemente a seconda delle occasioni si trova a formattare i contenuti delle query eseguite in un modo piuttosto che in un altro.
Certo non e' la panacena di tutti i mali, ma, a parer mio, potrebbe essere un ottimo modo per ridurre notevolmente la mole di software piu' o meno utile che si trova in ogni sistema desktop. Senza contare che, basandosi completamente su una singola applicazione "mutante" ed avendo il tutto un discreto coefficiente di performance, ben si adatta all'ambiente embedded/mobile, in cui certo non ci si puo' permettere di avviare programmi su programmi.
Ancora a lungo devo meditare su quanto qui scritto, e paradossalmente mi trovo per l'ennesima volta a litigare con il design delle fondamenta di Lobotomy stesso: da due giorni mi arrovello per includere Clutter all'interno di Synapse sottoforma di widget GTK, e ora mi viene in mente che potrei riscrivere tutto Kiazma a mo' di widgets basati direttamente sullo stesso Clutter. Un lavoraccio che mi obbligherebbe a ricreare buona parte dello stack di funzionalita' gia' esistenti in GTK, ma che porterebbe pure ad una immensa flessibilita' e molto orientato al futuro del progetto...
Nessun commento:
Posta un commento