Re: Proposing Tracker for inclusion into GNOME 2.18

["Alberto Ruiz" <aruiz synaptia net>]

2006/10/20, John Stowers <john stowers lists gmail com>:

Hey John,

I have been using tracker for a few months (since the move to sqlite)
and think it is great. I also use Beagle (for email searches, and
because its result tiles are more useful).

I was under the impression that (features aside) because Tracker is
written in C, there is greater chance that it could end up lower in
the GNOME stack.

Yes it has a DBus interface, and for 'search type' apps (nautilus,
deskbar, etc)  which query it DBus is probbably the easiest interface.
However if it comes into the platform then I look forward to seeing
some kind of libtracker-gtk library being written with;
* A tagging widget
* A media browsing widget (a treeview with Video, Music, Pictures,
like the one you see in all apple iApps)
* A tile derived widget for displaying a files metadata
* Generic treeview/iconview/tile results widget
* RDF manipulation functions
* lots of other crack

That would be awesome, since a lot of overlapping features in several multimedia apps written using GNOME libraries could unify the way they looks and the technology they use. I'm thinking about rhythmbox, banshee, f-spot, etc.., but they're building their own model from scratch, and it's hard to reuse the work for other apps.

A library like that in our stack could start promoting a better way to access data other than file choosers or dialogs like that. A view of collections of documents of the same class or scope, are, IMHO, a more usable way to behave than the actual model of browsing inside a tiny filechooser to open or store documents (or drag and dropping from nautilus). This is not something new, the examples that I marked after work like that, and others applications on the stack could, but, without this kind of tools in the platform it's harder to get people implemeting this kind of features in their apps.

Beagle AFAIK, doesn't solve this problem except from the indexing and searching point. It's not possible to build a metadata layer around documents with it.

So, I think that something like tracker plus those UI candy that John suggest inside the GNOME development platform makes sense in order to:

a) Avoid the actual overlapping features on several existing apps and utils (banshee, rythmbox, f-spot, leaftag...)
b) Promote this model of interaction between documents for a better user experience (document class views instead of file choosers).

If no better candidates than tracker are proposed for solving this problems, I think that we should make a roadmap in order to get it as stable and performant as the GNOME community wants it to be and include it as soon as possible (I don't mean 2.18).

I think this is the chicken and the egg problem. If tracker comes into
GNOME then that gives application authors a central place to store and
lookup tags and metadata about objects.

Being in GNOME gives the incentive/reason for a libtracker-gtk to
exist, and it has the potential to make GNOME, desktop wide, more
integrated.

I suppose I can more clearly see the possibilities, and a roadmap on
how to get there if Tracker is in GNOME.

-- 
Un saludo,
Alberto Ruiz