Edward Hervey: PiTiVi 0.13.1 : “L’Aquila Immota Manet : The eagle remains unmoved”

Dal blog di Edward Herbey viene data la notizia dell'uscita della versione 0.13 di PiTiVi:



Questa release è dedicata a coloro che hanno perso la loro vita il 6 Aprile del 2009 all'Aquila.

Troverete maggiori informazioni sui cambiamenti, i bugfixes e via dicendo nelle note di rilascio che trovate qui.

Un riassunto di questa release:

• 3 sviluppatori lavorando quasi a tempo pieno: Alessandro Decina, Brandon Lewis e Edward Hervey
• Un insano QA/usability nazifanatico che ha inondato il bugtracker con diverse questioni: Jean-Francois Fortin Tam
• Oltre 700 commit!
• Una completa riscrittura del core, nuove timeline multi-layered, audio waveforms, video thumbails
• Miglioramenti sulla velocità
  

Questa non è la fine e siamo ben lontani dall'averla raggiunta. Stiamo già lavorando sulla prossima release 0.13.2 che dovrebbe essere disponibile giusto prima del Gran Canaria Desktop Summit in luglio con emozionanti miglioramenti come: transizioni, mixing, effetti, maggiore velocità/miglioramenti nella gestione della memoria...

La gente dice che un'immagine vale mille parole... allora intuisco che un video valga un milione di parole. Jean-Francois ha creato uno screencast dove mostra le ultime feature di PiTiVi...e naturalmente è stato realizzato con PiTiVi. Puoi trovarlo in formato ogg o su youtube. Grazie Jean-Fracois!

Godetevi lo spettacolo!

Rodney Dawes: It's a Mock WOrld

Rodney Dawes ci parla sul suo blog di una nuova interfaccia per gestire i contatti:

Ho recentemente fatto menzione in un paio di occasioni che sto lavorando su alcuni mock-up di una nuova interfaccia per il contact management. Sto finalmente postando gli screenshot adesso e spero di poter risolvere alcuni dei dettagli per vedere il tutto implementato molto presto. L'idea è di fornire un'interfaccia molto semplice e delle informazioni extra riguardo all'utente, informazioni che normalmente non sono disponibili nell'interfaccia dell'agenda. Voglio anche liberarmi del concetto di avere degli "address book" che puoi gestire separatamente dalla tua lista contatti attuale che potrebbe anche avere lo stesso contatto in più posti.

Questa la semplice vista della lista dei contatti. Non sono sicuro che possa andare d'accordo con tutti i menu, o se addirittura ne debba avere. L'attuale toolbar per le voci comprende: nuovo contatto, ritorna alla lista (in grigetto al di fuori della vista) e un combo box per filtrare la lista. Il lavoro di filtraggio sarebbe basato sulla memoria nella quale il contatto si trova, i tag sul contatto, i nomi, lo status e tutte le informazioni associate con il contatto, quindi sarebbe più o meno un'interfaccia del tipo: "fai quello che intendo". Il contenuto associato con i contatti, che termina nella list view, non è completamente specificato, nemmeno il menu del contesto che dovrebbe apparire quando si fa right clic. Aprendo un contatto dovrebbe mostrare alcune animazioni carine in sequenza alla clutter e portarti verso la Contact view:

Non sono completamente sicuro su come il layout dovrebbe essere esattamente, siccome alcune cose richiederebbero lo scrolling.

Probabilmente avremo soltanto una scrollbar per l'intero canvas e un overflow verticalmente dove necessario. Qui il nuovo punto di contatto sarebbe disabilitato nella toolbar, ma penso che la casella filtro potrebbe essere utile per condensare l'informazione mostrata per un contatto. Per esempio digitare "telefono" per mostrare solo il numero di telefono del contatto. Potremmo mostrare un sacco di informazioni per un contatto, come un RSS feed, post su flickr, contatti correlati e cose simili attraverso i web services. Voglio trovare un giusto equilibrio e mostrare l'informazione più pertinente in una porzione prominente in alto nel canvas, così come ad esempio delle informazioni utili prese dall'agenda come libero/occupato, informazioni basilari sul contatto, la presenza e le locazioni dove contattarlo.

Questa UI per i contattii è una piccola parte di un progetto molto più grande di cui ho parlato con altri hackers per unire i backend e un API d'accesso, per ottenere tutte queste informazioni, per fare in modo veramente che la gente e le relazioni siano la parte principale del desktop. Ulteriori notizie verranno presto su questo argomento.

Christopher Blizzard: dailymotion and open video

Christopher Blizzard sul suo blog ci parla di una novità che riguarda Dailymotion:

Oggi Dailymotion, uno dei siti di video hosting più grandi al mondo, ha annunciato il suo supporto per l'open video. Hanno realizzato una press release, un blog post sul nuovo sito openvideo e un sito dimostrativo dove potete vedere alcune delle cose che si possono fare con l'open video e Firefox 3.5. Stanno automaticamente trasformando tutti i contenuti del loro Motion Makers e le creazioni degli Official Users e si aspettano di avere circa 300'000 video trasformati nei formati open Ogg Theora e Vorbis. Potete vedere il sito che hanno messo su andando su openvideo.dailymotion.com.

Vorrei ringraziare personalmente le persone meravigliose che lavorano a Dailymotion, insieme a Paul e Tristan che hanno permesso di realizzare questo progetto sino al punto a cui si è arrivati adesso. Dailymotion è stato un eccellente test case per noi, perché non si sono limitati a rifare i file con il formato che noi supportiamo, ma hanno anche costruito un player completo usando HTML, CSS e Javascript e che sembra comporsi come i player flash-based che vediamo oggi sul web. Hanno anche fatto in modo che sia possibile incorporare a un open video utilizzando un ingegnoso tag

Posizionandosi sui pilastri gemelli della video API di HTML5 e su codec royalty-free il movimento che vuole portare gli open video sul web è sulla strada giusta. Dailymotion insieme con Wikipedia e l'Internet Archive hanno cominciato a rendere popolare l'open video. I codec FREE stanno diventando sempre migliori col tempo e stiamo cominciamo a vedere maggiore interesse in questa tecnologia.

Dailymotion, Mozilla e un vasto numero di altri partner saranno presenti alla Open Video Conference il 19 e il 20 giugno. Se sei intessato nel parlare con noi magari potresti fare un salto alla conferenza e apprendere ciò che sta succedendo con i video sul web.

John Stowers: Playing With Clutter

John Stowers sul suo blog ci parla di Clutter:

Giocando con Clutter

Alcuni di voi saranno famigliari con Gloobus. Nelle ultime notti ho passato un po' di tempo ad integrare Gloobus dentro nautilus.



Questa è una bozza. Per il momento non ho fatto molto - mostra i primi 8 file nella directory e permette di navigare tra di loro con un'animazione. È più che altro un port dal C++ di Gloobus in un Actor in C di un ClutterGroup, la maggior parte dei ringraziamenti andrebbe fatta all'autore di Gloobus.

Soffre degli stessi bug di Gloobus, come la mancanza di supporto per ridimensionare e spostare la finestra e non scala con parecchi file. Inoltre fa acqua da tutte le parti (questo dipende da me). Ecco la mia inadeguatezza rappresentata in forma di video.

Se vi interessa ancora dare un'acchiata e magari sistemare tutti i bug i passi per testarlo sono:

1. Installare clutter-gtk-0.9
2. Scaricare nautilus dal Git repository (il branch di clutter)
   https://github.com/nzjrs/nautilus/tree
3. Creare il programma di test
   cd src/file-manager
   make -f Makefile.covflow && ./test-covflow
4. Creare nautilus con l'opzione –enable-clutter-view
5. Fare andare il nautilus appena creato
6. cd src
   ./nautilus -q
   ./nautilus –no-desktop

Questo è un lavoro molto recente così le solite avvertenze del caso sono necessarie. Sentivo proprio il bisogno di parlarvene così ora posso tornare a preoccuparmi del mio lavoro di dottorato.

Dan Williams: Face transplants are the new Botox

Dan Williams parla sul suo blog del Network Manager:

Quando stavamo aggiungendo il supporto a numerosi apparecchi sul NetworkManager 0.7, Bryan Clark e Mike Langlie hanno rifatto il design dell'applet e tirato fuori dei fantastici mock-up.
Ne è venuto fuori che GtkMenu non funziona bene con connessioni multiple o apparecchi attivi multipli. Anche se finora ci ha servito bene, l'applet basato sul codice GtkMenu dovrebbe essere mandato al macello e trasformato in gustoso grasso animale. Anche se il nuovo lavoro di design è stato fatto nel Gennaio 2008, ho bloggato a riguardo i mock-up solo nel Giugno dell'anno scorso perché faccio schifo.

Li ho tenuti nel mio computer per 18 mesi, perché tra far uscire NM 0.7, mobile broadband e tutto il resto la meravigliosità che 0.71 ha portato, non c'è stato il tempo di sedersi e attualmente rifare il design. Ma questo non dovrebbe fermare le discussioni su quanto eccellente l'NM-applet possa diventare.

Nella Stanza Operativa

Ignorate la barra del titolo. Queste sono vecchie; non vogliamo più una title-bar. Piuttosto solo un widget personalizzato come il Volume Applet. Quindi ecco qui:

L'utente ha attiva una connessione via cavo e una connessione wireless disattiva. Notare che solo la tua rete wifi preferita (es: quelle a cui ti sei collegato precedentemente) appare nella lista. La gente spesso vede 10 o 20 reti wifi e metterle tutte in lista nel menu è piuttosto inutile.
C'è stato un compromesso con la facile scoperta delle reti wifi per la prima volta, le quali adesso prenderebbero un click in più (di "Show"). Ma mostrare solo le reti che attualmente utilizzi rende la UI molto più pulita e bella da vedere per i netbook. Il nuovo design mostra anche un maggiore dettaglio, come i setting sulla sicurezza in un linguaggio chiaro.



Se hai usato una VPN con questa rete prima (o collegata a un network wifi) dovrebbe probabilmente mostrarti anche questo. Questa parte però ha bisogno di approfondimento, perché le VPN sono indipendenti dalla rete sottostante, ma spesso dovrebbero essere "collegate" a una o due specifiche connessione. Ma ciò che rende le cose corrette è raggruppare ciò probabilmente vuoi fare vicina ad ognuna.



Così cosa succede se vuoi vedere tutto? Be', premi il bottone "Show" e naturalmente ottieni la lista. Probabilmente possiamo fare meglio di una barra di scorrimento, ma comunque sono solo dei mockup. Forse possiamo fare qualcosa di più intelligente anche riguardo allo scanning.

Una Faccia Aggiornata per il 2009

Il 2008 non è il 2009. Per questo Jon McCann e io ci siamo riuniti poche settimane fa e abbiamo lavorato su cose a cui la gente tiene in questo momento. Fresco di lavagna dopo un viaggetto attraverso Gimp:

Immediatamente noterai la forte somiglianza con i lavoro di Bryan e Mike di un anno fa. A loro credito Jon e io pensiamo che gli stessi concetti chiave siano ancora validi. Abbiamo dato un'occhiata a come il mobile broadband si integrerebbe.
Abbiamo separato le icone per mostrare ogni apparecchio individualmente, nonostante anche questo richieda una maggiore riflessione a riguardo, visto che a voi non importa molto l'intensità del segnale wifi quando siete su una rete 3G. Ma vi importa quanto buona sia la tua rete 3G anche quando non siete connessi, siccome vuoi sapere se puoi saltare su 3G o no da subito. Pensieri? Commenti? Flame?

Windows 7++?

Ci ha sorpresi che Windows 7 assomiglia molto a quello che Bryan e Mike hanno abbozzato 18 mesi fa. Mooolto tempo prima di loro. Sì, i colori sono diversi e sì c'è un sacco di roba discutibile in stile Microsoft, ma il network applet di Windows 7 sembra e si percepisce molto come i mockup dell'nm-applet di Gennaio 2008. Ma penso che possiamo fare meglio, rendendo il networking più pulito e conciso. L'applet di Apple Airport è probabilmente troppo minimalista, ma quella di Microsoft è probabilmente troppo complessa. Da qualche parte nel mezzo è dove l'nm-applet stava pianificando di essere e dovrebbe essere: farti connettere con pochi passi e mettere quello che ti serve in un singolo e comodo posto.

La Semplicità di Ogni Giorno

Suona come qualcosa che Martha Stewart venderebbe al K-Mart, ma è quello a cui il software dovrebbe aspirare. Lasciamo agli utenti fare quello che gli vien da fare, poi togliamoci dai piedi e lasciamoli indisturbati. Non mostrare opzioni che gli utenti non necessitano ogni giorno, ma fare in modo che siano disponibili altrove in un clic o due. Tenere l'integrazione snella, semplice e pulita. Non complicare con opzioni non necessarie. Se una cosa non è utilizzata ogni giorno probabilmente non dovrebbe essere vista ogni giorno. Questo è ciò che la nm-applet dovrebbe fare.

Quindi facciamoglielo fare. Prototizzare i concetti in una applet in Python sarebbe un primo grande passo. Dopo aver fatto un po' di prove implementiamole in un nm-applet. Il debutto del NetworkManager 0.8 con un'interfaccia nuova e sexy renderebbe orgogliosa tua mamma. Qualcuno disponibile?

Android Full Screen on Ubuntu

Michael Frey mostra alcuni interessanti screenshot in cui fa andare alcune applicazioni di Android su Ubuntu Netbook Remix.

In un altro suo post si trovano altre informazioni. Android è stato creato per architetture x86, ma usa una sua versione di libc, quindi ha compilato il sorgente fornendo la versione che aveva in locale.
Finito di compilare funzionava, ma nel codice diverse funzionalità sono specifiche per uno specifico hardware, come ad esempio quella che controlla se l'apparecchio è acceso.

Alexandre Rosenfeld: Conduit’s improvements

Alexandre Rosenfeld ha riscritto la configurazione del sistema di Conduit, basato sulla precedente limitata implementazione che ha trovato quando ha iniziato a lavorare al Summero of Code 2008.

Ecco cosa ci racconta:

Quello che ora viene fornito è una schermata di configurazione per l'utente con la solita configurazione per i widget dove inserire il testo, drop-boxes, item-lists ecc.. e i bottoni OK e Cancella. Il problema era che ogni dataprovider aveva il suo codice Gtk e Glade, ciò significa che un sacco di codice era duplicato e con interfacce confuse, per niente HIG-compliant. Oltre a ciò ogni data provider mostrava la propria finestra di configurazione, così non eravamo in grado di fare niente altro che mostrare il la finestra. Sistemare tutto ciò significava sistemarli tutti uno alla volta.

Ho cominciato con l'idea che per essere più utili alle applicazioni esterne dobbiamo essere più flessibili e dobbiamo sistemare i nostri problemi una volta per tutte in tutte le finestre di dialogo. Sapevo che avrei dovuto cambiare ogni dataprovider che forniamo. Alla fine ho creato un wrapper a Gtk, lasciando che i dataprovider avessero solo a che fare con quello che a loro interessa. Perché abbiamo un limitato set di widget, possiamo avere un'API molto più utile allora avendo a che fare direttamente con Gtk. Otteniamo anche alcuni benefici:

* Sistemare il codice in un posto lo sistema per tutti i dataprovider.
* Essere HIG-compliant è molto più semplice
* Potremo passare da Gtk a qualcos'altro molto più velocemente in futuro
* Possiamo gestire le finestre di configurazione sui client in un modo nettamente migliore (pensate a incorporare una finestra di configurazione per sincronizzare l'ipod dentro Rhythmbox).
* Possiamo fare qualcos'altro che siano finestre di dialogo per la configurazione. Pensate a una sidebar alla Glade.

E' stato esplicitamente creato il design per gli ultimi due punti, perché il mio primo lavoro a Conduit era che il modulo iPod fornisse la stessa esperienza di iTunes per sincronizzare ed era uno dei maggiori obiettivi.

Così speravo di mostrare uno screenshot di come fosse prima, ma sembra che abbiamo sistemato così tante cose ultimamente (o ne abbiamo sbagliate così tante prima) che non riesco a fare andare la vecchia versione.

Ad ogni modo ecco qui uno screenshot del nuovo codice:




Naturalmente abbiamo cambiato un sacco di codice con gli ultimi commit e non senza creare nuovi bug. La nostra UI è ancora pessima, ma speriamo di poterla migliorare presto.

Dovrei iniziare a pensarci su a partire da questa Summer of Code. Fortunatamente avremo qualcosa di veramente buono alla fine dell'estate (il mio inverno a dire il vero).

Philip Van Hoof: Rearchitecting Tracker

Philip Van Hoof racconta i suoi piani per cambiare l'architettura di Tracker. I cambiamenti sul codice possono essere seguiti qui e qui.

Cosa è stato completato?

• Tutto il codice del database è ora fuori dell'indexer. Ora l'indexer utilizza il tracker-store. Ordina al tracker-store di immagazzinare medatadi. L'indexer ora interroga il tracker-store per cose come la data di modifica. Al momento non ha accesso al database direttamente. Questo potrebbe cambiare per ragioni di performance, ma non siamo ancora sicuri.
• Il processo trackerd è stato rinominato tracker-store
• L'oggetto DBus nel tracker-store adesso esegue da solo le richieste di SPARQL Update. È utilizzato per mandare questa richiesta al tracker-indexer.
• E' stato spostato il codice per il watching e crawling che era nel demone all'indexer. Questo significa che il tracker-store non dipende più da inotify. Questo lavoro ha reso possibile creare il proprio indexer o non avere un indexer del tutto. Questo è stato un grosso compito ed è stato realizzato oggi. Questo naturalmente lo stiamo testando al momento.
• Philip Van Hoof ha scritto una API interna per mettere in coda le store requests al database, rendendo possibile in modo asincrono il trattamento di grandi quantità di dati quando consegne multiple di metadati dratanno al tracker-store ordini per immagazzinare i loro metadati.
• Ho anche realizzato il porting del codice esistente per utilizzare questa API interna. Questo task sta procedento e lo stiamo testando. Per esempio il Turtle Import, il supporto per la cache di dispositivi rimovibili in Turtle, i moduli Push (il supporto per i client di posta) e il DBus SPARQUL Update API sono influenzati da questo.
• La classe signals, la quale adesso non richiede il coinvolgimento dell'indexer, è stata sistemata.

Cosa c'è da fare?

Al momento l'indexer istruirà un processo di estrazione per estrarre i metadati da un file. Questo processo comunica i metadati prima all'indexer, il quale rigira gli stessi al tracker-store. Questo può essere fatto in modo più efficiente lasciando l'estrattore comunicare i metadati direttamente al tracker-store.

Racetrack

Racetrack è stato progettato per archiviare e mostrare i risultati di test automatizzati.
Vmware ha già immagazzinato dentro il Racetrack Repository più di 2 milioni di test.

Utilizza un modello molto semplice con appena tre tabelle base:
ResultSet : immagazzina informazioni su un set di test (Product, Build, eccc)
Result: immagazzina informazioni riguardo al testcase stesso.
ResultDetail: immagazzina i dettagli di ogni verifica eseguita all'interno del test. Include anche gli screenshot e i file di log. Quando c'è un problema determinare le cause diventa più semplice.

L'API per i web services è già parte del pacchetto e SilkTest l'API per Java saranno aggiunte entro breve.

Il sorgente di Recetrack è disponibuile qui.