Nel post “Anteprima: integrazione tra Nautilus e Tracker” avevo presentato alcuni possibili (e probabili, si spera) sviluppi dell’integrazione tra GNOME e Tracker per raggiungere quello che potenzialmente sarebbe il desktop più avanzato e integrato che si sia mai visto.
Una bozza dell’integrazione tra i Simboli (Emblems) di Nautilus e i tag di Tracker
Sembra che le cose procedano ad un ritmo molto promettente e che i primi risultati usabili si vedranno presto. È già possibile avere una prima integrazione tra i Simboli (Emblems) di Nautilus e i tag di Tracker.
Questo significa che possiamo ad esempio assegnare un simbolo raffigurante un libro a più file/directory, e ottenere che quegli stessi file/directory vengano contraddistinte con il tag “università”, per poi poter essere visualizzati insieme agli altri documenti con lo stesso tag grazie ad una ricerca veloce. Ma questa è solo la punta dell’iceberg…
La visione di “John Stowers” è molto più complessa e appetibile, e ce ne parla nel suo recente post “A Metadata Enabled GNOME“, in cui segnala il lavoro che ha recentemente svolto:
- Freedesktop emblem specdefinisce uno standard per l’installazione e l’uso di Simboli di Nautilus, ufficiali, di terze parti o definiti dall’utente
- Tracker Nautilus Integration. È già disponibile una patch per integrare le funzionalità dei Simboli di Nautilus con i tag di Tracker.
- libtracker-gtk fornisce un insieme di controlli GTK per permettere agli sviluppatori di sfruttare Tracker nelle loro applicazioni
Come vedete carne al fuoco ce n’è anche tanta… e sembra che tutto proceda esattamente come personalmente ho sempre desiderato sin da quando ho letto la prima descrizione di Tracker!
Se volete avere un po’ più di idee su dove tutto questo potrebbe andare a parare vi consiglio anche di dare un occhio alle pagine rilevanti del wiki messo su da John, credo che verrà aggiornato spesso :)
Sappiate comunque che esistono ancora altre idee, e ancora più sorprendenti, che circolano già da un po’ grazie a Jamie, l’autore di Tracker. Ne ho accennato altre volte ma credo che adesso tutto prenda una luce nuova: già adesso Tracker – il “motore” – è capace di fare la maggior parte dei compiti per cui è stato pensato, e spetta alle applicazioni il prossimo passo, quello di avvalersi delle nuove possibilità offerte.
Ancora oltre: la mia personale “visione”
Faccio un esempio per chiarire. Già adesso Tracker indicizza i file MP3 presenti sul nostro sistema. Ogni nuovo MP3 aggiunto alla nostra home utente dopo un download, una conversione da CD, una copia da una penna USB, eccetera… viene automaticamente rilevato, interrogato e catalogato da Tracker, che ne riconosce ed estrae i tag inclusi (artista, titolo, album, eccetera…)
Questo significa che Tracker ha già una libreria audio completa, aggiornata all’ultimo secondo, ordinabile e ricercabile con metodi semplici (ma volendo anche molto complessi) da qualunque applicazione audio che sfrutti Tracker! In questo momento sto usando Rhythmbox, che ha una sua directory contenente una sua libreria. Stesso dicasi per Amarok, stesso dicasi per Listen, per Quod Libet, per …tutti i lettori/catalogatori audio! Ognuno ha un suo database che gestisce la sua libreria, spesso in maniera incoerente e sicuramente meno efficace di Tracker.
Se sul nostro sistema proviamo tre o quattro lettori audio al mese, alla ricerca di quello perfetto (cosa per niente rara) ci troveremo facilmente con una quantità di database duplicati, inutili e per niente fruibili dalle altre applicazioni
Invece di sprecare tutto questo spazio su disco, memoria, tempo all’avvio dell’applicazione, e tempo investito a sviluppare un sistema per gestire una libreria per ogni piccola applicazione… non sarebbe ideale avere un solo indice di ricerca, quello di Tracker, e condividere le informazioni con tutti i lettori audio? Basterebbe solo volerlo, visto che – come dicevo – da parte di Tracker ci siamo già.
Bello, no? Adesso immaginate che Tracker, oltre ai file audio, gestisce e supporta appieno file di testo, immagini, video, documenti di vario tipo (OpenOffice.org, PDF, M$ Office…), e che in un futuro ormai prossimo supporterà anche contatti, email, conversazioni private, appuntamenti/calendario, segnalibri del browser… Ogni applicazione GNOME (ma non solo) potrebbe avere accesso a queste info condivise…
Cominciate anche voi ad avere la visione? :)
Già.. “Visione” è il termine adatto..
Quando si passerà all’ “Esperienza” sarò molto più soddisfatto..
Più o meno quali sarebbero i tempi per attuar tutto ciò?
Di qui ad un anno?
o più?
Le razionalizzazioni sono sempre benvenute. Ammesso che avvenga la convergenza che auspichi, una cosa carina sarebbe che i database di tracker possano finire criptati in modo semplice e comodo.
E’ facile che il coso ti indicizzi cose che devono rimanere private e sul più bello saltino fuori…
La mia proposta è:
con password vedo i database completi delle cartelle riservate
senza password solo le cartelle politically correct
Ciao
La visione di un OS Perfetto? :D
beh…è una visione stupenda!questo vorrebbe veramente dire cooperare!però ho delle domande:
-non ci dovrebbe essere comunque la possibilità di scegliere?se nn uso tracker nn posso avere il mio catalogo?se nn uso tracker ma qualcos’altro il mio prog di musica nn mi cataloga la musica?
-ma su win catalogatori simili nn ci sono già?perché questo dovrebbe dare l’esclusiva a gnome come miglior DE?
-se tracker venisse abbandonato tutti i prog che si basano su di lui che fine fanno?
Spero di essere stato chiaro..
Saluti
jak
diverrà Tracker Gnome alla fine…speriamo non MONO Gnome.. :D Cmq sarebbe splendido!
Secondo me il prossimo passo deve farlo gnome,integrando tracker,come ha gia fatto ubuntu,al posto di quell’indecenza di beagle,solo dopo i dev delle varie applicazioni potranno usarlo,altrimenti avremmo applicazioni solo per ubuntu!
@lizardking
Non capisco il tuo commento,potrebbe benissimo esserci un gnome che usa mono e tracker(come il mio) anche se presumo che questa parte discosti un po dalla visione di felipe! :D
Alla M$ hanno altri cinque anni di tempo per copiare :-D
Sono alcuni anni che penso una cosa del genere.
Su windows è un casino (windows media player e itunes per esempio con nero hanno tre database diversi!)
Avvicinandomi a linux pensavo che questo problema fosse risolto invece era peggio ancora!!!
Con i vari motori per le varie piattaforme (googledesktop, beagle ecc…) si è cercato di migliorare ma il problema persiste!
Per Windows mi pare che winFS (il nuovo filesystem perso per strada con vista!) sarebbe stata una soluzione! Con la sua uscita avevo sentito molti che dicevano che prodotti del genere (filesystem basati su logica database) su linux esistevano già (stiamo parlando di 2 anni fa) non li ho mai trovati!
Forse Tracker (con fuse) sarà finalmente la strada?
MacOSX con il suo finder non è ancora all’altezza!
Qualche idea nuova l’ho in mente
Stanno lavorando a qualcosa di simile anche per KDE?
Io sono molto impaziente di avere tracker integrato nel mio Ubuntu BOX :-)
@Fox-ino
La maggior parte dei casini in win deriva dal fatto che non aveva una reale distinzione tra la root e la home. Tuttora xp non l’ha nel senso stretto. Secondo voi “Document an Settings” è un nome funzionale? In Unix è più semplice cercare qualcosa, se si sa più o meno cosa si cerca. Però mentre con una Ubuntu qualunque questi database sono di solito in testo semplice, con win non è certo così.
Per quanto riguarda WinFS, si capiva subito che non sarebbe andato in porto! Cioè non puoi avere un filesystem che sia veloce, affidabile, sicuro e che sia addirittura un database. E per di più partendo da NTFS, che una scheggia proprio non è.
Comunque qui non si tratta di un sistema che ritrova i file, piuttosto di un sistema che permette la perfetta organizzazione della propria home.
Io credo che da qui a poco passeremo dal concetto di file-estensione-apri_con a quello di documento.
Siiiiiiiiiiii…Era da una vita che aspettavo sta funzione!Alleluja!
Spero, Felipe, che proseguano con l’attuale velocità ( se non anche maggiore! ), per portare finalmente tracker anche dentro Gnome di default.
Una cosa che mi fa pensare sarebbe la funzione auspicata da tkk, o una sua qualche implementazione parziale, per avere ricerche e “ricerche”…Anche se penso che questo esula da un normale desk search…
@jack: non capisco le tue ‘paure’…Vedi che forse hai già le domande davanti e non le vedi!Pensa al pacchetto libdeskbar-tracker…
@Fox-ino:Mentre s-vista se l’è perso per strada ( anche perchè è un progetto quanto mai pesante e preistorico ) Amarok ( che io sappia ) integra già un motore delle ricerche basato su database, solo che è sicuramente più flessibile di quello microzoz, in quanto si può scegliere al primo avvio che database usare tra SQLite, MySQL e non ricordo quale altro…Però OS X ha Spotlight ( il finder è il file manager ), che attualmente è molto indietro rispetto a tracker e agli altri desk-search di “casa nostra”!
@hronir: esiste già qualcosa del genere se non sbaglio…Ma non ti so dire…Cerca nei commenti ai post del tag Tracker su questo blog…
@felipe: Congratulations!Your english is perfect! ;D
@italyanker: Felipe qui ci mette in attesa… attendi(am)o! :)
Ciao a tutti.
Mi piacerebbe avere un opinione di Felipe per il progetto NEPOMUK-KDE (http://nepomuk-kde.semanticdesktop.org/xwiki/bin/view/Main/), che dovrebbe costruire un infrastruttura per l’uso dei metadati, che si integrerebbe con strigi in kde.
Ciao !!
@Xander:
A questo punto nessuno ha delle scadenze. Se Tracker venisse accettato per GNOME 2.19 credo che potremmo subito vedere grandi cose tra… diciamo sei/otto mesi?
In fin dei conti, Tracker è già qui. Una volta stabilizzate un po’ di cose e dato un assetto ai vari standard (come ha fatto John cominciando con la spec degli Emblems), io credo che per le applicazioni diventerà quasi d’obbligo usare le possibilità offerte da Tracker e questa nuova libreria-ponte per GNOME.
@tkk:
Tracker è completamente multiutente e indicizza solo la $HOME di chi lo lancia come impostazione predefinita. Se puoi accedere ad informazioni non protette non sarà mai colpa di Tracker che te le ha scovate, quanto tua che non le hai protette :)
@jak:
Se Tracker venisse accettato in GNOME stai tranquillo che non verrebbe abbandonato mai per “incuria”. Già adesso ci sono molti sviluppatori che partecipano attivamente, oltre all’autore
@Alx e tutti i KDE-isti:
Appena ho un po’ di tempo ho pianificato una bella chiacchierata per la categoria “Il salotto di (maria de) Felipe” con chi ne sa molto più di me a riguardo :D
@felipe:
“io credo che per le applicazioni diventerà quasi d’obbligo usare le possibilità offerte da Tracker”
è qui che ti sbagli: a meno che qualcuno finalmente non si degni di scrivere una “libtracker” per permettere agli sviluppatori di usare tracker, allora nessuna applicazione integrerà mai tracker – a meno che gli autori di tracker stesso non la modifichino e non la mantengano vita natural durante. scrivere una libreria è fondamentale – al momento tracker può essere usato solo via remote procedure call e d-bus, ed è un bagno di sangue da tanto questo approccio è orrido da fare in linguaggi che non siano python o c# (e se devo usare c# allora tanto vale che io usi beagle).
voglio ricordare che gli utenti non sanno cosa sia, come funzioni o che importanza abbia tracker: se nautilus usasse un ipotetico “Foo” al posto di tracker *nessuno* se ne accorgerebbe. sta agli sviluppatori di tracker mettere a disposizione degli sviluppatori delle applicazioni un modo facile per usare quello che hanno scritto. altrimenti, finirà nel dimenticatoio, superato da qualcos’altro.
@Emmanuele:
Mi sbaglio in che senso? Nel post ho segnalato che uno dei progetti che attualmente sta curando John è proprio:
libtracker-gtk: fornisce un insieme di controlli GTK per permettere agli sviluppatori di sfruttare Tracker nelle loro applicazioni.
Potrebbe essere quello che manca a Tracker per poter essere appetibile. O almeno il senso del post di John, e anche del mio, era proprio questo: permettere a tutti di avere un più facile accesso alle API di Tracker.
Io credo che tutti vogliamo la stessa cosa in fondo.
Chi mi chiarisce un dubbio … da qualche mese, anche gazie a felipe che me lo ha fatto scoprire, utilizzo traker e da qualche anno o forse piu’ indici generati da lucene (in forum, blog e ora anche in un motore documentale), cosi’ a senzazione (forse anche per via dell’interfaccia di ricerca no so) gli indici generati da lucene e le query mi sembram piu’ efficenti, senza voler denigrare un ottimo progetto come traker … qualcuno riesce a far una prova comparativa?? che indicizzazione usa traker … se non ricordo male qualcosa che ha a che fare con mysql ma non vorrei dire corbellerie :D
@felipe: libtracker-gtk fornisce widget – non un’interfaccia ad alto livello per tracker. non voglio widget: voglio qualcosa di simile a gconf, dove prendo un oggetto a cui chiedo valori e che posso usare per impostarne altri. widget non me ne faccio niente: non posso integrarli con progetti già esistenti se non rimpiazzando i miei (che probabilmente sono già specializzati) oppure aspettare che vengano aggiunti a libtracker-gtk.
@Emmanuele:
Già. Leggendo il tuo post mi ero reso conto che libtracker non basta, in effetti.
Credi che sarebbe sensato provare a parlare con John Stowers e tastare cosa pensa dell’esigenza – legittima – di avere delle API esposte? E di possibili termini per implementare qualcosa del genere? Al momento la sua libtracker è allo stato di bozza, quindi forse gli si potrebbe suggerire la via più accettabile per gli sviluppatori di app “reali”. Che ne pensi?
Io posso provare volentieri a contattarlo, se credi che questo possa servire a qualcosa, ma suppongo che sia un tantino differente essere contattati da uno che ha un oscuro blogghettino… piuttosto che direttamente da Mr GNOME Search Tool (tra le altre cose) :)
Per quanto riguarda KDE, ci sono info qui e qui.
Ciao!
@hronir:
A parte il fatto che sei OT… c’è pure conflitto di interessi! (quegli articoli sono miei) :D
@il conflitto di interessi: cavolo non me ne ero accorto (in effetti — colpevolmente — non bado spesso al nome degli autori negli articoli…). E non sapevo scrivessi per HTML…
@l’OT: perche’? intendi che in questo tuo post si parla di integrazione tra File Browser e Indicizzatore, e non dell’indicizzatore in se’? Vabbe’, allora sono OT a meta’… :)
@hronir:
Tranquillo, il mio era un appunto scherzoso :)