DBus + GObject

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...).

... e Android fu'

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 ;-)

Alta Conducibilita'

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

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.

Webness

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

Come le API col miele

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 !

Un VFS object oriented

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

Leopard Guided Tour

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.

[OT] Linux Day 2007 a Torino!

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 ;-) !

Un colpo alla botte, uno al cerchio

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.