Re: [Tracker] Are thumbnails from trackerd really useful?



Le lundi 11 septembre 2006 Ã 14:15 +0100, Jamie McCracken a Ãcrit :
Laurent Aguerreche wrote:
Le dimanche 10 septembre 2006 Ã 17:16 +0100, Jamie McCracken a Ãcrit :
Laurent Aguerreche wrote:
Hello,

currently trackerd generates thumbnails for PDF files. I just wonder
whether it is useful!

To have this feature, trackerd calls evince (which depends on many
components of X and GNOME...) and those calls slowdown a little bit
trackerd.

Graphical shells, like Nautilus, Konqueror or Thunar, are supposed to
know how to make thumbnails from files, and I have already many
generated thumbnails in ~/.thumbnails. So I think that trackerd should
not do thumbnails and let other programs do it by themselves.

Am I missing something?


Yes.

Doing it in tracker means you wont have to wait for file managers to 
thumbnail.

Yes but I don't care about that! IMHO trackerd should be dedicated to
extract datas from documents for research, and only for research.

In future if trackerd does a thumbnail for each indexed file it will
spend something like an equal, or greater, time for this task than for
extracting datas.
Furthermore I know that I have some documents that I won't never open
because they are in archives, in big projects, etc. So while trackerd is
losing its time with thumbnailing for documents that I won't never open,
live queries aren't as responsives as they could be for instance.

However:

1) thumbnails should be optional so feel free to add an option to 
disable them.

Ok. So I propose a patch.

thanks patch is good and now committed.

(default is DoThumbnails=true...)

2) They dont use the freedesktop spec for thumbnails yet. This is a bug 
and a fix would be nice
http://lists.freedesktop.org/archives/xdg/2004-October/005067.html

But a fix doesn't seem to be so easy!
Names in ~/.thumbnails/{normal,large,fail} are md5 hashes. I think it
isn't a problem since there is a free (in public domain) implementation
available in libgnomeui (it just takes time to compute uri). But
problems come right after: thumbnails need to be resized and tagged. In
libgnomeui, GDK is used. Since GDK is dependent to X, a replacement
should be found...

MD5 hash does not require gnome. (mysql has a function for it built in 
but as md5's code is so small you could inline the source for it in 
tracker-utils.c)

Yes I know. I just say that I found an implementation in public domain
in libgnomeui. It is small and can be reused/copied. :-)


Its easy to fix and efficient too. Tracker would simply check the mtime 
of the existing thumbnail in ~./tumbnails before deciding whether to 
call a thumbnailer.

You also need to resize thumbnails and tag them which requires a library
that can handle many different picture format.

Or other possibility: each thumbnailer produce a correctly sized and
tagged PNG picture that can be copied. Problem is that many of them will
require X... If someday you want a daemon that indexes documents
in /usr/share/doc for all users (datas sharing), you will have to assume
that it doesn't use X...

Thumbnails are important for a tracker search gui and a possible tracker 
backed file manager which I plan to write some day!

Look at GnomeThumbnail in libgnomeui, there is already all you need to
manage tumbnailing! (perhaps this code is in GTK2.10 now)

It is easy to use and any application that use it will fill
~/thumbnails/* automatically if necessary. :-)

So I'm staying on my idea that thumnailing in trackerd isn't useful...


And what is a "tracker backed file manager"?


3) long term plan is to add *optional* gconf facility for replacing the 
config file and getting access to all the the thumbnailers defined in 
gconf (see keys /desktop/gnome/thumbnailers in gconf-editor)

Hum... and a corresponding thing for KDE's users?   ;-)

Im not a c++ programmer and there are no C bindings to KConfig so would 
need a volunteer to do this.


It could be interesting to have a way to change options dynamically.
With DBus?

maybe but that would mean updating the backing store too (gconf, ini 
file, kconfig etc) so might be tricky.



Laurent.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]