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

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.