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

[Laurent Aguerreche <laurent aguerreche free fr>]

Le lundi 11 septembre 2006 Ã 16:01 +0100, Jamie McCracken a Ãcrit :
> Laurent Aguerreche wrote:
> > 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.
>
> the gconf thumbnailers mostly do this (resize or they take size params). 
> Im not sure what you mean by tag? (tags in the created thumbnail image?)

In libgnomeui:

  if (width != NULL && height != NULL) 
    saved_ok  = gdk_pixbuf_save (thumbnail,
                                 tmp_path,
                                 "png", NULL,
                                 "tEXt::Thumb::Image::Width", width,
                                 "tEXt::Thumb::Image::Height", height,
                                 "tEXt::Thumb::URI", uri,
                                 "tEXt::Thumb::MTime", mtime_str,
                                 "tEXt::Software", "GNOME::ThumbnailFactory",
                                 NULL);
  else
    saved_ok  = gdk_pixbuf_save (thumbnail,
                                 tmp_path,
                                 "png", NULL,
                                 "tEXt::Thumb::URI", uri,
                                 "tEXt::Thumb::MTime", mtime_str,
                                 "tEXt::Software", "GNOME::ThumbnailFactory",
                                 NULL);
    

it isn't tags, but thumbnail attributes in freedesktop standard,
sorry...
They are optionals but make loading of the original file faster...


> > 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...
>
> if X is not installed then thumbs wont get generated anyhow. Most of the 
> thumbnailers are command line only (even if they have X dependencies)
>
> > > 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)
>
> libgnomeui will probably get deprecated at some point and in any event 
> we dont want to depend on gnome specific stuff in case XFCE is 
> interested in tracker.

I just looked at GTK2.10. I really thought it implements a thumbnailing
system...
But XFCE (Thunar more exactly) has already a thumbnailing system.

> > 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"?
>
> one that uses tracker to get at files instead of doing a stat dance and 
> a huge no of slow disk seeks. Eg with tracker getting all files in my 
> home directory is a hell of a lot quicker than stat'ing around trying to 
> read off all the data from disk (which nautilus does). Plus with mimes 
> and thumbnails already generated it would make a super fast file manager.

So you begin to see Tracker as a sort of stack upon file system?

> Then of course is the integration of tags and metadata, more powerful 
> search and the ability to sort data by say Image.Date so all photos are 
> organised by when they were taken.
>
> Also good for flat views of all files like all photos or all music which 
> means the tracker filemanager would be able to act like a photo manager 
> or music manager app.


Laurent.