Re: BonoboPreview initiative - png in a control

[Jens Finke <jens triq net>]

On 10 Dec 2001, Rodrigo Moya wrote:
> > Well, your point is to use a BonoboControl for displaying all this. Let's
> > assume you have a dir with 30 different files in it. I don't believe it's
> > very efficient to start multiple controls to create a preview for all the
> > different file types.
> >
> my point is not to use BonoboControl because I want to, but because it
> seems the best solution, IMO. Of course, having lots of controls at the
> same time could be bad, unless those controls are made really
> lightweight.
> If there's a better solution than using BonoboControl, it's fine for me.
> But I don't think the thumbnail idea is a good idea for non-image files.

Well I just have concerns about the speed of the following standard
usecase:

"The user points to a directory in nautilus with >100 different files in
it and want a preview for them."

If I understand this correctly there will be started a component for each
file type now, which generates previews. When you have a gnumeric file
here, what should be in the preview? A small version of the gnumeric
table! This means that you must interprete all the nifty features of
gnumeric to generate a real preview (eg. Guppi graphs). This applies to
all other complex applications.

And what do you do with these previews after the user changes to another
dir? Throw them away? And the next time it takes again a lot of time to
render the preview (=> big waste of cpu time). Wouldn't it be better to
generate thumbnails once and save them permanently for reuse? This is
where the TMS jumps in, because it defines a way how to save thumbs
permanently.

So, I see this solution: We create a preview framework which provides easy
access for applications to previews for different file types. Every
preview is a png image.  If a preview doesn't exist for a certain file the
preview framework searches for a component which can do this job. So
Gnumeric can register a preview component for this framework. IMO this
merges both ideas and especially ensures that all operations are as fast
as possible.

If you really need a full featured component to present a preview (eg.
your oaf file example) than you should think about two things:
1. Is this a standard use case which is worth supporting?
2. Is this needed or shouldn't it better provided by a real application?

Regards,

   Jens

-- 
"Wer die Freiheit aufgibt, um Sicherheit zu gewinnen, wird am Ende beides
verlieren." -- Benjamin Franklin