Pensieri e parole su HCI, home computing, tecnologie desktop e sul Progetto Lobotomy

lunedì 17 dicembre 2007

Webmaster si nasce, parte seconda

0 commenti
Dopo aver (mesi addietro) sistemato il blog, questa sera colto da ispirazione ho sistemato anche il sito del progetto Lobotomy. Non che abbia fatto stravolgimenti particolari, semplicemente ho spostato il menu in una barra laterale (anziche' nell'intestazione) e poco altro, probabilmente la novita' piu' grossa consiste nel feed RSS agganciato alle news pubblicate sulla pagina. Ultimamente metto RSS ovunque :-P
Prossimamente faro' in modo di aggiungere tra le news anche la pubblicazione di nuovi papers, documentazione ed altro, insomma usare davvero questo strumento come "news" e non solo come annuncio delle nuove releases. E vorrei iniziare ad usare questo simpatico strumento che facilita la trasformazione di puro testo in pagine HTML, sempre per la documentazione (soprattutto quella cosiddetta "informale").

sabato 15 dicembre 2007

Magic Ink

0 commenti
Negli scorsi giorni ho avuto modo di leggere questo paper.
Nonostante sia stato scritto da una persona senza particolari referenze o titoli, ottimamente rappresenta quello che e' e quello che dovrebbe essere l'interfaccia utente di un PC: oggi abbiamo a che fare con lo strascico di vent'anni di pigrizia ed abitudine, durante i quali sono stati usati, riusati , abusati ed edulcorati concetti creati agli albori del personal computing per ovviare alla scarsita' di risorse dei sistemi dell'epoca, mentre la strada dovrebbe essere quella dell'integrazione e dell'automatizzazione.
La prima parte splendidamente riassume i principi intorno a cui dovrebbe essere costruita una interfaccia non solo "usabile" ma anche comoda ed intuitiva con un poco di buon senso e di stile, mentre nella seconda (dopo una lunga divagazione dell'autore un po' fuori tema, sull'implementazione di un tool per designers...) sono illustrati esempi di come i piu' forti progressi potrebbero essere raggiunti sfruttando al meglio la potenza delle macchine odierne per prevenire ed anticipare le esigenze dell'utente e limitare al massimo la fase di interazione col sistema (ovvero: la fase piu' critica, noiosa ed error prone).
Ammetto di essere stato fortissimamente influenzato da questa lettura e dalle perle di ingenua saggezza che riserva (alla fine, non dice nulla di nuovo. Semplicemente lo dice molto bene...), ho rafforzato alcune idee per lo sviluppo di Lobotomy, scartatene altre ed introdotte un paio di nuove. Mentre occasionalmente continuo il perfezionamento del VFS object oriented in LibHyppo di quando in quando mi fermo a meditare su come potrebbe apparire il prossimo Synapse soprattutto nella sua nuova prossima incarnazione di desktop manager.
Dovro' decidermi a scrivere una paginetta di documentazione preventiva prima o poi...

martedì 11 dicembre 2007

LiPS

0 commenti
Quando ho letto per la prima volta la notizia ho pensato "bella iniziativa, ma con tutto l'hype generato intorno ad Android probabilmente finira' nel dimenticatoio...". Ed invece, qualche reazione c'e' stata, sebbene di entita' mediatica assai minore che non il teatrino messo in piedi da Google e soci.
LiPS, consorzio per la standardizzazione di Linux su piattaforma mobile, ha rilasciato (dopo due anni dalla fondazione del consorzio stesso... Sign...) la prima versione della specifica di riferimento.
Personalmente vedo luci ed ombre su questo evento: da una parte la volonta' di costruire uno standard effettivo (agnostico rispetto a qualsiasi framework o ambiente di sviluppo) per garantire interoperabilita' tra le applicazioni mi suona bene, ma dall'altra trovo la specifica insoddisfacente sotto diversi aspetti (troppo restrittiva su certi componenti, troppo lasca su altri...); il proposito e' quello di facilitare la vita a chi sviluppa applicazioni, ma il consorzio e' totalmente chiuso e scarso e' il margine di interazione col mondo esterno (la community, insomma); si punta molto su tecnologie open, ma l'ente poco sembra essere propenso ad aderire anche solo lontanamente alla filosofia di condivisione.
Ad ogni modo, voglio credere a questa opera, in quanto piu' concreta che non il gia' menzionato Android (che mira all'implementazione di una piattaforma, non alla definizione di un'API comune, che sul lungo termine porta a molti piu' vantaggi): gia' ho mandato una mail sulla lista degli sviluppatori del framework di OpenMoko per chiedere in merito alla loro adesione allo standard, ma non ho ricevuto risposta; vedro' di adoperarmi per fare la mia parte, magari implementando quel poco glue code che funga da interfaccia tra le funzioni elencate nella documentazione e gli strumenti gia' oggi esistenti.
Questo e' un passo verso l'interoperabilita', e l'interoperabilita' e' un passo verso l'integrazione.

sabato 8 dicembre 2007

Cambiare, dalle fondamenta

0 commenti
Ieri sera, dopo aver scritto il precedente post, mi sono auto-ispirato e sono andato a leggere qualche articolo online del gia' menzionato Raskin e da altre fonti correlate, per rinfrescarmi la memoria.
La convinzione generale che mi sono fatto e' che i commenti di Raskin, correttissimi e sacrosanti, implicherebbero uno stravolgimento completo non solo del concetto di interfaccia utente, ma di tutto il sistema operativo a partire dal kernel.
Gia' da tempo il ben noto Tanenbaum sostiene il fatto che un PC deve essere stabile e sicuro per essere usabile, esattamente come... un televisore (che, notoriamente, non crasha, non reboota ed e' usabile da chiunque), ma oltre a cio' occorrerebbe forse rivedere il modo in cui le applicazioni interagiscono con il resto del sistema.
Per fare un esempio: a detta di Raskin (e non solo) non dovrebbe mai esserci bisogno di salvare i documenti o i files che si stanno elaborando. Sfido chiunque a dire che sia una cosa sbagliata. Ma come implementare cio'? L'applicazione deve costantemente tenere traccia delle operazioni che esegue l'utente, bufferizzarle e sbatterle permanentemente sul disco, ma... Ad oggi, nella specifica POSIX non e' minimamente prevista una cosa del genere, ed un file deve sempre essere scritto per intero (o comunque: a partire da dove e' stata eseguita la modifica in poi, tutto). Manca una syscall per dire al filesystem "salvami questi tot dati a partire dalla posizione X, ma non al posto di quelli esistenti: nel mezzo!".
Nei prossimi giorni leggero' (o ri-leggero') qualcosa in piu' di quanto scritto da Tanenbaum (o, piu' in generale, in merito a Minix3) per trovare qualche punto di contatto tra le visioni di alto (l'interfaccia utente) e di basso livello (il kernel) dei due personaggi, in costante ricerca di ispirazione.

venerdì 7 dicembre 2007

La via del Maestro

0 commenti
L'altro giorno ho acquistato un libro (usato) su Amazon. Oltre a segnalare il fatto in se' (e' il primo acquisto di un bene materiale che effettuo sull'Internet...), il motivo della menzione su questo blog e' da ricercare nella natura del libro stesso: "The Humane Interface" del mai sufficientemente compianto Jef Raskin.
Per sapere chi sia stato Raskin rimando alla pagina su Wikipedia, di cui consiglio lettura a tutti coloro che non sanno a chi mi stia riferendo: se state usando un sistema operativo dotato di interfaccia grafica (un sistema qualunque ed una interfaccia una qualunque...) e' opportuno sapere a chi dovete cio'.
Gia' possedevo una copia... ehm... digitale "di valutazione" del libro, ma ho voluto procedere con l'acquisto della copia cartacea onde poterne consultare spesso e velocemente i contenuti: dal poco che ho avuto modo di leggere (la mia "copia di valutazione" e' assai scarsamente navigabile, stramaledetto chi ha inventato il formato CHM...) ed apprezzare, il volume offre una infinita' di spunti per la costruzione di interfacce grafiche *realmente* usabili, che vadano al di la' dei soliti preconcetti e delle solite abitudini.
"Una provocazione", viene definito da uno dei commenti trovati su Amazon, ma una provocazione generata da chi ha inventato quello che ad oggi e' lo standard di fatto sui monitor del mondo intero e dunque degna quantomeno di considerazione.
Non nascondo di sperare di essere largamente ispirato da questa lettura durante la definizione del prossimo Synapse e della libreria Kiazma: staremo a vedere quanto riusciro' a elevarmi al di sopra dei miei stessi preconcetti e ad aderire alla drastica visione di Raskin.

giovedì 29 novembre 2007

Fuori

0 commenti
Quando ho trovato questo link in una mail della mailing list del Progetto Clutter ho pensato "Carino, peccato sia una patch esterna a GTK. Chissa' se includeranno mai qualcosa del genere nel mainstream...".
Ieri, dal blog del funambolico Mac Slow, sono venuto a sapere che la patch per l'offscreen rendering potrebbe essere inclusa gia' nella versione 2.14 (la prossima stabile). E saranno possibili effetti come questo qui.
La stessa cosa dicasi sul fronte QT.
Cosa implica tutto cio'? Implica nuovi effetti, nuove e sinora inaudite possibilita' per le interfacce utente delle quotidiane applicazioni, e tanto caos.
Rimango sempre dell'idea che tutti questi strumenti offerti ai designer di user interfaces, sebbene potenzialmente utilissimi e comunque indubbiamente gradevoli graficamente, porteranno a breve ad una forte frammentazione nel look & feel di ogni applicazione, ed invece di procedere sulla strada dell'integrazione ognuno si sentira' legittimato ad applicare rotazioni, zoom, animazioni e quant'altro dove piu' gli aggrada, in una continua competizione a chi realizza l'interfaccia piu' estrosa (ed inusabile...).
C'e' da credere che a breve nasceranno frameworks (o si modificheranno quelli esistenti) che permetteranno di sfruttare comodamente tali innovazioni, intrinsecamente limitando eventuali colpi di testa contenendo le velleita' artistiche dei developers entro una API comune per tutti e ben specifica, ma la tentazione resta sempre forte, soprattutto quando si hanno a disposizione librerie cosi' comode e potenzialmente cosi' distruttive come la gia' citata Clutter.
Per quanto mi riguarda, continuo a lavorare (o meglio: continuo a sperare di poter lavorare :-P ) sul mio proprio toolkit (Kiazma) con l'intento di usare sempre e solo quello nel contesto di Lobotomy ed uniformare l'interfaccia delle applicazioni che saranno (un giorno o l'altro...) comprese nell'ambiente, ed accolgo di buon grado la possibilita' di usare i widgets gia' esistenti in GTK, con il proposito di riutilizzare soprattutto gli elementi di input (GtkEntry, GtkTextView...) ed integrare il toolkit con widgets espressamente rivolti alla manipolazione degli items provenienti dal filesystem Hyppocampus.
Ma spero che la squadra di Gnome corra al piu' presto ai ripari, stendendo nel caso una versione 3.0 della loro HIG che comprenda anche indicazioni sull'utilizzo dell'offscreen rendering.

mercoledì 28 novembre 2007

del.icio.us

0 commenti
Tra i miei alti e bassi nell'approccio alle tecnologie "sociali" offerte dall'odierno Web, solo oggi ho scoperto del.icio.us .
O meglio: conoscerlo lo conoscevo gia', ma oggi ho fatto il grande passo di registrarmi un account. Ho iniziato a popolarlo con i miei bookmarks e qualche link pubblicato in passato su questo stesso blog, ed ammetto che in fondo non e' male.
La cosa che piu' in assoluto mi ha stupito e' stata la gestione dei tags: osservando come sono usati su questo sito, ovvero in modo "sensato", mi rendo conto che essi hanno davvero una qualche forma di utilita'. Come vuol dire "sensato"? Vuol dire che il form per l'inserimento di nuovi links e la modifica di quelli esistenti aiuta l'utente a selezionare tags che gia' sono stati assegnati ad altri elementi personali, oppure allo stesso elemento ma da altri utenti, ed in tal modo si riesce ad evitare dispersione e frammentazione dell'informazione. Che e' il rischio piu' grosso nella categorizzazione a tags.
Senza contare che sto' del.icio.us e' davvero ricco di contenuti: sono andato a curiosare nelle pagine di coloro che avevano come me bookmarkato URL scarsamente popolari, ed in breve ho scoperto perle nascoste come questa qui. Il fatto di far organizzare i riferimenti dalle persone risulta ottimo per indicizzare con precisione pagine che altrimenti si perderebbero nel marasma della Rete ed ignorate dagli spiders dei motori di ricerca, e seguendo le catene di tags che legano una pagina con l'altra ci si trovano risultati spesso inaspettati.
Imperterrito continuo a pensare che, in ambiente desktop, i tags non servano a nulla, ma appunto perche' sul desktop l'utente tagga i files suoi secondo i suoi criteri e null'altro: l'unico modo per trarre profitto da questo meccanismo di organizzazione e' la collaborazione e la condivisione.
Il tagging funziona solo sul Web.

lunedì 26 novembre 2007

Back on SVN (?)

0 commenti
Due minuti fa', colto da ispirazione, ho iniziato a meditare sul fatto di tornare ad usare il controllo di versione su SourceForge per Hyppocampus.
O meglio: iniziare a farlo.
A suo tempo iniziai ad usare il CVS per BrainTop, da lungo tempo non piu' aggiornato (non essendo piu' il componente mantenuto, almeno per ora e per molto tempo ancora...) e lasciato in condizioni disastrate, ma lo feci in un tempo in cui sapevo a malapena cosa fosse il controllo di versione.
Di acqua sotto i ponti ne e' passata: SVN lo uso regolarmente a lavoro, e sinora ho gestito i repository localmente nella mia LAN domestica (piu' con finalita' di backup che altro); solo recentemente ho preso a sfruttare lo stesso servizio su Savannah (per Synapse) e GNA (per SCD), giusto giusto in tempo per lasciarli da parte e sviluppare Hyppocampus 0.3, e forse e' tempo di utilizzare questo potente strumento regolarmente.
Ammetto di essere un pessimo utente di SVN, tendo ad usarlo con lo scopo di mantenere una copia ridondante del mio codice piu' che per fornire una versione sempre aggiornata (ma quantomeno corretta) del software ed ho l'update facile, ma vedro' di abituarmici col tempo.
Domani ci pensero'...

sabato 24 novembre 2007

Well-formed data

0 commenti
Bazzicando per la Rete ho trovato poco fa' questo grazioso sito, a prima vista mantenuto da un tot di ex-studenti del nord Europa con il pallino per la semantica e l'organizzazione dei dati. Nonostante il termine "semantico" sia a tutt'oggi l'ennesima buzzword usata ed abusata (nel giro di pochi mesi la sentiremo nominare tanto spesso quanto "2.0" adesso...) queste pagine offrono quantomeno qualche originale spunto di riflessione.
Le demo proposte (oltre ad essere spettacolari :-P ) fanno toccare con mano i risultati di una accurata e ponderata visualizzazione delle informazioni: con un poco di zoom e qualche linea si interconnettono i tags dei bookmarks su del.icio.us, rendendo estremamente rapida l'individuazione di contenuti di interesse, ed una serie di filtri a cascata applicati su dati solo parzialmente correlati tra loro permettono di individuare con pochi click relazioni non aspettate.
Il tipo che manda avanti il sito ha (inevitabilmente) una nutrita collezione di bookmarks, e sul sito stesso appaiono infiniti links dai titoli estremamente promettenti.
Questa scoperta casca proprio a fagiuolo: giusto ieri meditavo sul fatto che, nel momento in cui il sostrato del VFS in Hyppocampus sara' quantomeno rilasciabile (ed oramai non manca molto, abbiate fede), tocchera' mettere mano alla componente grafica di Lobotomy. E stravolgerla cosiccome e' stato per il filesystem. Finche' dovro' semplicemente wrappare gli oggetti che vengono da Hyppocampus in widgets grafici ad-hoc non sara' un problema, ma ad un certo punto vorrei fermarmi un attimo e rivedere pesantemente il modo in cui tali widgets dovranno interagire tra loro e con il resto dell'ambiente.

lunedì 19 novembre 2007

Ubuntu Home Server

0 commenti
Ho scoperto solo adesso che esiste una cosa di cui da lungo tempo vado meditando.
Ebbene si: l'alternativa Linux al Windows Home Server esiste, e non potrebbe essere altro che non una versione personalizzata di quella che al momento e' la distribuzione piu' diffusa al mondo.
Il sito di Ubuntu Home Server non mi sembra nulla di particolarmente sofisticato, e' evidente che il progetto e' giovane e scarsamente organizzato da una modesta community, ma almeno il potenziale c'e': tutto sta' in quanto i developers si impegneranno nel prossimo futuro, considerando che sinora il lavoro svolto mi sembra cosi' cosi' e tra le features correnti mancano elementi essenziali eppur facilmente implementabili (come ad esempio la cache DNS o quella per gli aggiornamenti di sistema).
L'ideale sarebbe trovare la collaborazione di qualche produttore di hardware disposto ad investire in una appliance dedicata a fungere da home server, come gia' succede per il WHS venduto su macchine HP.
Al momento sto attendendo la conferma dell'iscrizione al forum, per riversare li' qualche idea in passato avuta, appuntata e mai approfondita. Chissa' che non sia la volta buona che contribuisco attivamente ad un progetto di sviluppo serio :-P

sabato 17 novembre 2007

DBus + GObject

1 commenti
Questa sera, profittando di un poco di tempo che sarebbe andato altrimenti sprecato, ho dato una scorsa al tutorial di D-Bus e mi sono illuminato di immenso: ho capito cos'e' un proxy e come ci si puo' agganciare a signals provenienti da un GObject remoto (sfruttando il binding Glib), risolvendo (almeno in linea teorica) il problema della connessione tra il SubConsciousDaemon ed il VFS di LibHyppo e permettendo la notifica asincrona e trasparente dei cambiamenti che avvengono sul filesystem Hyppocampus.
Creo un oggetto HyppoItem, lo aggancio ad un oggetto remoto HyppoItemObserver residente in SCD, e quando una modifica all'elemento avviene viene rilasciato un segnale, cui potranno essere assegnate callbacks per l'aggiornamento della grafica o altre amenita'.
E' talmente banale che mi stupisco di non aver trovato queste informazioni prima.
Nella mia todolist aggiungo la traduzione in italiano di questo bellissimo (seppur un po' lunghetto) pezzo di documentazione, da pubblicare poi su BarberaWare, e per intanto credo che entro questo weekend riusciro' a compiere qualche passo cruciale in vista della prossima release di Hyppocampus (che gia' da troppo tempo latita...).

lunedì 12 novembre 2007

... e Android fu'

0 commenti
Come annunciato, Google ha oggi rilasciato l'SDK del framework Android, destinato a diventare (nelle speranze della societa' americana e dei suoi partner, ma anche ai fatti) un punto di riferimento per lo sviluppo di device mobile.
Questo video, tra i diversi rilasciati in queste ore ad uso e consumo dei curiosi come me, ne illustra a grandi linee l'architettura: c'e' un kernel Linux, qualche libreria presa di peso dal parco di software libero, una JVM personalizzata ed ottimizzata per gli apparati embedded, e lo stack Android vero e proprio (il quale, inutile a dirsi, e' in Java. Al momento non e' prevista la possibilita' di usare altro, si fa menzione di C++ in alcune pagine ma non ci spero proprio...). Nel pacchetto scaricabile dal sito, degno di nota e' l'emulatore, col quale giocare con il software di default della piattaforma e su cui sperimentare le proprie applicazioni.
L'API e' assai ricca, le ho dato appena una scorsa e, oltre agli elementi facilmente predicibili (classi per la gestione dei contatti, del registro chiamate, dell'interfaccia di rete...), subito mi sono balzate all'occhio curiosita' come il FaceDetector (gia' visto da qualche parte...).
Inaspettato (ma non clamoroso) il challenge destinato agli aspiranti developers, con ricchissimi premi in palio (e tanta voglia di attirare l'attenzione della community), ma precluso ai residenti in Italia (come evidenziato al fondo della FAQ), credo a causa della stessa legge per cui i proxy governativi impediscono agli abitanti del Bel Paese di accedere ai siti di giochi di azzardo... Bella fregatura...
Impressioni a caldo (ed assai superficiali): completo e largamente orientato all'integrazione delle applicazioni (come e' giusto che sia), ma poco congeniale a chi (come me) vuole avere un controllo completo del device su cui mette le mani. Sara' che sono poco avvezzo a Java e se posso lo evito se non quando merita davvero, sara' che per deformazione personale le parole "accesso al dispositivo" vogliono dire avere le ioctl() del kernel a portata di mano, mi sa tanto che torno ad attendere la release del Neo 1973 / OpenMoko con la speranza di potermici dedicare non appena ne avro' uno e contribuire a quella community: come gia' detto sul lungo termine c'e' da aspettarsi che il colosso Google avra' la meglio, ma finche' c'e' qualcosa con cui divertirsi davvero meglio tenerselo stretto ;-)

mercoledì 7 novembre 2007

Alta Conducibilita'

0 commenti
Come talvolta accade, questo post e' piu' un promemoria per me stesso che un commento rivolto agli occasionali lettori di questa pagina...
Seguendo alcuni links apparsi oggi nella roadmap per Gnome 2.22 (sempre estremamente interessante...) ho appena scoperto l'esistenza di Conduit, framework dedicato all'astrazione delle operazioni di sincronizzazione tra... qualsiasi cosa a qualsiasi altra cosa :-P .
L'idea e' quella di facilitare lo scambio di files tra diverse piattaforme, siano esse il PC, un dispositivo mobile o qualche sito Web2.0 : non mi e' ancora chiaro se la libreria sfrutta un qualche VFS esterno (faccio notare che quello proprio di Gnome e' in fase di totale riscrittura, ed anzi e' prossima la migrazione verso "gio") o ne implementa uno suo, indaghero' questa sera con comodo a casa, ma comunque la cosa mi garba e mi ricorda molto l'antico proposito (al solito, temporaneamente sospeso causa mancanza di tempo) di costruire una applicazioncina a prova di utonto che permetta di gestire i backups (e costituire una alternativa Linux based al Windows Home Server ;-P ).
E' in occasioni come questa che un po' mi sento in colpa per passare il tempo a sviluppare progetti per conto mio invece che contribuire a quelli esistenti: questo framework pare assai interessante e permetterebbe un ulteriore passo avanti verso l'integrazione delle applicazioni, elemento indispensabile se si spera di vedere un giorno software libero sui desktop di tutto il mondo e convincere il "popolo" ad abbandonare la popo' cui e' abituato, e per questo rinnovo il proposito di scrivere codice quanto piu' possibile riusabile anche al di fuori dell'ambiente Lobotomy e dare un contributo (seppur minimo) all'accrescimento dell'appetibilita' della piattaforma universale.

Il Pinguino e' mobile...

0 commenti
Tutta l'Internet ne parla, forse anche un po' a sproposito, ma la notizia e' stata tanto attesa (quanto, per molti, alla fine forse deludente) che non ci si puo' esimere dal fare un commento: il Gphone, il mitologico telefono cellulare di Google, si e' materializzato, ma non nella forma da molti attesa.
Gia' si sapeva da qualche tempo che si sarebbe trattato non gia' di un telefono cellulare ma di un sistema operativo (Linux inside) dedicato agli apparati mobile, eppure, in tipico stile Google, la conferma non c'e' stata fino all'annuncio ufficiale.
Nasce cosi' (o meglio: cosi' viene ufficialmente svelato, ma ancora non s'e' visto nulla di concreto...) Android, framework dedicato ai dispositivi cellulari promosso dalla Open Handset Alliance, consorzio formato da fior fiori di colossi del settore tra cui HTC, Motorola, (ovviamente) Google e pure, dulcis in fundo, Telecom Italia ( :-P ).
Poco c'e' da dire perche' poco c'e' ancora da vedere, almeno per ora, e l'unico spunto che offro e': come si pone questo nuovo progetto, forte del sostegno di quanti in fondo decidono il mercato, nei confronti del modesto ma completamente free e community-driven OpenMoko? C'e' da supporre che, sul lungo termine, indubbiamente il pesce grosso si mangera' il piccolo e la lotta per il controllo del settore mobile tornera' a giocarsi tra le alte sfere, ma piu' incerto e' forse il destino sul breve periodo, quando i taiwanesi si decideranno a immettere sul mercato il Neo 1973 Phase2 e fiumi di smanettoni (me compreso :-P ) si precipiteranno a sviluppare nuove applicazioni per esso e ne parleranno ad amici, parenti ed internauti (per mezzo dei rispettivi blogs).
Al momento non mi resta che attendere news da entrambi i fronti: sul Neo ancora poco si sa di certo, per Android sara' rilasciato l'SDK il 12 novembre (lo stesso giorno da cui sara' possibile acquistare un XO anche come privato ;-) ) e non manchero' di prelevarne una copia da iniziare a valutare.

venerdì 2 novembre 2007

Webness

0 commenti
Il termine "webness", su cui mi ha edotto Federica qualche giorno fa', e' l'ennesima buzzword legata al mondo del Web2.0 e vuol dire tutto e niente, ma a parer mio ben si sposa con il processo in corso sul desktop Linux (precedentemente gia' trattato), ovvero l'integrazione tra applicazioni web ed applicazioni locali.
Il dibattito a tutt'oggi vive momenti di alti e bassi, ed in casa Gnome questo e' un momento di "alto": sempre piu' spesso si sente parlare del progetto di RedHat di portare il web a piu' stretto contatto con tale desktop environment, questo e' solo l'ultimo di una lunga sequela di articoli in merito. Ed allo stesso modo, da un'altra parte, emerge il progetto Prism di Mozilla, orientato alla "desktoppizzazione" di applicativi puramente web ed al loro utilizzo anche al di fuori del browser entro cui sono solitamente relegati.
Il proposito di sfruttare (e/o riusare) componenti nati sul web anche sul desktop di tutti i giorni mi garba, e non per niente tra i miei innumerevoli progetti in coda di attesa v'e' pure qualcosa in merito, sebbene sia titubante sulla loro efficacia: da diverso tempo lo sforzo comune e' quello di integrare sempre piu' tra loro le applicazioni e fornire all'utente un ambiente sempre coerente ed in cui le informazioni possano essere usate in diversi contesti, ma come potrebbero rientrare i widgets web (per cui, notoriamente, non esiste standard alcuno ed ogni vendor cerca di essere incompatibile con la concorrenza) in tale ottica? La speranza che iniziative come l'OpenSocial di Google (destinata a fornire una API comune per i social networks) prendano piede e' forte, in quanto e' fondamentalmente inutile stare a discutere di integrazione del web nel desktop se manco il web e' integrato con se' stesso, e non resta che stare a vedere quanto esperienze di tal fatta si ripetano e siano accettate dalla community (da cui, alla fine, proviene la maggior parte di elementi web appetibili per l'utilizzo locale).

Tornando a Lobotomy: ieri sera mi e' passata per l'anticamera del cervello l'idea di lavorare a mia volta per la desktoppizzazione del web (gia' che questa e' la tendenza, e' presumibile pensare che nel giro di poco sorga una API unica per la bisogna...), ed il primo approccio sortomi e' stato quello dell'utilizzo dell'interfaccia a plugins di Hyppocampus (temporaneamente sospesa nella transazione da serie 0.2 a 0.3).
Introducendo un nuovo "tipo" di item nel filesystem (dopo il gia' esistente "contact", che astrae a foggia di file un unico contatto della rubrica) ed assegnando ad esso dimensione sullo schermo, URI di riferimento e qualche altro metadato, implicitamente viene descritto un widget web pronto per essere trattato in quanto tale e sottoposto all'utente.
Come sottoporlo? Bella domanda: un widget Kiazma ad hoc puo' bastare? Non lo so, ci devo ancora pensare...

giovedì 1 novembre 2007

Come le API col miele

0 commenti
Persevero a seguire nei ritagli di tempo le evoluzioni intorno a Leopard, la nuova release del sistema operativo di casa Apple da cui continuo a trarre ispirazione. Un giorno o l'altro vedro' di iniziare ad implementare una sorta di WebClip per Linux, sfruttando anche le nuove conoscenze acquisite su XUL e le estensioni Firefox, ma chiaramente il piu' delle idee sono destinate all'opera su Lobotomy.
In particolare questo articolo mostra una carrellata della nuova API introdotta con Leopard: come sempre il punto di forza sta nell'integrazione con i vari componenti di sistema, e moltissime sono le funzionalita' per appoggiarsi a Safari o a Spotlight o per costruire interfacce grafiche tra loro coerenti con quelle proprie del resto dell'ambiente.
Non da sottovalutare ad esempio sono chicche come quella per la notifica dello stato di visualizzazione della finestra (e' visualizzata / e' coperta / e' stato cambiato workspace), evidentemente agganciate al window manager e che permettono di risparmiare non poche risorse nell'elaborazione di grafica che magari non serve in un dato momento. Senza chiaramente menzionare la pletora di widgets gia' pronti per includere nelle proprie applicazioni funzionalita' anche assai complesse senza una riga di codice...
Mi bookmarko la pagina in vista del prossimo ciclo di sviluppo di Kiazma :-P !

domenica 28 ottobre 2007

Un VFS object oriented

0 commenti
Chi mi conosce lo sa: non sono mai stato un particolare fan dei linguaggi ad oggetti.
Ma, e questa e' una mia particolare considerazione pressoche' inedita, il design pattern della programmazione ad oggetti non mi dispiace poi troppo.
Ora che finalmente la parentesi del Linux Day e' stata chiusa (sebbene abbia ancora qualcosa da sistemare a tal merito... E debba poi tornare ad occuparmi di BarberaWare...), ho provato a riprendere in mano le modifiche iniziate due mesi addietro a LibHyppo e mi sono accorto che stavo compiendo un errore di progettazione: data per assodata la mia volonta' di portare in GObject tutte le strutture manipolate per mezzo di tale libreria, mi son chiesto "Ma perche' limitarsi a correggere le routine per il Virtual FileSystem solo per assecondare questa nuova formalizzazione? Adottiamo in toto la logica ad oggetti!".
Pertanto, da oggi (vabbe', diciamo domani... ;-P ) iniziero' a riscrivere il layer di astrazione per l'accesso ad Hyppocampus rifacendomi un po' meno all'abituale API descritta in POSIX ma sfruttando un po' di piu' le proprieta' stesse dei GObject.
Non garantisco di realizzare qualcosa di realmente ottimale (oramai si sa che il mio software difetta di particolare progettazione...), ma quantomeno un po' piu' vicino al modello object oriented pienamente supportato dallo stack Glib.
Tutto questo portera' ad una evidentente rottura dell'API, ma probabilmente non se ne accorgera' nessuno :-P

lunedì 22 ottobre 2007

Leopard Guided Tour

0 commenti
Noto (ed anche con discreto piacere) che in Apple stanno prendendo l'abitudine a fare brevi video di presentazione per i loro prodotti: e' successo per iPhone, per il nuovo iPod, ed ora per la prossima incarnazione del loro spesso amato e talvolta odiato sistema operativo: Leopard.
Sorvolando sugli aspetti esplicitamente dedicati all'utenza di bassissimo rango (l'imbarazzante parentesi sugli effettini grafici di iChat potevano anche risparmiarsela...), a prima vista il nuovo prodotto sembra essere ancora piu' integrato, e dunque potente, dei suoi predecessori; assai notevoli le interconnessioni tra il client di posta ed iCal, il calendar di MacOS, cosiccome la manipolazione dei templates per le mail (che sono una "trappola per turisti", ma comunque dall'aspetto molto grazioso).
Oltre alle features gia' precedentemente annunciate e viste, stuzzicanti sono le opportunita' offerte da un parsing in fin dei conti banale sui contenuti della posta elettronica: basta poco per individuare un potenziale riferimento ad una data ("domani", "mercoledi"...) e permettere di creare un nuovo evento nel calendario partendo da tale semplice informazione.
Come al solito io continuo ad osservare e a raccogliere spunti per Lobotomy, e come sempre Apple, checche' se ne dica sulle sue scelte politiche e commerciali, fa la differenza.

giovedì 18 ottobre 2007

[OT] Linux Day 2007 a Torino!

0 commenti
Gia' che l'appello l'ho lanciato io, inevitabile e' la mia reazione (sebbene molto fuori tema rispetto a questo specifico blog...) ;-)
Come tutti sappiamo, il 27 ottobre e' il Linux Day: in 100 e piu' citta' italiane sono previste manifestazioni ed eventi espressamente dedicati a divulgare il software libero presso il grande pubblico, e a far conoscere il Pinguino a quante piu' persone possibili.
Personalmente sono parte del "Comitato Linux Day Torino", gruppo di volontari che lavora attivamente per la concretizzazione dell'importante manifestazione ed impegnato non solo a mettere in atto il ricco programma previsto per l'edizione 2007 ma anche tutte le performances collaterali. Insieme ad infinity mantengo il blog della combriccola (pure quello!), partecipo alla mailing list, come gia' detto preparo il talk su XUL e vedro' di fornire assistenza a coloro che si presenteranno all'HelpDesk.
E' un duro lavoro, ma qualcuno lo dovra' pur fare...
Dunque: il 27 ottobre gia' sapete cosa fare, che siate nei pressi dell'ex capitale d'Italia od in qualsiasi altro luogo dello Stivale mediterraneo c'e' un linuxaro che vi aspetta ;-) !

sabato 13 ottobre 2007

Un colpo alla botte, uno al cerchio

0 commenti
Da quasi un mese non scrivo nulla su questo blog, e da molto piu' tempo non lavoro su Lobotomy. Ma non per questo il progetto e' stato chiuso!: molto piu' semplicemente da qualche tempo mi trovo *molto* impegnato con l'organizzazione dell'edizione 2007 del Linux Day a Torino, e non ho tempo di dedicarmi a null'altro.
Non mi dilungo su questo argomento, in quanto poco attinente, ma faccio notare che, per una serie di circostanze correlate al Linux Day stesso, mi son trovato "costretto" a studiare XUL, ovvero la stessa tecnologia cui mi ero ripromesso di dare uno sguardo per la concretizzazione dei concetti espressi in questo documento: per quanto ho visto sinora l'approccio adottato si presta abbastanza bene ai miei scopi, sebbene non sia forse la strada ideale da seguire. Una applicazione XUL e' estremamente prolissa, ci sono metodi assai migliori di fare quello che si puo' fare con questa metodologia, meditero' ancora in merito e faro' sapere il prodotto delle mie elucubrazioni.

Per i buongustai: a fine didattico sto scrivendo una applicazioncina XUL che nulla ha a che fare con Lobotomy e che serve a me per metter le mani direttamente sulla tecnologia (quale metodo migliore per imparare ;-) ?), in questo preciso momento ancora non e' stato pubblicato nulla ma non manchero' chiaramente di popolare la pagina del progetto con qualche abbozzo di codice prima del 27 ottobre.

domenica 30 settembre 2007

No Hack, No Cry

0 commenti
Ahime', il talk su Lobotomy all'HackMeeting di quest'anno non c'e' stato. Vuoi perche' non ho seguito piu' che tanto le fasi di assegnazione delle aule e definizione del programma dell'evento, vuoi perche' magari non e' piaciuta l'idea, vuoi perche' in effetti non m'ero manco preparato nulla ed ho preferito non "occupare" uno spazio, di Lobotomy ho avuto modo solo di accennare all'amico Mikro, uno dei pochi developers "acari" con cui ho il piacere di chiaccherare di quando in quando.
Tanto peggio, se ne parlera' nei prossimi anni (sempre che decida di continuare ad andare al Meeting...).
Ad ogni modo, all'evento pisano non son stato solo ed esclusivamente passivo (al contrario della densa coltre di turisti che ad ogni anno si presentano... Mah...): ho avuto l'onore di far da "valletto" nel corso del talk degli amici Leso e brain in merito al loro progetto di grid internazionale che vogliono mettere in piedi unendo le risorse dei vari hacklabs sparpagliati in Italia ed in Europa, la cosa non e' affatto male e spero che raggiungano qualche obiettivo (cosi' da poter attingere potenza di calcolo quando mi decidero' ad implementare e testare il modello per per l'handwritten recognization da includere in Lobotomy :-P )

venerdì 7 settembre 2007

Thinking Kiazma

0 commenti
Leggendo questo per niente nuovo ma comunque sempre interessante articoletto sul multithreading (argomento su cui mantengo alto il livello di guardia) mi son ricordato che non ho ancora menzionato su questo blog gli ultimi progressi raggiunti nella fase di ri-progettazione di Kiazma, su cui ancora sto lavorando ma per cui vengo continuamente interrotto da altri impegni.
Assunto che il toolkit di riferimento sara' Clutter, il cui widget elementare da cui derivano tutti gli altri e' il ClutterActor, Kiazma avra' le interfacce KiazmaFile e KiazmaMetadata: la prima sara' implementata da tutti i widgets destinati a rappresentare a video elementi prelevati dal filesystem Hyppocampus (KiazmaIcon, KiazmaApplication...), la seconda da tutti i widgets destinati a rappresentare singoli metadati (KiazmaNote, e tutti gli oggetti editabili creati per ogni tipo di metadato previsto). ClutterActor "liscio" sara' usato per implementare widgets di contenimento (KiazmaIconView), prettamente decorativi o con scopi legati alle funzionalita' dell'applicazione in se' (KiazmaButton).
A dirla tutta non so ancora se KiazmaFile e KiazmaMetadata saranno interfacce o widgets da cui derivare poi gli altri, la prima soluzione permetterebbe di scrivere oggetti generici (da usare in ogni contesto, non necessariamente legato al filesystem) da estendere poi in altri oggetti che ne ereditino completamente le funzionalita' ed implementino solo le funzioni descritte dall'interfaccia, la seconda permette di mascherare meglio i dettagli che descrivo sotto; devo ancora analizzare le implicazioni delle possibili opzioni, ma piu' o meno la linea sara' questa.
Tra le maggiori novita' in questo sistema ci sara' una revisione che si spinge fino a LibHyppo, libreria che include il Virtual File System per l'accesso a Hyppocampus. HyppoVFSFile (il link si riferisce alla versione 0.2.3, che non e' piu' valida) diverra' un GObject (adesso e' una semplicissima struct) ed ogni istanza sara' monitorata, col supporto di SCD, per emettere signals in caso di modifica, aggiunta o rimozione dei contenuti o dei metadati assegnati: in questo modo, intercettando appropriatamente tali signals all'interno di KiazmaFile e KiazmaMetadata sara' possibile aggiornare dinamicamente la grafica presentata all'utente pressoche' senza intervento alcuno da parte del programmatore che sviluppa l'applicazione finale, rendendo implicita nel toolkit questa funzionalita'.
Quanto sopra descritto e' ancora completamente suscettibile di stravolgimento (vedro' di trovare un poco di tempo per meditare questo weekend), ma riassume a grandi (grandissime) linee quel che si vorrebbe ottenere per la serie 0.3 della componente grafica del progetto Lobotomy.

domenica 2 settembre 2007

Predicar bene e razzolar male?

0 commenti
Rileggendo alcuni dei miei precedenti posts, soprattutto quelli in merito all'utilizzo di Clutter per la re-implementazione di Kiazma e Synapse, un interrogativo morale mi e' sorto: forse qualcuno, leggendo i miei propositi di utilizzo di una libreria grafica tanto avanzata e "sbrilluccicosa", pensa che mi sia ridotto anche io a voler sviluppare qualcosa di esteticamente bello e nulla piu'? Forse che tutte le proteste di innovazione e rivoluzione si riducono a qualche icona animata?
La risposta a questi interrogativi, qualora fossero sorti codesti sentimenti in qualcuno dei miei lettori, e' ovviamente "no": l'utilizzo di Clutter deriva da una (e piu' d'una) necessita'.
I motivi per cui ho deciso di riscrivere la mia propria libreria di widgets sono fondamentalmente due:
  • usando GTK+ mi sarebbe stato impossibile implementare l'environmental mapping ed altre tecnologie analoghe in programma per Synapse: poiche' in tali condizioni urge avere il pieno controllo dei singoli elementi che appaiono sullo schermo non e' possibile poggiarsi su una libreria che pone (legittimamente ed anzi fortunatamente) dei paletti alle manipolazioni possibili, ma e' indispensabile andare ad agire direttamente nella logica interna del sistema grafico. Indi, il fatto di riscriversi suddetto sistema grafico rispettando sin dalle fondamenta determinati obiettivi risulta addirittura piu' rapido e comodo che non compiere degli hacks di dubbia stabilita' su quanto c'e' di gia' esistente.
  • una delle parole chiave che appaiono nella roadmap del progetto Lobotomy e' "multithreading": se gia' adesso il sistema e' scomposto in piu' componenti che agiscono in processi separati, nell'immediato futuro si mira a strutturare ogni applicazione per operare quanto piu' possibile in modo parallelo, con il preciso scopo di massimizzare la prestazione su quella che oramai sembra destinata ad essere l'architettura hardware con cui dovremo confrontarci negli anni a venire: il multicore. Con tale obiettivo in mente, la nuova libreria grafica sara' orientata proprio alla parallelizzazione della generazione, disposizione e visualizzazione dei frammenti grafici da presentare all'utente: ad esempio, la KiazmaIconView che proprio adesso sto sviluppando sara' in grado di ricevere asincronicamente le informazioni sui files da visualizzare, si' da costruire nel frattempo le icone finali (le quali non saranno statiche, come nei filemanager attuali, ma ponderate in funzione del result set estratto da Hyppocampus che si intende rappresentare) e operare su piu' fronti contemporaneamente.
Oltre ai bisogni sopra esplicitati, non manca naturalmente anche il desiderio di costruire qualcosa che sia esteticamente bello ed ancor piu' funzionale: il gia' piu' volte menzionato Clutter permette di approcciarsi alla creazione di interfacce utente seguendo un paradigma completamente diverso da quanto visto sinora coi tradizionali toolkits grafici (disponendo gli oggetti non piu' a "scatole cinesi", uno dentro l'altro, come in GTK+, ma posizionando liberamente i tasselli che formano l'interfaccia nel suo complesso), sfrutta l'accelerazione OpenGL (dunque: la computazione prettamente grafica va a carico della scheda grafica, che in questo modo viene utilizzata non solo per i giochi tridimensionali ma anche nei tradizionali compiti di tutti i giorni), e viene comunque finanziata e sviluppata da una societa' (OpenedHand) che opera nel campo del mobile, dunque e' lecito aspettarsi un occhio di riguardo anche per quanto concerne la performance e l'ottimizzazione.

Ad oggi lo sviluppo di Kiazma procede assai a rilento, un po' perche' ancora mi si pongono problematiche strutturali che intendo pero' ben analizzare (in modo da non dovermi nuovamente trovare a scontrarmi con ostacoli logici da me stesso creati, come ahime' mi succede troppo spesso...) ed un po' perche' sono abbastanza preso dall'organizzazione del LinuxDay2007 a Torino: vedro' cosa riusciro' ad approntare da qui alla fine di settembre (quando, in un modo o nell'altro, qualcosa dovro' portare a Pisa...), ma e' piu' probabile che una release 0.3 di Synapse/Kiazma arrivi ad ottobre.
Stay tuned ;-)

martedì 28 agosto 2007

Lobotomy@HackMeeting

0 commenti
Dietro costrizione da parte dell'amico HS1 (diciamo che ci scambiamo reciprocamente un favore... ;-) ) ho avanzato al gruppo che gestisce ed organizza l'HackMeeting, l'annuale raduno di hackers e smanettoni che quest'anno si terra' a Pisa il 28-29-30 settembre, una proposta per tenere un talk su Lobotomy. Il post apparso nella mailing list del coordinamento (girato a mio nome dall'amico acaro DW) ha riscosso un modesto ma pur sempre confortante apprezzamento, indi credo proprio che mi tocchera' inventarmi qualcosa da presentare al pubblico pisano alla fine del prossimo mese...
Per facilitarmi le cose ho assunto di tenere un seminario sugli strumenti di indicizzazione orientati al desktop presenti e futuri (dal classico Beagle di Gnome al prossimo Strigi di KDE) e di incastrare nel discorso il mio progetto, che vagamente e' assimilabile allo stesso concetto (sebbene l'approccio sia radicalmente diverso): certamente non posso permettermi di confabulare per una intera ora su qualcosa che ho ricominciato da poco a scrivere da principio e che anzi e' ancora in fase di (perenne) progettazione, per cui non esiste nemmanco uno screenshot abbozzato, sarebbe forse un tantino presuntuoso pretendere di interessare un gruppo di persone con qualcosa che non esiste se non nella mia testa, pertanto vedo di contestualizzare l'argomento su tematiche di piu' ampio respiro e che gia' adesso sono alla portata dell'utenza (Tracker, uno dei tanti indexers, verra' ad esempio immesso nella prossima release di Ubuntu e sara' da subito fruibile a tutti).
Ancora non so in quale dei tre giorni mi tocchera' presenziare (spero non proprio venerdi, forse sabato), ma vedro' di tenere aggiornato questo blog man mano che la cosa verra' definita.
Ci vediamo a Pisa ;-)

domenica 26 agosto 2007

Split to Integrate

0 commenti
Pubblicato un nuovo documento "informale" sul sito di Lobotomy, dove viene descritta (molto sommariamente...) l'architettura che si intende implementare nelle prossime fasi dello sviluppo (soprattutto di Synapse).
Buona parte del concetto nasce dall'intuizione espressa nel precedente post su questo blog, arricchita pero' da una visione di insieme piu' approfondita e ponderata.
So che avevo promesso un documento sull'approccio che verra' adottato per la costruzione della componente grafica vera e propria di Lobotomy, ma... Ci son da fare i mockups, e sono pigro :-P . Per non parlare del fatto che ho iniziato solo ieri a riscrivere from scatch Kiazma, con l'intento di ricostruire lo stack di widgets (magari non per intero, ma buona parte) gia' presente in GTK+ ma usando Clutter (e non GDK) come fondamento: sara' un lavoraccio, ma questa opera colossale mi permettera' sia di avere totale controllo dell'intero set di elementi grafici che verranno poi usati in Synapse (che a sua volta andra' riscritto) e nelle applicazioni XSLT che rappresenteranno il pool applicativo del desktop environment intero che di sfruttare i gradevolissimi effetti messi a disposizione dal canvas sviluppato da OpenedHand.
Insomma: le idee ci sono (e pure tante! Troppe!), il tempo e' sempre quel che e'. Prima di vedere anche solo una minima parte del sistema descritto nel documento linkato in apertura ne passera' di acqua sotto i ponti...

venerdì 24 agosto 2007

Tutto e' un metadato!

0 commenti
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...

venerdì 17 agosto 2007

Hyppocampus 0.3rc1

0 commenti
L'ho detto (pochi minuti fa', oltretutto) e l'ho fatto: la release 0.3rc1 di Hyppocampus e' ora disponibile dalla solita pagina su SourceForge!
Alla fine ho deciso di numerare questo pacchetto come "release candidate 1" perche' alcune cose devono ancora essere completate (e magari anche testate in modo decente...), e soprattutto per permettere agli altri componenti di Lobotomy di passare nello stesso momento alla nuova serie e tenere allineate le versioni.
L'unico grosso problema di questa release e' la modalita' di compilazione: avendo Hyppocampus come dipendenza il SubConsciousDaemon, ma non essendo il SubConsciousDaemon aggiornato alla stessa versione, la costruzione di questo particolare componente viene ostacolata dagli headers che in LibHyppo non tornano. Lo so, e' un delirio, ma la build di Lobotomy e' sempre stata un delirio: vedro' di mettere a posto al piu' presto (magari con la release 0.3 finale?) le cose, magari fornendo uno scriptone unico che esegua in maniera automatizzata il soddisfacimento delle dipendenze cicliche scaricando i pacchetti adeguati ed installandoli nell'ordine corretto.
Insomma: scaricate, e leggete la documentazione che ho scritto con tanto amore (e nel mio solito inglese funambolico...) in merito ai criteri di funzionamento del sistema.

UPGRADE: il pacchetto su SF e' stato or ora aggiornato per due motivi.
Innanzitutto e' ora possibile compilare SCD 0.2.3 con LibHyppo 0.3rc1 (ho dovuto spostare qualcosina, ma solo in via temporanea!), e dunque almeno uno dei tanti problemi della procedura di build e' stato sistemato.
E poi, cosa forse anche piu' importante, ho corretto il file di licenza allegato al pacchetto: negli headers di tutti i files avevo riportato che il software era sotto GPLv3, mentre il COPYING allegato risultava ancora fermo alla v2 :-P . Ebbene si: Hyppocampus (e tutti gli altri componenti in Lobotomy) passa alla distribuzione GPLv3; questo progetto e' sempre stato (e sempre sara') fondato su software libero, qualche tutela in piu' da parte della nuova licenza non puo' che essere gradito.

Click!

0 commenti
Nel delirio indotto dall'eccesso di lavoro (son tre giorni tre scrivo la documentazione e ritocco Hyppocampus 0.3 in vista dell'imminente release, che spero di far avvenire oggi, e che intanto leggo tutto quel che mi capita sull'Internet... L'estate mi fa male...) ho ceduto al richiamo del Web2.0 ed ho giocherellato un poco su Flickr, la nota community di photo sharing (ma che lo dico a fare? Posso facilmente immaginare che tutti sappiano cosa sia Flickr...).
Ho registrato un account a nome del progetto Lobotomy ed ho caricato la mia prima immagine (scattata col cellulare... I miei mezzi multimediali sono assai limitati...), assai rappresentativa del mio stato attuale.
Mi garba l'idea di utilizzare questa nota piattaforma per l'implicita promozione di Lobotomy: il solo fatto che da quella community passino milioni di utenti e' gia' una garanzia di visibilita'; per questo da oggi tutte le foto (e, in maggior misura, gli shots) riguardanti Lobotomy saranno accessibili da questa pagina, ad uso e consumo sia del mio pubblico che degli occasionali passanti (ovviamente i thumbails saranno sempre visibili anche dalle pagine incluse nel sito principale del progetto).
Allo stesso modo in cui un di' mi decidero' a condividere col mondo i video che vorrei realizzare con i componenti di Lobotomy in azione sull'account or ora registrato su YouTube.
Evviva il Web2.0 :-P

mercoledì 15 agosto 2007

Come eravamo, come siamo

0 commenti
La notizia di oggi, pigro ferragosto dal clima primaverile (alla faccia del riscaldamento globale!), e' che Gnome, quello che probabilmente e' il desktop environment piu' amato sul panorama freesoftware, compie 10 anni. E la pagina piu' linkata e', ovviamente, quella che riporta il primissimo annuncio ufficiale della nascita del progetto.
A seguire, un'orgia di felicitazioni e complimenti (cui mi aggiungo pure io, ci mancherebbe!) a questa longeva opera, che nel corso degli anni e' cresciuta a dismisura (basta dare uno sguardo alla lista di documentazione prevista per la piattaforma) ed ha segnato il passo dell'evoluzione del desktop computing su Linux. Ad oggi, anche grazie alla virale diffusione di Ubuntu, questo e' l'ambiente grafico piu' utilizzato dagli utenti pinguineschi (e non solo).

Ma...
Dando uno sguardo a certi screenshots pubblicati insieme a qualche commento particolarmente zelante in giro per l'Internet, la mia perplessita' cresce: stando alle immagini, Gnome e' passato da questo a questo.
Cosa e' cambiato in dieci anni?
Niente.

Per la carita': incredibili progressi nella presentazione grafica, mucchi di funzionalita', applicazioni integrate le une alle altre (piu' o meno...)...
Ma, ai fatti, nell'arco di due lustri (un'era geologica, in campo informatico) la minestra e' sempre la stessa: la barra con il taskmanager, i menu dei programmi, le finestre, le icone. Sempre loro, sempre nello stesso posto, magari con qualche colore in piu' ed una maggiore risoluzione.
Il numero di informazioni che ogni giorno un qualsiasi utente domestico si trova a manipolare e' esploso, la potenza computazionale messa a disposizione e' incrementata seguendo un'andamento esponenziale, l'insieme di possibilita' e' una composizione ortogonale tra questi due fattori.
Eppure la barra con il taskmanager, i menu dei programmi, le finestre e le icone sono sempre loro, sempre nello stesso posto.

Non a caso e' nato il Progetto Lobotomy: per sperimentare qualcosa di nuovo. Qualcosa studiato (almeno nelle intenzioni) da zero, non l'ennesima implementazione dello stesso sistema ma orientato ad una nuova prospettiva del desktop.
Quale sia questa prospettiva, sinceramente non lo so neppure io: come ho sempre sostenuto, Lobotomy non ha la pretesa di diventare il desktop environment del futuro; molto piu' semplicemente (ed umilmente) qui si sperimenta, spesso pure a casaccio e senza particolari obiettivi (i quali, si sa, diventano obsoleti nel giro di sei mesi), idee del qui presente maintainer o carpite su un blog o da qualche altra parte.
Giusto ieri ho iniziato a stendere un documentuccio (preannunciato molto vagamente nello scorso post) su quello che ci si aspetta dal prossimo BrainTop, sul quale ricomincero' a lavorare (dopo piu' di un anno!) dopo aver terminato l'ennesima revisione della gerarchia dei widgets previsti in Kiazma: li' si troveranno in buona sostanza una gran parte dei principi sui quali si intende fondare lo sviluppo di Lobotomy (almeno, della sua componente grafica) nei prossimi mesi.
Dopodiche'... Chi vivra', vedra'...

martedì 14 agosto 2007

Copione!

0 commenti
Amo l'idea della condivisione delle idee :-) .
Nel giro di un paio di giorni, attraverso links e blogs (e per di piu' in maniera praticamente casuale, senza premeditare ricerche specifiche), ho trovato belli che implementati un paio di frammenti di codice cui andavo meditando da tempo e che avevo appena aggiunto nella lista di TODO per Kiazma: per la gestione delle liste con l'attrito, simpatica feature piu' volte menzionata su questo blog e trovata implementata nel codice SVN di OpenMoko, e per la costruzione di insiemi di icone sensibili al passaggio del mouse (come nella dockbar di MacOSX, per capirci) abbozzata dall'instancabile MacSlow nel suo curioso blog (che consiglio a tutti: spesso ci si trovano hacks affascinanti applicati alle piu' avanzate tecnologie grafiche disponibili!) e che intendo utilizzare in un modo che al momento non ho avuto modo di descrivere al mio pubblico ma per cui al piu' presto vedro' di stendere una paginetta informale.
Ammetto di aver sempre preso dall'Internet frammenti di codice sparso, GPL o public domain, un po' per pigrizia ( ;-) ) un po' per effettiva ignoranza nei confronti di certe possibilita' offerte da molte librerie che pure uso spesso (GTK+ in primis), ma trovo che ultimamente (gli ultimi mesi) il proliferare di tali spesso interessanti e comunque innegabilmente utili perle sia cresciuto in buona misura: gli stimoli creativi (e competitivi) offerti dalle interfacce di iPhone, Windows Vista, MacOSX et similia inducono alcuni tra i piu' capaci hackers in circolazione (tanto per menzionarne uno tra quelli che tengono alta la bandiera italiana nel mondo: Emmanuele Bassi) a stupirci di quando in quando sia con implementazioni a codice aperto delle stesse funzionalita' che si vedono nei prodotti commerciali che con ottimi esercizi di stile che con interi progetti orientati al visibilio sia degli utenti che dei developers (cfr. Clutter).
Se nei prossimi tempi vedrete procedere il Progetto Lobotomy in modo piu' spedito (lo spero fortemente!) sara' anche per la mia (buona o cattiva che sia, dipende dai punti di vista) tendenza al copia&incolla.

sabato 11 agosto 2007

Quelli che... 0.3!

0 commenti
Piccolo aggiornamento sullo stato dei lavori in corso in casa Lobotomy: il ritardo accumulato in attesa per la prossima release e' consistente, ma mi giustifico dicendo che sto riscrivendo pressoche' daccapo Hyppocampus.
Il cambiamento piu' importante si nota nel fatto che il sistema di indicizzazione interno e sviluppato from scatch e' stato deposto in favore dell'utilizzo di DBI per l'utilizzo a mo' di backend di tutti gli RDBMS di cui esiste un driver: attualmente sto lavorando solo su PostgreSQL, forse faro' in tempo a testare anche su MySQL, mentre rimando al piu' prossimo futuro possibile il supporto a SQLite (che richiede qualche attenzione in piu', ma e' indispensabile qualora si volesse portare Lobotomy su piattaforma embedded).
So perfettamente che gia' poco tempo fa' avevo insinuato che non avrei usato alcun database esistente a causa dei grossi ostacoli che si ponevano nell'utilizzo di un RDBMS classico nella prospettiva di Hyppocampus, ma nuove strade si sono aperte da quando ho introdotto l'utilizzo di un parser scritto in bison/flex : fondamentalmente, adesso le query sono convertite dal modello logico che implementa il filesystem (una tabella con 2^64 colonne ed una riga per ogni elemento che vi si trova) a quello implementato nel DB vero (una tabella con 3 sole colonne, ed un insieme di righe per ogni file), in modo da preservare la facilita' di interrogazione da un lato e la compattezza dello storage dall'altro. Ricca documentazione accompagnera' questo complesso (almeno all'apparenza, ma non nella realta') meccanismo di trasfusione relazionale ;-) .
Le modifiche (sia esplicite, che introdotte implicitamente dalle nuove possibilita' offerte dalla disponibilita' di una base dati vera e propria su cui poggiarsi) sono tali che ho deciso di saltare direttamente alla serie 0.3 dello sviluppo, almeno per quanto riguarda Hyppocampus: con sommo dispiacere dei miei fans ( ;-P ) la nuova release del filesystem piu' relazionale sulla piazza non sara' accompagnata dalle relative versioni di Synapse e di SCD, ed anzi (questo vale in particolare per Synapse) a causa di piccoli ritocchi nelle modalita' di interrogazione SQL verra' a mancare pure la retrocompatibilita' con i prodotti esistenti. Vorrei cogliere l'occasione del salto di serie per fare grosse modifiche anche sugli altri progetti coinvolti in Lobotomy, ma cio' richiedera' (ulteriore) tempo e non mi sento di prometter nulla fino a settembre (sebbene in questo momento e per le prossime due settimane saro' in ferie dal lavoro, e potro' dedicare quasi ogni giorno al coding estremo in assetto estivo ;-) ).

venerdì 3 agosto 2007

CoreObjects

0 commenti
Su OSNews, uno dei miei portali di informazione preferiti, trovo un articolo concernente il Progetto Etoile, di cui gia' avevo letto qualcosa ma che solo ora va a rientrare nella mia personale cerchia dei "progetti da seguire da vicino".
Tale progetto ha scopi comuni (e pure scopi divergenti) rispetto a Lobotomy: l'intento dichiarato e' quello di costruire un nuovo paradigma di desktop, sebbene ad oggi da codesta opera ho visto solo graziose idee comunque sviluppate in una prospettiva WIMP.
Nell'articolo si parla di una (almeno, sulla carta) interessante tecnologia che permetterebbe di facilitare l'accesso ai files: nulla di nuovo sotto al sole, semplicemente il proposito e' quello di svincolare le applicazioni dalla gestione diretta degli elementi sul filesystem (e, piu' generalmente, dalla gestione degli errori relativi ai failures piu' hardware che software) aggiungendo un (ennesimo) strato di astrazione, ma taluni passaggi del brano hanno stuzzicato la mia fantasia.
Ad esempio, al fondo si accenna alla possibilita' di astrarre non solo i documenti ma le loro singole proprieta', in modo da salvare permanentemente (e/o trasferire attraverso una rete) solo quelle ed avere implicitamente la trattazione del versioning del materiale (chiaramente, la prima cosa che mi viene in mente pensando a "proprieta'" e' "metadato" ;-) ), e si fa riferimento pure ad una tecnologia Apple che astrae i tipi di informazione (sembra fatto apposta per questo :-P ).
Spero che i ragazzi di Etoile ottengano qualche buon risultato dalla loro analisi, e non e' detto che un giorno (come gia' mi e' passato per la testa) non li contatti per lavorare insieme su quello che in fin dei conti e' un obiettivo comune.
Per intanto (giusto per tranquillizzare coloro che frementi attendono la prossima release del sistema Lobotomy, in mostruoso ritardo) io sto lavorando su una pressoche' totale riscrittura di Hyppocampus... Maggiori dettagli a seguire ;-)

giovedì 2 agosto 2007

Clutter

0 commenti
Per quanto continui a sostenere i pensieri espressi nello scorso post su questo blog, mi rimangio il proposito di adottare GTK (quantomeno nella versione "liscia") per l'implementazione delle prossime features "avanzate" nei vari componenti grafici in Lobotomy: per quanto giusto oggi sia riuscito ad ottenere un primo prototipo di lista "scrollante" a la iPhone, esistono metodi ben piu' raffinati ed efficienti per ottenere certi risultati.
Poco fa' ho scaricato e compilato il codice dall'SVN del progetto Clutter, e ne sono rimasto affascinato: nei files di esempio, con poche righe di codice C (alla faccia di chi propugna Python o altre amenita': non e' il linguaggio che conta, ma la competenza ed il buon senso del programmatore!) si ottengono risultati piu' che ragguardevoli (ed in alcuni casi a dir poco strepitosi), con tanto di animazioni, rotazioni di immagini, trasparenze, prospettive e quant'altro, il tutto accellerato in OpenGL ed integrabile con GTK.
Guardando poi questo video (reperito sul blog del progetto) la prima cosa che ho pensato e' stata "Enter the Matrix" ;-P
Devo fortemente rivedere i miei propositi per il futuro di Lobotomy: assunto che ancora molto ho da lavorare sulla parte "non visibile" (la stesura del nuovo parser di Hyppocampus procede, a rilento ma procede) del sistema, alla luce delle tecnologie che oggi vengono proposte (e delle possibilita' offerte, tendenti ad infinito) non si tratta solo di includere qualche simpatico effetto grafico alle applicazioni, ma di stravolgere il modo stesso in cui l'informazione viene sfogliata, contestualizzata e visualizzata.
Nei prossimi giorni avro' molto su cui meditare...

sabato 28 luglio 2007

Smooth Scroll

2 commenti
Ispirato da questo paragrafo della pagina dedicata alle discussioni sull'interfaccia di OpenMoko, da un paio di giorni medito in merito all'implementazione, per mezzo di GTK+, di qualche routine per facilitare la realizzazione di interfacce che usino pesantemente lo "smooth scrolling": questa tecnica permette, a parer mio, di ottenere (senza neppure troppo sforzo) interfacce gradevoli ed allo stesso tempo estremamente usabili e funzionali, soprattutto su devices portatili (come appunto OpenMoko) che spesso e volentieri vengono manipolati con una mano (ed un dito, il pollice) sola. In particolare, mi riferisco alle liste "con l'attrito" di iPhone, e al carousel con cui vengono visualizzate le immagini.
In breve, lo scopo e' quello di ottenere dei widgets (nella fattispecie, dei GtkContainer. O anche uno solo, derivato da GtkViewport) che prevedano callbacks per la gestione della pressione, il rilascio e lo spostamento del cursore sul monitor, si' da scorrere il contenuto in funzione dell'intervallo di tempo ed il percorso e dunque della "velocita'" impressa al cursore stesso. Lo spunto da dove iniziare con il codice me lo ha fornito il client IM un tempo conosciuto come Gaim, che gia' da tempo implementa (pur sfruttandolo in minima parte) lo smooth scrolling, mentre la parte prettamente matematica del sistema trova una ricca risorsa in questa lista di algoritmi belli che pronti per essere adottati in circostanze diverse.
A breve spero di avere tempo per affrontare la problematica e scrivere una test suite, per poi includere in Kiazma il risultato della ricerca...

giovedì 19 luglio 2007

Alla faccia dei brevetti...

0 commenti
Mentre in Europa si torna a parlare di brevettabilita' del software (meglio tenere sempre le orecchie ben tese...), quel gran calderone di menti, a volte ingenue e a volte geniali, che e' l'Internet continua a sfornare spunti e proposte per piccole e grandi innovazioni.
Stasera mi son trovato a scorrere la wishlist e la lista di propositi all'interno del wiki del progetto OpenMoko (che continuo a seguire con interesse), ed ho trovato innumerevoli idee da applicare al campo embedded (e non solo) che quantomeno meriterebbero di essere valutate. Ammetto di non aver neppure finito di leggere la lunga pagina, cosiccome a suo tempo non finii di leggere la lista di idee apparse su KDE-Look in merito alle aspettative del piu' volte menzionato KDE4, ma mi riprometto (e me lo appunto apposta su questo blog ;-) ) di riprendere in mano suddetti collettori di creativita' e lasciarmi ispirare quanto piu' possibile.
Come mia abitudine tendo ad evitare gli oziosi "paradigmi" di ceppo accademico, secondo cui una soluzione sarebbe meglio di un'altra solo in virtu' di incomprensibili funzioni matematico/esoteriche, strizzando invece l'occhio a coloro che pongono soluzioni reali a problemi reali, miscelando nella propria intuizione l'esperienza di utente ed una buona dose di buon senso.
Lobotomy e' sperimentazione, dunque... sperimentiamo ;-) !

lunedì 16 luglio 2007

Suonala ancora, Sam

0 commenti
Negli ultimi giorni ho preso una decisione cardinale: riscrivo l'engine di Hyppocampus.
Da notare che preciso il fatto di voler riscrivere la parte di risoluzione, ovvero il pezzo di codice che riconduce dalla rappresentazione interna della query al result set, non il parser (che sarebbe quello che porta dalla query in forma testuale alla rappresentazione interna): l'obiettivo e' rivedere pesantemente anche quello, ma l'opera non e' realizzabile se prima non si formalizzano meglio gli internals con cui i dati vengono gestiti.
Questa decisione e' presa alla luce del fatto che, allo stato corrente, tale porzione (che del resto comprende quasi la meta' dell'intera applicazione) non e' stata preventivamente studiata per essere espansa e supportare nuove funzionalita', ed oggi, che vorrei introdurre l'indispensabile trattamento di selezioni multiple e la clausola ORDER BY nelle query avanzate al filesystem, dovrei aggiungere parametri su parametri alle gia' sufficientemente incomprensibili routines interne per ottenere il risultato sperato.
Indi: apro un nuovo file, recupero il recuperabile (il parser testuale, appunto, e qualche algoritmo sparso), formalizzo tutti i dati in strutture che innalzino in grado di astrazione delle informazioni manipolate e ne rendano piu' comprensibile l'utilizzo, e ci lavoro su. Per questo, dubito che prima di agosto si vedra' una nuova release del filesystem correntemente "piu' relazionale" della piazza ;-) .

Profitto dell'argomento per esprimere un inciso per tutti coloro che piu' volte mi han chiesto perche' non uso una base relazionale esistente per mantenere i dati e persevero nel volerne scrivere una da me: il punto sta nel fatto che, di per loro, un database ed un filesystem sono assai diversi, e tradurre la sintassi di accesso ad uno nella sintassi dell'altro e' un lavoro persino piu' complesso che non la riscrittura di uno dei due componenti in tale ottica. Volendo creare una tabella di database secondo l'attuale struttura logica di Hyppocampus essa dovrebbe avere 2^64 campi, uno per ogni metadato possibile (essendo mappati su 64 bits), e la maggior parte della tabella sarebbe comunque vuota; volendo dividere la tabella secondo la struttura "una riga per ogni metadato" ci si imbatterebbe nella gestione della varieta' di possibili tipi di dato assegnabili a suddetti metadati (al momento: int, short, long long, [che possono anche essere unsigned], stringa, stringa UTF-8, boolean, float, char, struct, per non parlare degli altri tipi astratti...) e con un'elevazione nel grado di complessita' delle query richieste per accedere al filesystem; volendo adottare quest'ultimo approccio ma mascherando l'accesso al database secondo lo schema proposto nella prima opzione, occorrerebbe stare a tradurre ogni query da un formato all'altro, compito non banale...
Poi ci sono tutte le problematiche relative alle prestazioni (per quanto un DB general purpose possa essere veloce, una base dati appositamente studiata per compiere certi tipi di operazione se ben implementata diventa ben piu' ottimizzata e piu' rapida), alle limitazioni (i campi di un DB devono essere sempre dimensionati a priori, mentre uno degli obiettivi in Hyppocampus e' quello di permettere grandezze arbitrarie per i valori assegnati) eccetera...

Un lungo lavoro di progettazione mi attende: questa volta, tanto per cambiare ( ;-) ), vorrei studiarmi bene la situazione prima di iniziare a stendere il codice...
Stay tuned ;-)

giovedì 12 luglio 2007

In punta di penna

0 commenti
Nella lista di specifiche rilasciate oggi da IBM al mondo opensource si trova un sacco di fuffa destinata alle tecnologie web: XML, XSLT, SOAP, e tutte le altre siglette che tanto piacciono a quegli ibridi mezzo programmatori e mezzo commerciali che fanno del Web2.0 il loro pane quotidiano.
Ma, dopo una breve scorsa, almeno una cosa interessante l'ho trovata: la specifica dell'Ink Markup Language. Che e'? Un formato per rappresentare l'informazione creata "a mano", quali firme, disegnini e qualunque cosa possa essere scannerizzato o, meglio, tracciato sul monitor per mezzo di un tablet.
Ammetto di dover leggere attentamente la specifica e valutarne l'usabilita' e la completezza (nonche' l'abbordabilita'...), ma posso ben sperare di potermi fidare; in ogni caso questo materiale cade a fagiuolo: mi stavo giusto chiedendo come immagazzinare in Lobotomy i dati introdotti per mezzo dello stylus (nell'interfaccia dell'OnMouse-Shell e similari), e forse questa e' davvero la strada giusta.

venerdì 29 giugno 2007

Inevitabilmente iPhone

0 commenti
Due parole in merito al tanto discusso, amato, odiato, venerato, criticato nuovo "gadget" Apple, commercializzato oggi e di cui l'Internet inizia a popolarsi di immagini, video e quantaltro: l'iPhone.
Al di la' dell'indubbio successo commerciale che esso rappresentera' (si sa: e' cool, ha la mela Apple, non importa che costi e sia blindatissimo!) e delle innumerevoli critiche che si possono muovere alle politiche di vendita, credo che questo aggeggio rappresenti una grossa svolta nel mondo dell'interazione con gli apparati digitali: il solo fatto che sulla sua superficie non appaiano pulsanti, ma tutta l'interfaccia sia implementata su un grosso touchscreen, la dice lunga sulle implicazioni.
Tra le immagini che piu' hanno stuzzicato la mia fantasia, lo splendido widget per la selezione di date e orari (a "slot machine", in modo che sia facilmente usabile con il solo pollice), ed il video sulla tastiera virtuale con tanto di zoom sui tasti digitati e sul cursore.
Ammetto che mi piacerebbe averne uno tra le mani (sebbene qui in Europa, come al solito, arrivera' solo tra un po'...), ma, da, per ovvie ragioni sia "morali" che pratiche, l'oggetto del mio desiderio al momento e' l'altrettanto atteso (almeno nel mondo "libero") OpenMoko, l'antagonista "open" dell'iPhone che si propone con lo stesso approccio gia' adottato da GP2X in tema di console portatili: software libero, ambiente di sviluppo, ed infinite possibilita' di estensione. Per intanto, nell'attesa che esca (e che venga distribuita la seconda versione, si' da evitare la fase preliminare di debug dell'hardware...), mi sa che a breve scarico l'SDK... ;-P

giovedì 28 giugno 2007

Ciak. Motore. Azione.

0 commenti
Piccolo post per segnalare (ed appuntarmi il fatto ;-) ) che, nella mia infinita ignoranza, ho appena scoperto l'esistenza di questa graziosa applicazione (ovviamente gia' pacchettizzata Debian) che permette, con un paio di click, di registrare in forma di video quel che appare sul monitor.
Utilissima, comodissima e facilissima, credo che prossimamente pubblichero' sul sito del Lobotomy Project qualche simpatica ripresa del mio desktop e (soprattutto) di Synapse ed Hyppocampus ;-)

mercoledì 20 giugno 2007

KDE copia Lobotomy (o viceversa?!)

0 commenti
Al di la' del titolo di questo post, ovviamente ludico, vado qui ad evidenziare il curioso fatto che una idea proposta nel recente passato su questo blog si trova gia' nella roadmap di uno dei componenti del piu' volte menzionato KDE4, Akonadi: leggo qui 'That said, there are parts of Akonadi that integrate very well with Qt and KDE. In particular, it has support for very smart copy/paste and drag/drop for applications that want to deal with data stored in Akonadi. If you drag the name of a contact, for example, into a text file, you'll get their name since that's the only format that a text file can understand. If you drag it into a calendar, the calendar can easily recognize that it is accepting a drop of a contact, and could conceivably ask you if you'd like to make an appointment with this contact, etc.'.
Sostanzialmente l'obiettivo e' quello di astrarre i dati scambiati tra una applicazione e l'altra, eventualmente convertendoli in qualcosa di coerente con l'informazioni di partenza ma compatibile con l'applicazione di arrivo di un drag'n'drop. Esattamente come proposto tempo addietro nel post sopra linkato e, in tempi piu' recenti, in un piu' ricco documento pubblicato sul sito di Lobotomy!
In ogni caso, sempre nello stesso articolo leggo anche 'The libraries support this level of integration, but it may take a while for the applications to take full advantage of it.': ovviamente ci vorra' del tempo prima di vedere questa tecnologia effettivamente usata, vuoi perche' posso facilmente immaginare che il team di KDE stia ancora lavorando sull'API vuoi perche' occorrera' poi mettere d'accordo gli svilupatori di un bel numero di applicazioni per usarla. Ad ogni modo, io procedo con la mia implementazione (la quale, almeno sulla carta, implica un maggiore livello di flessibilita' nella traslazione dell'informazione da applicazione mittente ad applicazione destinataria), vediamo chi arriva prima ;-P

martedì 19 giugno 2007

Desktop 2.0

0 commenti
Questo ennesimo articolo sui "WebOS", gli ambienti operativi fruibili con un browser ed una connessione alla rete (non necessariamente La Rete...), mi riaccende la fantasia in merito alla gia' annunciata volonta' di portare lo stesso Lobotomy sul web. Perche' e' distribuibile (nel senso di "usabile da piu' posti"), perche' gli strumenti per le interfacce web sanno essere assai piu' flessibili dei classici toolkit grafici nativi su PC, perche' e' centralizzabile (con un singolo server domestico si eseguono tutte le istanze si ambiente grafico che possono girare in una abitazione), perche' costringerebbe a studiare soluzioni "right-button-less" (poiche' la pressione del tasto destro del mouse attiva il menu del browser, non quello dell'applicazione!)...
Quel che mi chiedo e' perche', con cotanta abbondanza di tecnologie e possibilita', tutti si limitino a ricreare nel browser lo stesso approccio di interazione che usano tutti: sempre le solite finestre, sempre le solite icone, sempre gli stessi menu... Forse sono io che ancora non mi sono documentato e non ho mai scovato il progetto realmente innovativo, che offra una alternativa o almeno uno spunto, ma ad oggi ammetto che i siti che ricreano sul web la stessa interfaccia di Ubuntu o di Windows mi lascia quantomeno perplesso...
Mi sono appuntato questo grazioso articolo (non recentissimo, ma comunque offre un ricco punto di partenza) che elenca una infinita' di frameworks PHP per AJAX: considerando che nel prossimo futuro saro' costretto a lavorare parecchio con questa roba, tanto vale arricchire il mio know-how per poi sfruttarlo in Lobotomy ;-). Chissa' che un giorno non trovi (o non mi metta a scrivere io) una libreria di widgets web in PHP comodo come il GWT (il quale, bonta' sua, non e' proprio GPL...)

lunedì 18 giugno 2007

Icone Pro-Attive

0 commenti
Finalmente qualcosa di realmente interessante (oltre agli effetti speciali impressionanti quanto inutili) si vede correlato al tanto atteso KDE4!
Qui si trova qualche informazione (e qualche screenshot, e qualche video) in merito a Plasma, il componente che, nella prossima incarnazione del desktop environment piu' amato e piu' odiato sul panorama, fungera' non solo da acceleratore di fighettosita' (tra le altre cose, rappresenta l'integrazione di SuperKaramba nel resto del sistema) ma anche da collettore di piccole grandi funzionalita'.
Tra le maggiormente degne di nota (almeno fino a questo punto, e stando a quanto e' effettivamente tangibile) v'e' la fruibilita' delle icone: quelle che fino ad oggi sono state semplici immaginette rappresentanti files ed applicazioni con Plasma diventano elementi attivi, che variano a seconda del passaggio del puntatore del mouse e permettono il diretto accesso a particolari funzioni ed opzioni. Questo, che al primo impatto sembra l'ennesima trovata finalizzata al mero incremento della "wow-aggine" ( ;-P ), e' invece un ottimo (magari non intenzionale, ma pur sempre ottimo) approccio ai dispositivi pen-driven: poiche' su tali apparati e' assai scomoda la consultazione dei menu contestuali (per il semplice fatto che uno stilo non ha il tasto destro come il mouse), l'immediato accesso alle opzioni secondarie e' un fattore di primaria importanza, ed il fatto di avere a portata di singolo click l'abilitazione di operazioni avanzate aumenta drasticamente l'usabilita'.
Innovazione da tenere in considerazione e di cui seguire gli sviluppi, ed ovviamente da valutare per l'inclusione in Lobotomy ;-)

martedì 12 giugno 2007

Nella tana del Leopard

0 commenti
Come si poteva pretendere che su questo blog non si facesse almeno un cenno alla recente performance di Steve Jobs (CEO di Apple, per chi fosse appena giunto sul pianeta Terra e non lo sapesse...) al WWDC 2007? Inutile dilungarsi ulteriormente in merito all'evento in se' (tutta l'Internet ne parla, come spesso accade per le iniziative della casa di Cupertino...), ed andiamo direttamente al sodo: MacOS X Leopard.
Annunciato come una grande evoluzione del sistema operativo con la Mela, il quale e' a sua volta universalmente riconosciuto come il piu' innovativo ed usabile sistema desktop, la keynote sull'imminente rilascio ha allo stesso tempo stupito e deluso molti: niente ZFS, ma un file manager estremamente potente e flessibile; la Time Machine ridotta ad una mera funzionalita' di backup, ma lo Spotlight potenziato per l'individuazione delle funzionalita' all'interno delle applicazioni.
Assunto che una buona parte delle "innovazioni" sembra poco piu' che un pretesto per sfoggiare orpelli grafici sbrilluccicosi e di scarso interesse pratico (come del resto gia' e' accaduto con Windows Vista...), e che una ulteriore vagonata di effetti speciali fini a loro stessi e' prevista per la presentazione ufficiale di Core Animation, mi permetto di fare qui un compendio di quelli che, a parer mio e a poche ore dalla fine della conferenza che tanti clamori ha provocato e molti altri e' destinata a provocare, sembrano gli aspetti piu' interessanti dell'approccio di interazione offerti da MacOS 10.5:
  • il Quick Look e' una funzione avanzata di preview dei files: ottima l'idea di mostrare le anteprime in un frame posto in primo piano, certamente piu' comodo ed efficiente che non le striminzite iconcine cui siamo abituati
  • il gia' citato potenziamento di Spotlight, che consente ora di cercare anche le funzionalita' piu' avanzate e nascoste delle varie applicazioni, e' davvero notevole: sebbene sia deplorevole il fatto che esistano programmi cosi' complessi che non si sappia dove andare a cercare il pulsante per attivare una particolare opzione, mi rendo conto che in taluni casi (come nei software di edit grafico avanzato) non si possa fare altrimenti, dunque ben venga un supporto universalmente accessibile e riconoscibile
  • gli Stacks sul desktop sono veramente graziosi: permettono di avere a portata di mano un gruppo di files, direttamente nel docker e senza aprire il file manager. Quantomeno sembra di veloce accesso, sebbene temo non scali molto bene su quantita' crescenti di elementi... Ci hanno provato...
  • la Time Machine avrebbe potuto essere una buona idea, e sarebbe anche stato assai facile implementarla appoggiandosi sullo ZFS di Sun, ma a quanto pare non verra' sfruttata come sperato: certamente il versioning dei files utente e' da tenere in considerazione, e gia' contemplato per le futur(issim)e versioni di Hyppocampus
Al solito, nel bene e nel male Apple si rivela costante fonte di ispitazione (non a caso sono stati loro a concepire l'attuale paradigma del desktop e delle finestre...): auguro a Leopard di essere un grande successo commerciale, per intanto mi limito ad ammirare e a meditare...

sabato 9 giugno 2007

0.2.3

0 commenti
Sono infine riuscito a rilasciare la versione 0.2.3 di Synapse e di Hyppocampus, nonche' la 0.4.2 di SCD (prima o poi faro' riallineare sti' numeri...): nonostante il ritardo rispetto alla classica roadmap (cerco sempre di distribuire nuove releases con cadenza quanto piu' mensile possibile), le nuove features proposte non sono moltissime, a causa anche della immensa quantita' di tempo che sto' impiegando nel progetto precedentemente annunciato.
Ho dovuto lasciare le modifiche in Kiazma (finalizzate all'implementazione dell'environmental mapping) un po' a meta', dunque l'aspetto di Synapse e' assai peggiorato (non ci sono piu' icone, solo rettangoli neri... D'oh!), ma l'importante e' sapere che questa e' solo una fase transitoria.
Mezzo implementato il meccanismo di plugging automatico, prima introduzione delle VIEWs in Hyppocampus (e' possibile "salvare" le queries ed esplorarle successivamente accedendo al nome assegnato), numerose sistemazioni nella modalita' "shell" dell'On-Mouse Shell (ora i files selezionati in Synapse sono listati in una variabile di ambiente nella consolle che si apre nel rettangolo di selezione)...
Le cose da fare sono ancora molte. Moltissime.