Lobotomy Project
Lobotomy Project
# In questo documento si presenta in modo informale la linea di sviluppo che si intende mantenere per la serie 0.3.x del Progetto Lobotomy, il quale sara’ costruito come un unico grande Model-View-Controller seguendo la regola per cui gli elementi grafici rappresentano elementi sul filesystem, ed essendo il filesystem di riferimento relazionale anche gli elementi grafici devono essere tali.
Introduzione
Cenni Globali
Il Linguaggio
Un Esempio
Il Futuro
# Gli ambienti operativi moderni, cui noi tutti siamo abituati, sono caoticamente composti da miriadi di applicativi monolitici isolati ed indipendenti, che includono al loro interno il codice per gestire la grafica (la finestra principale, i bottoni, i menu…), il codice per la manipolazione dei dati (sparpagliati in diversi files con diverse formattazioni in diversi angoli del filesystem), il codice per le funzionalita’ effettive (la connessione al tal tipo di server, la riproduzione del tal contenuto multimediale…), tutto impacchettato per compiere il task assegnato.
# Sebbene cio’ potesse andar bene agli albori del personal computing oggi i limiti imposti non sono piu’ accettabili: la complessita’ dei singoli programmi porta con se’ inevitabili difetti e problemi che talvolta possono sedimentare col tempo ed essere risolti solo con una completa re-ingegnerizzazione, l’aggiunta di funzionalita’ non previste fin dall’inizio risulta spesso o impraticabile o forzatamente applicata con risultati nefasti per l’usabilita’, e dall’altra parte l’esplosione dell’Internet ci ha portato ad avere una mole di informazioni enorme che si riuscirebbero ad usare pienamente solo se facilmente navigabili e correlabili tra loro, cosa attualmente non possibile data la scarsa integrazione.
# Il desktop e’ rimasto immutato per trent’anni** Ovvero dalla comparsa delle prime interfacce grafiche: Wikipedia , fior di effetti speciali sono stati aggiunti ma le finestre e le icone son rimaste li’ dove sono stati piazzate nei prototipi sperimentali realizzati presso i laboratori Xerox, ed e’ giunta l’ora di rivedere il sistema nella sua interezza, sia dal punto di vista dell’interazione uomo-macchina che dello sviluppo di codice operativo.
# Il Progetto Lobotomy** Homepage del progetto nasce con l’intento di sperimentare un nuovo modello architettonico per l’ambiente desktop (ma non solo), che non si limiti solo ad una differente disposizione delle componenti grafiche sul monitor ma vada a rivisitare l’intero percorso di interazione dell’utente con i propri dati, dal filesystem all’interfaccia. Due brevi documenti sono gia’ stati pubblicati in merito all’impostazione che si vuole adottare** Mapping the Graphical Environment into Filesystem (and Viceversa) e Split to Integrate , ma ne rivediamo qui i contenuti al fine di approfondirli, aggiornali alle piu’ recenti elucubrazioni, ed estenderli.
# Il target della serie 0.3.X del progetto mira a ricostruire l’intero ambiente prendendo ispirazione dal noto design pattern del Model-View-Controller** Il Model-View-Controller , riorganizzando alcuni dei componenti esistenti e definendo diversi ruoli per altri. Il model sara’ il filesystem relazionale Hyppocampus, contenitore universale di files ed informazioni interrogabile con query SQL; il controller verra’ interpretato dal SubConsciousDaemon e da una serie di altri daemons che implementeranno le funzionalita’ essenziali invocate di volta in volta dall’utente per mezzo dell’interfaccia o da altri daemons; infine, la posizione di view verra’ occupata da Synapse, applicazione che fino ad oggi e’ servita come semplice file manager ma che verra’ completamente riscritta per essere di fatto l’unica applicazione dotata di interfaccia grafica in esecuzione.
# I concetti di fondo sono due: separare le tre parti logiche di cui si compone ogni software (gestione dati, presentazione a video e business logic) ed astrarle una volta per tutte, a livello di sistema anziche’ di singolo programma, e costruire una mappatura 1:1 del filesystem, mantenendo la coerenza relazionale dei dati visualizzati nello stesso modo in cui sono trattati nello storage. In questo documento andiamo ad approfondire la seconda parte.
# Come puo’ un singolo applicativo essere adattato per ogni esigenza. Molto semplicemente: con dei templates predefiniti.
# Assumendo che esiste un insieme arbitrario di informazioni che possono essere presentate all’utente (tante quante sono le possibili query che possono essere eseguite sul filesystem ed i conseguenti result set estratti), ma non sapendo nulla sul modo piu’ conveniente di presentarle (dipendendo dalla immediata necessita’ dell’utente, cui non si puo’ leggere nella mente e che sarebbe comunque complesso da comprendere), l’idea e’ quella di mettere a disposizione un numero arricchibile a piacimento di templates, ognuno dei quali definisce il layout da adottare indipendentemente dal gruppo di dati passato e studiato per una specifica richiesta, lasciando all’utilizzatore la possibilita’ di optare per un template piuttosto che un altro in ogni momento. Tali templates saranno poi passati a Synapse al momento della loro attivazione, interpretati, ed usati come riferimento per la nuova disposizione della grafica.
# Un template sara’ composto da una rappresentazione ad icone dei files dati in ingresso e da una colonna che visualizzi i metadati X, Y e Z dell’item selezionato, un’altro conterra’ la lista scrollabile di quegli stessi files ed una barra con una serie di pulsanti che invocano funzioni ben precise, un’altro ancora visualizzera’ i nomi degli items inclinandoli e disponendoli randomicamente sul video (inutile, ma coreografico…). Ad ogni template potra’ essere passato ogni possibile result set, da filtrare e visualizzare cosi’ come richiesto, in modo non dissimile da quanto accade per XML con XSLT** Cos’e’ XSLT (da cui peraltro nasce l’ispirazione per questo meccanismo).
# E proprio in XML** Cos’e’ XML saranno definiti i templates. L’idea di usare l’eXtensible Markup Language per specificare un layout grafico non e’ affatto nuova** Si veda XUL di Mozilla o il GtkBuilder recentemente incluso nello stack GTK+ , e fornisce un ottimo compromesso tra facilita’ di implementazione, funzionalita’ e limitazione delle liberta’ lasciate agli sviluppatori dediti alla stesura di nuovi templates, i quali in qualche modo devono essere vincolati al fine di evitare iniziative che andrebbero ad intaccare la coerenza del look’n’feel globale e di guidare lo sviluppo in modo unitario, scongiurando ridondanze e forzando il riutilizzo del codice esistente.
# Il dialetto XML che qui si espone viene al momento chiamato, come imposto dal criterio di nomenclatura proprio del Progetto Lobotomy, "Thoughts", traduzione di "Pensieri".
# Soffermiamoci un istante per capire come dovra’ funzionare il sistema, in modo da focalizzare il nostro cammino verso una meta conosciuta.
# Immaginiamo che l’utente richieda un certo insieme di dati, vuoi stendendo a mano la query di ricerca vuoi invocando una delle query predefinite e salvate a mo’ di bookmark. I dati vengono prelevati da Hyppocampus e, grazie all’astrazione del VFS implementata in LibHyppo (la libreria allegata al pacchetto) si ottiene un HyppoVFSSet, ovvero un result set.
# Tale struttura dati viene passata a Synapse insieme al template da utilizzare, di default l’ultimo attivato prima dell’esecuzione della query oppure quello assegnato al bookmark selezionato, e l’interprete incluso nel programma legge il template, ne estrae la logica di posizionamento degli elementi, e piazza sul video i widgets prescelti pescandoli da Kiazma, la libreria grafica che implementa appunto i frammenti grafici di basso livello. Ad esempio, se il template contenesse
result_set = icon_view
# verrebbe utilizzata una rappresentazione ad icone dell’insieme, e per ogni item sarebbe costruita una icona cosi’ come definito dal widget "icon_view".
# Dato un insieme di dati, nulla vieterebbe di scegliere in ogni momento un diverso template, magari uno che contenga
result_set = list
# in tal caso gli stessi elementi sarebbero disposti in una lista, ovvero passati come argomento ad un widget preesistente nella libreria.
# La scelta di un template piuttosto che di un altro non sarebbe dettata solo dalla modalita’ di layout preferita, ma anche dal fatto che ogni template contiene la visualizzazione di informazioni aggiuntive (i metadati assegnati ad ognuno degli items nel result set) e le invocazioni di diverse funzioni eseguite nello strato del controller: un template ideato per la manipolazione di contenuti multimediali avrebbe i tasti per iniziare ed interrompere la riproduzione del file selezionato, mentre un’altro pensato per la navigazione della posta elettronica presenterebbe i pulsanti per replicare ad una mail ed aprire gli allegati. Cosa succede quando al template per le mail vengono passati files multimediali sara’ argomento per un’altro documento, parzialmente gia’ discusso in passato** Mixing Types .
# Il panorama sopra delineato porta implicazioni pesanti rispetto alle nozioni cui tutti noi siamo stati abituati dopo trent’anni di utilizzo del desktop WIMP** Window, Icon, Menu, Pointer .
# Innanzi tutto, non esistono piu’ le "applicazioni" cosi’ come le intendiamo noi oggi. Non esiste piu’ alcun processo che include al suo interno tutto quello che e’ richiesto per assolvere un insieme di compiti in qualche modo correlati, ma ogni aspetto computazionale viene astratto, implementato una sola volta e messo in condivisione. Ogni pratica di salvataggio ed elaborazione passiva dei dati viene centralizzata nel filesystem, l’intera grafica viene trattata da un singolo processo che si adatta in funzione di uno dei tanti templates selezionabili, il codice funzionale viene eseguito da processi dedicati eseguiti in background ed e’ invocabile attraverso un meccanismo di RPC (D-Bus, con ogni probabilita’).
# Di contro, ogni template viene dedicato ad un compito molto specifico e strettamente delineato: non esiste piu’ un "client di posta elettronica", ma separati sono il template per la consultazione della posta, quello per la composizione di una nuova mail, quello per replicare ad un messaggio arrivato… Da ogni template se ne puo’ richiamare un’altro in modo da costituire una sequenza logica di operazioni, ma ognuno di essi puo’ essere sostituito senza intaccare minimamente il resto del sistema.
# Non e’ propriamente un effetto dell’introduzione dei templates, ma insieme alle "applicazioni" si vogliono far sparire anche le finestre e le taskbar e rivoluzionare il flusso operativo dell’utente posto dinnanzi al monitor. Per maggiore dettagli in merito a questo obiettivo si legga il documento relativo.
# Essendo ogni template in puro XML e’ necessario elencare un insieme di tags utilizzabili ed interpretabili da Synapse: tale insieme, validato con una DTD ben precisa, fungera’ esattamente come ogni altro toolkit grafico, ma invece di avere una API per la costruzione e la disposizione dei widgets conterra’ equivalenti parole chiave da cui poi derivare la struttura grafica finale. In questo scenario il linguaggio XML usato viene usato a mo’ di wrapper della libreria Kiazma (che invece e’ una libreria e contiene delle funzioni che devono essere invocate secondo un certo ordine e con certi parametri), ed e’ una interfaccia di altissimo livello grazie alla quale in un colpo solo le informazioni prelevate dal filesystem sono tradotte in pixel colorati sullo schermo.
# Poiche’ uno degli obiettivi primari ed imprescindibili del linguaggio e’ la facilita’ di utilizzo e l’eliminazione di ogni fonte di ridondanza, urge ridurre drasticamente il numero di tags utilizzabili ed automatizzare il piu’ possibile la traduzione delle entita’ dal filesystem in elementi grafici. Per far cio’ occorre dimenticare le infinite carrellate di widgets utilizzabili nei comuni toolkits, da dover gestire solitamente a mano (nel codice), ma fare leva sulle proprieta’ relazionali delle informazioni che si vogliono rappresentare.
# I templates sono di due tipi, uno per la navigazione dei result set e l’altro per la manipolazione dei singoli items. Le differenze pratiche tra le due tipologie riguardano per lo piu’ l’inizializzazione della visualizzazione ed i riferimenti impliciti per i metadati (approfonditi tra poco), e la diversificazione e’ quasi esclusivamente al fine di mettere ordine che logicamente imposta.
# I tags vengono divisi per classi: una generica che ospita tags di uso speciale, una per i widgets di contenimento ed utili per allineare gli altri contenuti, una che funge da interfaccia verso le funzionalita’ implementate nel controller, ed una che include tutti gli elementi che mappano il filesystem.
# Sulla prima e la seconda non c’e’ molto da dire, verranno approfondite dopo.
# La terza include quegli oggetti che permettono di invocare determinate funzionalita’ sui files visualizzati in un dato momento nel template, e piu’ in generale sono i widgets che non sono associati a items dal filesystem e neppure servono alla formattazione della videata. Al momento qui sono contemplati solo i pulsanti cliccabili dall’utente, ma altri elementi sono in fase di studio.
# Infine la classe che davvero contraddistingue Thoughts, quella che implementa la natura relazionale del sistema nel suo complesso. In essa sono contemplati due soli tags: uno per i result set ed uno per i metadati. Perche’ non anche uno per gli items? Perche’ nei templates di navigazione gli items sono sempre contenuti nel result set e spetta al widget scelto per quelli rappresentarli secondo la visualizzazione preferita (icone, righe in una lista, pallini colorati…), nei templates di manipolazione l’intera schermata e’ un item e non c’e’ nulla da definire.
# L’unico tag di classe relazionale per cui viene esplicitato (comunque indirettamente) il contenuto e’ quello per i result set, mentre i widgets che rappresentano i metadati vengono disposti sul video ed il loro contenuto dipende obbligatoriamente da un item da cui leggere il valore scelto. Quale item? Nel caso dei templates dediti alla manipolazione diretta l’entita’ di riferimento e’ quella che si sta manipolando, sempre e comunque, mentre nei templates di navigazione e’ sufficiente indicare a quale widget-resultset il widget-metadato e’ collegato per fare in modo che la libreria si occupi di costruire le callbacks da attivare con la selezione degli elementi nel gruppo di dati.
# Questo genere di implicazioni automatiche permette di generare una gran quantita’ di codice (o meglio, di agganciare una gran quantita’ di callbacks predefinite) partendo da presupposti noti e sempre uguali, che possono essere tratti a priori appunto grazie alla natura relazionale e gerarchica delle informazioni da visualizzare: un metadato e’ sempre correlato ad un item, un item e’ sempre correlato ad un result set, un result set e’ sempre composto da items, un certo metadato e’ sempre presentato in una certa forma…
# Appare ovvio che, essendo i templates semplici files XML da recuperare alla bisogna, non esistono limiti sul numero di varianti che possono essere utilizzate in un sistema.
# Meno ovvia e’ la possibilita’ di introdurre nuovi widgets per la rappresentazione dei result set (ovvero nell’unico contesto in cui e’ permesso esplicitare il widget da usare): Kiazma e’ costruita in modo da poter accogliere nuovi moduli a caldo** Usando l’interfaccia GTypePlugin implementata in GObject con il preciso scopo di permettere il caricamento semplice e veloce di nuove forme di organizzazione grafica per gli elementi estratti dal filesystem. Il proposito sul medio termine e’ quello di prevedere una qualche forma di pacchettizzazione per i templates, in modo da far viaggiare insieme la descrizione XML ed eventuali moduli in essa richiamati.
# Un’altra possibilita’ di estendibilita’ viene fornita dall’opportunita’ di includere templates esistenti all’interno di altri: usando un tag speciale e’ possibile riutilizzare il codice XML scritto altrove e da qualcun’altro per arricchire la propria applicazione.
# In questo paragrafo si elencano schematicamente i tags sinora previsti all’interno del toolkit: chiaramente la lista e’ solo parziale e molte altre esigenze devono ancora essere soddisfatte, ma come vedremo nel capitolo successivo essi sono gia’ sufficienti per costruire templates perfettamente coerenti.
# Tags speciali: sono quelli usati per contenere il resto dell’applicazione, per inizializzarla ed identificarla
# Tags di contenimento: usati per formattare i contenuti, allinearli e disporli nel modo preferito
# Tags funzionali: per l’accesso alle funzioni implementate nel controller
# Tags relazionali: destinati a rappresentare le entita’ prelevate dal filesystem
# Come detto piu’ volte, le relazioni automatiche, predefinite ed implicite tra i diversi elementi grafici gioca un ruolo cruciale nell’ottica di ridurre il piu’ possibile il set di tokens da dover trattare nei templates XML. Alcuni attributi specifici sono stati identificati, di seguito la lista approssimativa
# Di seguito, un esempio che illustra in che modo puo’ presentarsi un template molto semplice per la composizione di nuove mail.
<?xml version="1.0"?>
<!DOCTYPE app SYSTEM "thoughts.dtd">
<app>
<name>mailcomposer</name>
<type>item</type>
<function>item:create</function>
<view ref="this">
<layout>
<vbox>
<relational>
<metadata type="META_MAIL_SENDER_ADDRESS" />
</relational>
<relational>
<metadata type="META_MAIL_SUBJECT" />
</relational>
<layout height="10">
<hbox>
<relational>
<metadata type="META_CONTENTS" />
</relational>
</hbox>
</layout>
<functional>
<button function="network::mail:send"
target="this"
desc="Send the mail" />
</functional>
</vbox>
</layout>
</view>
</app>
# Commentiamola dall’inizio: dopo le canoniche righe di inizializzazione per il documento XML vengono specificate alcune proprieta’ dell’intero template, il suo nome ed il suo tipo. Vediamo anche come viene applicata una funzione di inizializzazione (item::create), che forza la creazione di un nuovo item anziche’ l’apertura di uno esistente: questo appunto perche’ stiamo componendo una nuova mail, e pertanto un nuovo riferimento deve essere creato sul filesystem.
# Dopodiche’ vengono disposti i widgets che prenderanno il posto dei metadati assegnati all’elemento. Da notare che viene espresso solo il tipo di metadato che si vuole posizionare, in quanto sara’ poi l’interprete a scegliere il widget grafico piu’ opportuno per rappresentare il dato in base al suo tipo. Non viene esplicitata alcuna relazione tra i metadati e l’item di riferimento, appunto perche’ la relazione e’ implicita e forzata: essendoci qui un solo item trattato (quello creato in fase di inizializzazione, genericamente identificato come this) non esiste possibilita’ di errore.
# Al fondo si piazza il pulsante per l’invocazione della funzione destinata a trattare le informazioni immesse al termine dell’elaborazione da parte dell’utente. In questo caso si provvede a passare l’item di riferimento (target="this") al processo dedicato alla manipolazione della posta elettronica (network::mail), il quale vedendosi arrivare un HyppoVFSItem (ovvero, l’astrazione di basso livello dell’item, gentilmente costruita dall’interprete) ne andra’ a consultare i metadati META_MAIL_SENDER_ADDRESS, META_MAIL_SUBJECT e META_CONTENTS per la composizione del messaggio e la spedizione.
# E’ ovvio che il toolkit qui discusso e’ ancora lungi dall’essere completato, ed anzi questo stesso documento non va inteso come una specifica ma come una introduzione a quanto si vuole realizzare.
# In quanto sinora descritto mancano ancora dettagli sul criterio di concatenamento di diversi templates, che essendo tra loro invocabili devono pure in alcune occasioni passarsi l’un l’altro le informazioni elaborate durante le rispettive fasi di attivazione.
# Il numero di tags funzionali e’ destinato a crescere, in quanto numerose sono le situazioni in cui il dato da rappresentare e’ completamente astratto e non correlato ad alcun metadato: la selezione stessa di un tipo di metadato (magari in fase di assegnazione dello stesso) non e’ ancora permessa.
# In determinate (e preferibilmente molto limitate) condizioni dovrebbe essere possibile esplicitare il widget da usare per visualizzare un metadato, in quanto ad esempio una immagine puo’ essere presentata staticamente oppure all’interno di un contenitore speciale che ne permetta l’editing.
# I sopra menzionati aspetti richiedono una piu’ approfondita analisi del problema e si spera di divulgare soluzioni accettabili alle diverse richieste in una prossima versione di questo testo.
# Sebbene molto a rilento lo sviluppo di Lobotomy procede, ed in questo momento l’attenzione e’ incentrata sullo sviluppo di Kiazma, componente essenziale per la costruzione dell’intera interfaccia grafica del sistema. Considerando che le parti software in gioco sono molte e molto integrate tra loro non e’ possibile rilasciare quanto prodotto un poco alla volta, per il semplice fatto che ogni singolo pezzo e’ profondamente dipendente dagli altri e non basta neppure per una versione dimostrativa dell’ambiente.
# Come si evince dal testo sopra il codice da stendere e’ molto, in quanto si tratta di implementare in buona parte cose che non sono mai state sperimentate e che si vedono qui per la prima volta. Ma in fin dei conti e’ proprio questo lo scopo del progetto nella sua interezza, dunque non resta che attendere per vedere come va a finire (oppure partecipare allo sviluppo!).
Contents:
Introduzione
Cenni Globali
Il Linguaggio
Un Esempio
Il Futuro