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. _______________________________________________ tracker-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/tracker-list
