Non sono solo...

L'evento che maggiormente ha stuzzicato il mio ego negli ultimi giorni e' stata la mail di tal Lorenzo Bellini, studente lavoratore di Milano e lettore di questo blog (ciao, Lorenzo!), che oltre a menzionare Lobotomy nel suo blog mi informa dell'imminente apertura di un progetto di ricerca presso l'Universita' Bicocca rivolto allo sviluppo di un nuovo modello di desktop. Non sono solo a pensare che dopo vent'anni sarebbe forse il caso di esplorare qualche alternativa all'interfaccia utente general purpose... Chissa' che non traggano qualche ispirazione dalla (incompleta) sfilza di documentucci informali che ho sinora pubblicato sul sito. Attendo ulteriori news a tal proposito, e non nascondo la mia fretta di apporre gli occhi su qualche paper descrittivo del sistema che si vorrebbe implementare, dice Lorenzo, in forma di progetto free. Non e' da escludere, ed e' anzi probabile, che un giorno collabori a tale opera, almeno esternamente in qualita' di sviluppatore freelance.
Per quanto riguarda invece i progressi del progetto Lobotomy in se', non sono solo neppure sul fronte dell'implementazione e comunico che forse ho trovato un collaboratore: HoX, membro della Torino Linux Task Force (il gruppo da me involontariamente creato e dedito alla promozione attiva di Linux) e studente presso il Politecnico del capoluogo sabaudo, si e' proprio stasera incautamente offerto come beta-tester del codice e conto di metterlo all'opera in occasione del rilascio della release 0.3rc2 di Hyppocampus schedulato per questa settimana (ebbene si, finalmente!). Una mano nel debugging non e' mai sgradita, tutt'altro, e grazie a questa new entry e' possibile che le prossime release siano un po' meno bacate delle precedenti ;-)
Il futuro e' roseo.

Everything is Unix

Nonostante il mio proposito dell'altro giorno, non essendo riuscito a scaricar... ehm... acquistare regolarmente una licenza di Mac 8, sono passato direttamente all'installazione di Darwin sull'iMac G3 che mi e' capitato tra le mani. (Nota per i lettori occasionali: la maledetta immagine .cdr per PPC che si scarica dal sito si masterizza molto banalmente con il comando cdrecord nome_file.cdr, alla faccia di K3B ed analoghi che si rifiutano di trattare questo formato...).
Sono molto curioso di testare con mano se la ricca documentazione pubblicata sul sito di riferimento fa fronte ad una API effettivamente completa come quella promessa o se e' tutto fumo e niente arrosto...
Mentre la procedura di installazione prosegue, leggo un articoletto sulla seconda development release del Project Indiana, il progetto volto a rendere piu' user-friendly il notoriamente ostico e serioso Solaris: pare che, un poco alla volta, in Sun stiano cavando qualcosa di effettivamente usabile pure da comuni utenti desktop, e sebbene al momento il sistema non goda di una popolarita' neppur paragonabile a quella di Linux, di cui pretende di essere un rivale, c'e' da credere che, essendo esso supportato e spinto da un colosso che ha fatto e fa a tutt'oggi la storia dell'informatica e guida una torma di sviluppatori assai nutrita (del resto, sono sempre loro che lavorano su Java, OpenOffice e diversi altri pilastri), diverra' discretamente utilizzato da qui a qualche anno.
Cosa viene da pensare mentre si legge da una parte cotanto brano e dall'altra si installa la componente free del sistema operativo piu' innovativo della storia? Non voglio avanzare conclusioni, ma dal canto mio credo che prossimamente saro' un poco piu' attento alla portabilita' del mio codice ed all'aderenza alla specifica POSIX: con tanta carne al fuoco le possibilita' (e le alternative) sono tante, e tutte valide, meglio non focalizzare l'attenzione su un'unica piattaforma ma spaziare per quanto possibile.
In ogni caso, tutti e tre i sistemi menzionati in questo post sono piu' o meno derivati da Unix, ovvero *IL* sistema di ieri, di oggi, ed evidentemente di domani.

Mezzo Uovo Blu

Non sto a spiegare come e perche', ma e' successo: da ieri sono in possesso di un Mac.
Vabbe', non e' un Mac nuovo: e' un vecchio iMac G3 "Blueberry", il primo modello della serie di PC targati Apple da sempre in controtendenza col mercato dei soliti Intel + Windows.
Sulla macchina non so assolutamente nulla, in quanto l'ho accesa per la prima volta solo poche ore fa' trovandomi dinnanzi ad un errore del kernel, ed invece di fare quella che sarebbe forse la cosa piu' ovvia e pratica da fare, ovvero bootare con un live CD di una qualsiasi distribuzione Linux che supporti l'architettura PPC per curiosare tra le proprieta' fisiche del dispositivo, sto scaricand... Ehm... Sto attendendo che mi arrivi la licenza di Mac 8.6 per procedere poi con l'installazione.
Forse discutibile da parte di alcuni e' la scelta di adottare un sistema Macintosh (oltretutto obsoleto) in luogo di Linux, NetBSD, Darwin o qualsiasi altro sistema atto ad essere piazzato su quell'arnese, ma il proposito e' quello di mettere mano una volta tanto su qualcosa di diverso, da una parte lontano da Unix (solo la serie X di Mac e' basata su kernel FreeBSD ed anzi recentemente riconosciuta come Unix a tutti gli effetti) e dall'altra rivoluzionario, quantomeno in termini di interazione con l'utente, come e' stata (ed e') la piattaforma dei ragazzi di Cupertino.
Poi gia' lo so che per usare realmente l'apparecchio finiro' per caricare Darwin e consumare il repository di MacPorts (non posso certo mettermi a scrivere software per Mac Classic, o pretendere che su di esso ci siano tutte le applicazioni di cui abbisogno), ma finche' posso cavalco l'onda dell'entusiasmo hackish e cerco nuove fonti di ispirazione.
Questa volta, dal passato.

Non aprite quel cellulare!

Breve post per esprimere un parere in merito ad una notizia che puo' capitarvi di leggere o che magari avete gia' letto (a me era passata tra le mani diversi mesi addietro ed oggi me la trovo riproposta): il Readius, il "telefono" arrotolabile, e' una cagata pazzesca.
E' troppo grosso per essere un cellulare (vabbe' che chiuso e' assai compatto, ma lo si dovra' pur aprire... Ed allora non lo si potra' usare con una mano sola...), potrebbe rientrare nella categoria "Internet tablets" come i vari Nokia NXXX ma non ha connettivita' wireless ne' touchscreen (mi chiedo se ci sara' la possibilita' di scrivere almeno SMS), potrebbe starci ancora ancora come e-reader ma non e' ottimizzato per tale funzione (tanto valeva togliere il modulo GSM e renderlo ancor piu' compatto e piu' economico), e' palesemente fragilissimo, non e' open (quanto ci metteranno ancora i produttori di hardware a comprendere che l'unica strategia oggi valida e' quella di entrare nelle grazie dei developers "just for fun" che producono quintalate di applicazioni aggratis e si tirano dietro il mercato?) e costera' una cifra.
Molti potrebbero pensare a codesto aggeggio come ad un esempio di apparato mobile futuribile e futuristico, un simbolo dei tempi che cambiano e del progresso che avanza, ma a me sembra solo una trovata commerciale (che si risolvera' in un flop colossale con ulteriori nuove perdite per Telecom, coinvolta nell'iniziativa ed anzi tra i principali promotori): dai dispositivi portatili di prossima generazione mi aspetto molto di piu' che non codesto obrobrio di tecnologie potenzialmente valide malamente messe insieme.
Chi vivra', vedra'.

Deja vu

Da parecchio tempo un processo in background nella mia mente elaborava il seguente quesito: "Nella futura interfaccia di Lobotomy come potra' l'utente gestire piu' applicazioni insieme?". Ieri sera, poco prima di addormentarmi, una possibile risposta. Assai inattesa.
La versione breve e' "Non lo potra' fare": nella sintesi e' corretta, ma fuorviante... Indi vediamo di fare ordine.

Riferimento: oggi, in un qualunque desktop environment, le diverse applicazioni aperte sono contenute dal window manager ed "indicizzate" per mezzo della taskbar, la classica barra che risiede lungo uno dei margini dello schermo (solitamente in basso) ed ospita un pulsantino per ogni finestra. Clicco sul pulsantino, e la relativa finestra del programma viene portata in primo piano. In questo modo posso avere piu' applicazioni aperte e saltare da una all'altra comodamente, accedere ad esse anche quando la loro finestra e' sovrapposta da altre, ed avere sempre sott'occhio l'insieme.

Osservazione 1: come gia' piu' volte detto, uno dei propositi per le prossime evoluzione di Lobotomy e' l'astrazione delle applicazioni (*tutte* le applicazioni) in quanto "modalita'" di visualizzazione ed interazione con un dato item preso dal filesystem o su un result set. Ogni modalita' (view) descrive come tale elemento o gruppo di elementi (model) debba essere rappresentato ed ordinato sul monitor basandosi sulle proprieta' comuni di tutti gli elementi (controller), e quali operazioni possono essere su di esso intraprese. In questa ottica ogni lavoro dell'utente e' formalizzabile in modo elementare secondo lo schema
result set + eventuale item nel result set attivo + modalita' di visualizzazione
Se sto manipolando il sorgente di Hyppocampus avro'
tutti i files .c nel gruppo 'Hyppocampus' + solver.c + editor di testo
Se sto leggendo i feed RSS
tutti i feed RSS ordinati per data + (nessuno) + feed reader

Osservazione 2: meditiamo sulle azioni che comunemente compie l'utente davanti al PC. Con quante applicazioni egli interagisce contemporaneamente? Una. E quando ha finito con essa, che fa? Mediamente torna su una di quelle con cui ha operato piu' di recente.
Il player audio si apre all'avvio del PC e lo si lascia in esecuzione da una parte, idem dicasi per il client di instant messaging, nel mio caso abbandono pure il calendar, basket, e spesso la moltitudine di applicativi (editor di testo col codice su cui lavoro, browser aperto sulle pagine di documentazione, console, filemanager...) che lascio salvati nella sessione trattata dal session manager essendo troppo pigro per riaprirli ogni volta. Quante finestre rimangono? Un numero compreso tra tre e dieci. A che mi serve averle tutte a portata, se non le uso? Ben poco...

Osservazione 1 + osservazione 2: se io posso risalire a qualunque condizione di utilizzo da parte dell'utente con un insieme ridotto di informazioni, ed osservato che l'utente ha un, passatemi il termine, working set limitato a cio' che ha fatto nell'ultimo periodo di tempo, posso mettere insieme le due cose? Se si, come?

L'idea e' quella di una sorta di pannello per mezzo del quale accedere alle ultime azioni intraprese, in ordine cronologico, chiuse quando vengono abbandonate e ricostruite ad ogni nuovo ingresso. Possiamo chiamarla "taskbar temporale". Io preferisco chiamarlo piu' romanticamente "deja vu".
A questo punto, l'utente non salta piu' tra una applicazione e l'altra ma naviga (come in un browser...) attraverso le sue proprie operazioni: sta editando del codice (condizione 1), non ricorda i parametri da passare ad una syscall, ricerca la pagina di manuale che la descrive e la apre nel terminale (chiudendo la condizione 1 ed aprendo la condizione 2), legge, e torna indietro all'editor (ovvero, viene chiusa la condizione 2 e ricostruita la gia' esistente condizione 1).
Questa impostazione e' assai piu' vicina a quello che ai fatti e' il modo di operare comune, prendendo come riferimento quel che fa chi si trova dinnanzi al monitor piuttosto che l'innaturale astrazione delle singole applicazioni e delle singole finestre.

Mi rendo conto che, cosi' spiegata, la cosa poco si comprende e possa pure apparire astrusa, ma io sono molto soddisfatto di questa illuminazione. Faro' in modo di descrivere il meccanismo nel classico documentuccio informale, aiutandomi con qualche mockup.
Ulteriori delucidazioni ed elucubrazioni a seguire...

Ma dei plugins che me ne fo'?

Ci avevo pensato qualche giorno fa', ma avevo dimenticato di riportare la cosa su questo blog e solo ora, aggiustando qualche bug in Hyppocampus, mi e' tornato in mente.
La domanda e': serve ancora a qualcosa tenere la gestione dei plugins in Hyppocampus? L'idea era fondata sul desiderio di sfruttare la base dati con applicazioni comuni gia' esistenti, quali clients di posta ed altro, ma oggi che l'intera struttura di Lobotomy e' stata rivalutata in direzione di un completo desktop environment fine a se' stesso il fatto di mantenere compatibilita' con sistemi esistenti comporta solo un aumento nella complessita' della piattaforma ed un tempo considerevole di sviluppo (ricordiamo che, originariamente, ogni formato esterno in cui si volevano esportare i dati sul filesystem doveva essere gestito da un plugin dedicato) e mantenimento.
Assunto che in ogni caso il sistema avrebbe dovuto essere rivisto pesantemente (diciamocelo: il meccanismo di matching tra le richieste avanzate ed il reperimento del plugin adatto per soddisfarle era piuttosto abbozzato...) e che comunque e' stato sospeso nella release 0.3rc1, mi sa che e' la volta buona che scarto completamente questa funzionalita' dalla roadmap e dal codice.
Tanto ho gia' abbastanza materiale su cui lavorare ;-)

Piccola parentesi di aggiornamento: oggi ho constatato il funzionamento dell'implementazione del meccanismo degli observers del VFS, c'e' ancora qualche correzione strutturale da fare ma il piu' dovrebbe essere a posto. Ho individuato qualche bug in Hyppocampus, soprattutto nella gestione delle query che contengono stringhe, e li sto correggendo aiutandomi a tracciarli con qualche programmino di test che lascero' poi nella release finale in funzione di "unit tests".
Speravo di rilasciare questo weekend ma mi tocca rimandare di almeno un'altra settimana, in quanto altri impegni tengono occupato il mio tempo libero nei giorni lavorativi.
E poi, vorrei allegare al pacco finale un po' di documentazione in merito al nuovo VFS implementato in LibHyppo. Con tanti begli schemini sul trattamento interno degli eventi :-P

LSQL?

Gia' avevo avuto in passato questa sensazione, ma stasera essa si e' fortemente rafforzata: il SQL non mi basta.
Sto scrivendo la routine che verifica se un item sul filesystem Hyppocampus rientra o meno nel result set specificato da una query, permettendo dunque un controllo senza obbligatoriamente andare a consultare il database (che altrimenti sarebbe interrogato da tutti i processi che fanno uso degli observers ogni volta che un metadato viene creato, rimosso o modificato) e mi rendo conto che, allo stato attuale, alcune particolari interrogazioni non sono possibili.
Non e' possibile confrontare due metadati per lo stesso item (data ultima modifica = data creazione + N), malamente sono trattati i metadati con valori multipli (quando ne testo uno confronto tutti i valori assunti o basta che uno solo soddisfi la condizione?), nessun controllo a priori viene fatto sul tipo di metadato e sul valore con cui viene confrontato...
Per la prossima release di Hyppocampus (non in questa, la 0.3rc2, che e' gia' sufficientemente in ritardo) vedro' di fare mente locale sulla situazione, e credo che finiro' a definire un mio proprio dialetto SQL con qualche operatore in piu' rispetto a quello tradizionale; gia' adesso alcune interrogazioni non sono possibili a causa della natura della base dati (non esiste DISTINCT, non sono selezionabili funzioni di aggregazione nella query primaria...), ma forse sarebbe opportuno porre dei paletti ben fissati e documentati sulle modalita' di ricerca.
Gia' oggi il parser che verifica e trasforma le query ha numerose lacune (gestito poveramente e' ad esempio l'operatore IN), provvedero' a ritoccarlo prossimamente e, soprattutto, a pubblicare una ricca specifica di riferimento.

XML vs JSON

Nello scorso post ho fatto cenno alla possibilita' di non usare XML e XSLT per descrivere le applicazioni che dovranno essere (meglio usare il condizionale: "dovrebbero forse essere un giorno") integrate in Lobotomy, ma qualcos'altro.
Cosa?
Da un paio di versioni Clutter, quello che al momento e' il toolkit candidato per essere usato per l'implementazione della componente grafica del sistema, include una sorta di interprete JSON: dando in pasto ad un oggetto di tipo ClutterScriptable la descrizione di una scena formalizzata in tale linguaggio gli elementi vengono trattati e visualizzati, pure applicando effetti e cose graziose. Sembra proprio quel che ci vuole per l'"interprete" di programmi in Lobotomy ;-).
Il punto e' che la descrizione JSON e' statica, non prevede variabili come ad esempio il set di items estratti dal filesystem cui applicare l'effetto, ed urge trovare un compromesso tra la precedente proposta (result sets in XML e trasformazioni XSLT) con i nuovi orizzonti aperti da codesto strumento gia' bello che pronto.
La soluzione forse piu' ovvia e' quella di usare comunque XML e XSLT, ma per produrre un JSON da convogliare direttamente in Clutter ed ottenere l'elaborazione e la renderizzazione. Al momento mi sfugge come potra' essere possibile intervenire sulla "scena" astratta (e mascherata) dal ClutterScriptable per effettuare al volo i ritocchi dovuti a variazioni del result set rappresentato (la faccenda degli observers, gia' trattata), dunque esistono ancora margini di ripensamento e/o miglioramento.
Mi sa che alla fine l'interprete me lo devo scrivere da me...

FREE++

Essendo io artefice dell'iniziativa, non posso certo esimermi dal parteciparvi per mezzo del mio blog...
Su BarberaWare e' stato avviato il progetto FREE++, una campagna di sensibilizzazione degli sviluppatori freeware al freesoftware. Il fulcro dell'iniziativa sta in una sorta di lettera aperta (sebbene sia forse piu' corretto chiamarlo appello) che si vorrebbe vedere pubblicata in lungo ed in largo, al fine di essere letta ed illuminare qualche sviluppatore apportando nuova linfa al sempre piu' ricco panorama di software disponibile in forma di codice libero.
Non aggiungo altro in quanto la lettera, sotto riportata, gia' contiene pressoche' tutto; invito tutti a riprodurre a loro volta il testo sui siti e sui blogs di competenza, si' da propagare il messaggio quanto piu‘ lontano possibile.

Agli sviluppatori di software freeware,

questo messaggio, questo appello, e‘ a voi rivolto: rivolto a coloro che distribuiscono le proprie produzioni software gratuitamente, per mezzo dell‘Internet, in modo che tutti possano fruirne pur senza pagare per ottenere una licenza d‘uso; a chi e‘ mosso da passione e curiosita‘ nella realizzazione di un‘opera; alle persone che provano soddisfazione (ed anche, diciamocelo pure, divertimento) nel costruire qualcosa di utile, talvolta anche complesso, solo perche‘ appunto utile; a chi, per necessita‘ personale o per diletto, raccoglie la quotidiana e sempre rinnovata sfida degli addetti ai lavori in campo informatico: risolvere problemi.

Il punto cruciale che viene qui presentato e‘: perche‘ limitare le possibilita‘ di utilizzo, miglioramento e gradimento della propria produzione? Perche‘ confezionare una applicazione senza considerare l‘opportunita‘ di fare in modo che tutti possano trarre il massimo beneficio da essa? Perche‘ impedire a quelli con cui si spartiscono gli stessi interessi e le medesime passioni di apprendere il modo in cui si e‘ aggirato un problema e riutilizzarlo in altre opere? In poche parole: perche‘ non rendere il software non solo gratis, ma libero, un po‘ piu‘ "free"?

Inevitabile al giorno d‘oggi non aver mai sentito parlare di "freesoftware", o "software libero", ovvero di quella particolare modalita‘ di distribuzione del software secondo cui il programma viene accompagnato dal codice sorgente da cui si ricava poi il binario da eseguire. La variazione tra freeware a freesoftware e‘, sul piano pratico, minima: insieme all‘eseguibile compilato, pronto per essere eseguito dalla fascia di utenza che vuole usarlo per quel che fa, si distribuisce pure il codice sorgente che si e‘ amorevolmente steso, corretto e perfezionato per il programma stesso. Tale piccola accortezza porta ad una differenziazione assai piu‘ profonda tra i due approcci: l‘atto di pubblicazione del sorgente apre infinite strade a futuri sviluppi dello stesso, che potra‘ cosi‘ essere modificato, piu‘ facilmente perfezionato ed arricchito anche da terzi, ammirato e studiato da quelli che in esso trovano ispirazione o l‘agognata risoluzione di un proprio problema. Tutte attivita‘ che non potrebbero svolgersi se il software fosse si‘ gratuito ma pur sempre chiuso, segreto, inaccessibile. Tutte attivita‘ che non potrebbero svolgersi se si decidesse di condividere solamente lo strumento finale, la funzionalita‘, anziche‘ la conoscenza, il funzionamento.

Spesso l‘argomento "freesoftware" e‘ associato al mondo di GNU/Linux, il piu‘ conosciuto (ma non il solo) sistema operativo realizzato secondo i canoni dello sviluppo collaborativo, e ci si dimentica (o si ignora) che il principio base di questo approccio trascende ogni piattaforma, linguaggio e ambiente operativo. La concezione di freesoftware come lo si intende oggi nasce storicamente ben prima del fenomeno Linux e ne e‘ causa, non effetto, ed e‘ agnostica rispetto a qualsiasi tecnologia: nulla, ne‘ di carattere tecnico ne‘ legale ne‘ retorico, impedisce che un programma che si intende possa essere diffuso con una licenza libera sia scritto su un sistema operativo che di libero ha ben poco, o con strumenti proprietari e chiusi. La distinzione tra una applicazione ed un applicazione libera sta nella modalita‘ di distribuzione, non nel suo target o nella sua origine.

L‘invito che qui si vuole rivolgere ai tanti che amano realizzare cose utili per se‘ stessi e per il prossimo e‘ di valutare la possibilita‘ di renderle ancora piu‘ utili, andando al di la‘ della loro funzionalita‘ palese. La piena transazione dal modello freeware a quello freesoftware puo‘ essere piu‘ o meno indolore a seconda di come ci si vuol relazionare con chi si trovera‘ tra le mani il prodotto pubblicato: e‘ possibile impacchettare brutalmente il binario, il sorgente, la licenza preferita, e mettere il tutto a disposizione per il download su un qualsiasi sito web, oppure si puo‘ cogliere appieno lo spirito ed affrontare l‘avventura dello sviluppo collaborativo sfruttando la visibilita‘ di uno dei tanti portali che offrono spazio e risorse a chi vuole portare avanti un lavoro coinvolgendo altre persone in giro per il mondo, facendo crescere costantemente l‘opera. Per compiere un qualsiasi passo in direzione del software libero e‘ sufficiente volerlo, informandosi oggettivamente ed al riparo da ogni pregiudizio presso uno dei molti luoghi virtuali di dialogo e confronto sull‘Internet ed avanzare richieste di delucidazioni ai tanti che gia‘ hanno operato una scelta, oppure molto piu‘ semplicemente leggere il testo della licenza che piu‘ si gradisce e che meglio rappresenta le proprie esigenze: gli aspetti pragmatici da considerare immediatamente stanno tutti li‘, senza infarciture dialettiche soggettive e talvolta opinabili.

Gratis e‘ bene per molti, libero e‘ meglio per tutti.

Pipelines Grafiche

Leggendo questo articolo, e piu' in particolare il punto 7 della lista (che recita "Unless interface designers manage to offer the same functionality as the command line, that's not going to change -- and, frankly, not many are trying to do so."), mi torna in mente un vecchio proposito, diciamo "figlio" della gia' antica idea dell'OnMouseShell che si prevede per la componente applicativa di Lobotomy: riprodurre la funzionalita' della pipe (il carattere '|') caratteristica della shell Unix nell'interfaccia grafica.
Tutti sappiamo che la pipe nella linea di comando serve a usare l'output di un programma come input di un'altro, concatenando dunque piu' comandi in uno solo. Come interpretare questa funzione in un ambiente grafico, ove non esiste un output vero e proprio di un programma se non quello che viene disegnato nella sua finestra?
Per comprenderlo occorre fare un passo indietro, andando a ripescare il concetto per cui le applicazioni proprie del desktop environment Lobotomy non dovrebbero essere altro che trasformazioni di un result set estratto dal filesystem Hyppocampus; nel documento sopra linkato si parla di risultati in XML e programmi in XSLT, ultimamente sto un pochino rivalutando il formato da usare (e prossimamente esprimero' qui le mie elucubrazioni) ma la sostanza rimane la stessa. Se dunque riduciamo gli applicativi utente a manipolazioni di dati di formato universale e compatibili tra loro (o comunque artificiosamente resi compatibili), le cose si fanno un poco piu' strutturate: in questo contesto, la pipe dovrebbe permettere di presentare gli stessi dati in modalita' diverse, secondo schemi diversi, lasciandone invariate le proprieta'.
Facciamo il classico esempio chiarificatore: l'utente consulta la posta elettronica usando l'applicazione rivolta alla consultazione della posta elettronica (ovvero quella che dispone gli elementi a video con una lista di messaggi, lo spazio per la preview ed i pulsanti per comporre una nuova mail) cui viene passato l'insieme degli items presenti sul filesystem marcati come messaggi di posta. Poi pigia una shortcut (che potrebbe pure essere Win+Ctrl+\ , ovvero Win+| , cosi' si sfrutta pure quel che sarebbe altrimenti un tasto inutilizzato della tastiera...) e seleziona un'altra applicazione, ad esempio quella che funge da calendar, ed ecco che quegli stessi dati vengono presentati divisi per giorno di ricezione nella consueta griglia da calendar. Seleziona un singolo giorno, ovvero un sottoinsieme del gruppo di partenza (quello delle mail ricevute), di nuovo Win+| , seleziona il programma per l'instant messaging, ed ecco la buddy list delle persone che hanno inviato le mail di cui sopra.
Come concetto puo' forse apparire astruso, io stesso lo devo bene esplorare, ma una cosa e' evidente: in uno scenario del genere l'integrazione tra le diverse applicazioni sarebbe completa ed implementata ad un livello logico al di sotto delle singole applicazioni stesse (nel layer di trasformazione XML -> XSLT -> videata), e dunque implicita e trasparente.
Chi segue questo blog o ha comunque gia' letto qualche post puo' forse ricordare la precedente idea del plumb inverso: ebbene, questo qui illustrato ne sarebbe un utilizzo ideale (la trasformazione dalla lista di mail alla lista di persone da mettere nella buddy list nell'esempio sopra ne e' un dimostrazione), una funzionalita' basilare su cui le pipelines sarebbero costruite.
Un altro passo verso la convergenza tra la potenza della linea di comando e la semplicita' dell'interfaccia grafica...