Re: Proposed new API for libgnomeui

[Dave Malcolm <david davemalcolm demon co uk>]

On Tuesday 17 September 2002 19:55, Alexander Larsson wrote:
> On Tue, 17 Sep 2002, Dave Malcolm wrote:
> > On Tuesday 17 September 2002 16:48, Alexander Larsson wrote:
> >
> > <snip>
> >
> > > As a bonus I've added pluggable thumbnailing scripts.
> > > By putting this:
> > > video/x-msvideo: /home/alex/bin/avithumbnailer %i %o
> > > application/pdf,application/postscript: gs  -sDEVICE=png16m -r11
> > > -dFirstPage=1 -dLastPage=1 -sOutputFile=%o -dBATCH -dNOPAUSE %i
> > >
> > > in ~/.gnome2/thumbnailrc i was able to get this:
> > > http://people.redhat.com/alexl/files/thumbnails2.png
> >
> > <snip>
> >
> > Excellent - a few thoughts:
> > (i) For the pdf/postcript files, you might want to add "-dSAFER" for
> > paranoia's sake; also -sDEVICE=png256 was a lot faster for me when I was
> > playing around with this, with no appreciable loss of quality (on my test
> > cases, at any rate)
>
> Good stuff.

Now I think about it, my test cases were mostly monochrome, or with simple 
use of colour, so 256 colours were adequate for me,  Doh! :-)

>
> > (ii) Is ~/.gnome2/thumbnailrc just a temporary staging area?  We'd want
> > to be able to install new thumbnail generators on a per-mimetype and
> > possibly per-user basis.
>
> I'm wary about automatically installing these things. They can take a lot
> of time to run and be potential security hazards. I don't think make
> install of some random package should suddenly make me vulnerable to some
> postscript attack.
>
> I'm willing to discuss the exact behaviour though, but let's first see if
> we can get the API in.

The "lots of time to run" argument: When I implemented this before as a 
Nautilus patch I had problems when entering a big directory full of 
Postscript files - although the thumbnails were being generated on a separate 
thread, they were all on the same thread and so a complex file would block 
that thread.  So perhaps a pool of thumbnailing threads waiting for responses 
from the spawned processes?

Hopefully these thumbnails will be only regenerated every now and then (when 
the file changes), so although it's a CPU hog it shouldn't kill the system.   
(crosses fingers)

Could the scripts be "niced" down to a low priority?

Security risks:  good point.

Usual performance tradeoff issues; insert the usual "make it a preference" vs 
"abolish all preferences" discussion here.  Perhaps each thumbnailer could 
register itself with two parameters: speed and safety.  To minimise 
configuration hell, there could be a per-user property saying what level of 
speed and safety they will accept.  Hence, if running as root, you would 
disable all thumbnailers, if running on a low-end machine you perhaps would 
only enable "fast" thumbnailers, whereas if you wanted full eye-candy you 
would turn everything on.  Not at all sure about this, mind.

I hope that there will be lots of thumbnailers available, covering most of 
the file formats that users encounter (where appropriate).  In the same way 
that an application integrates itself with the desktop, installing the 
mimetypes it knows how to open etc, I hope that applications will want to 
provide scripts for thumbnailing their file formats etc. That implies some 
kind of mechanism for installing/configuring thumbnail generation.  

What that mechanism is, I don't know, but hacking a line onto the end of a 
text file seems crude; hence my comment about "temporary staging area" etc

>
> > (iii)  I've got a heavily hacked version of libole2 for extracting
> > thumbnails out of MS Office docs.   Where should I be sending patches
> > etc?
>
> No patches necessary. Just add stuff to your ~/.gnome2/thumbnailrc or
> /etc/gnome/thumbnailrc.

(Looks like I should be sending Jody some patches for libgsf)

>
> > <bluesky-mode>
> > (iv) ultimately it might be better to implement thumbnailing as a
> > component rather than script-based system; you ask an activation
> > framework to give you a reference to an object that can thumbnail a
> > particular mime-type.  That way you can amortise startup costs when e.g.
> > generating 10 thumbnails involving something complex e.g. StarOffice, and
> > hopefully avoid them altogether if StarOffice's already been launched
> > (you can hopefully ask it to generate some thumbnails for you, without
> > having to launch it yourself).   Though I'm not familiar enought with
> > Bonobo to implement this myself :-(
>
> I'm not sure this is a good idea. If done in-process it brings in lots of
> libraries that could collide, and may introduce instabilities. Done
> as an out of process component is possible, but it feels quite
> overengineered to me.

I was thinking out-of-proc - StarOffice/OpenOffice is my use-case - takes 
forever to boot but useful to have resident in memory once you have done; 
would then use the component framework to "talk to it", and generate the 
thumnbails.

My main worry for a component approach rather than a script approach (beyond 
a lack of experience/confidence with Bonobo) is that it would tie the 
thumbnailers to GNOME's component system - an advantage of scripts is that it 
should be easier to make it a cross-desktop thing, so that e.g. thumbnailers 
could be shared between GNOME/Nautilus and KDE/Konqueror (as well as merely 
the thumbnails themselves).   Perhaps this should be discussed as a 
FreeDesktop issue?  Would be nice to have thumbnails of KOffice files in 
Nautilus and of Gnome Office files in Konqueror.  (I've only got Konqueror 
1.9.8 installed: seems to do thumbnails of image files but nothing else)

>
> > (v)  taking things further, this could be generalised to per-mimetype
> > metadata providers:   the component we've launched might be able to tell
> > us the page count of a document, the author, the dimensions in pixels
> > etc. (These could then be displayed in Nautilus - page count is probably
> > more interesting to users like my mother than size in bytes).  Recent
> > versions of the WIn32 Shell Namespace and Explorer collaborate to provide
> > this kind of functionality.
> > </bluesky-mode>
>
> I will hopefully soon have some time to work on pluggable property pages
> in Nautilus. These could be per-mimetype and have custom information or
> even editing of the file. They can also be per-filesystem and do stuff
> like ACLs.

A good plan.  I was thinking of a slightly different (and parallel) queryable 
system where you activate a metadata provider object from a mimetype, which 
you can query for a list of fields of metadata, which you can then use to do 
name-value queries on a URI.   The fields also have translated names.   
Example:  "width-pixels" as a fieldname for image files, translated to "Width 
(pixels)" in an English locale.

This means that you'd have two sources of metadata:  data from the underlying 
filesystem (simple stuff like size in bytes, plus more funky stuff if using 
e.g the Reiser filesystem), plus data from the system I described above 
that's actually embedded in or generated from the file itself, but from a 
user's point of view "feels like" metadata (e.g. page count for a printable 
document, generated from the file by an app that understands the file 
format).   Arguably the latter is a product of the data, rather than 
"metadata", but from a user's point of view I don't think it's a useful 
distinction - both would be useful things to have columns for in a list view 
that I might want to sort the list on, or to have displayed under the icon in 
icon view.

The advantage of key-value metadata pairs over property pages is that you can 
consolidate them into list views from a variety of different sources (e.g. 
page counts for AbiWord and OpenOffice documents in the same column of a list 
view).   The advantage of property pages over a key-value system is that the 
UI can be designed to look nice "out of the box", and will probably be _much_ 
easier to implement the framework for. 

But this is very much "bluesky" at the moment (although, IIRC, Win32 does 
have both pluggable property pages _and_ pluggable key-value metadata pairs; 
the former is easy to find, the latter is well-hidden in the Explorer).

Apologies for writing so much English and so little code...

Dave