Re: BonoboPreview initiative

["Dirk-Jan C. Binnema" <bulkmeel yahoo co uk>]

On Sun Dec 09, 2001 at 04:51:54PM -0800, Maciej Stachowiak wrote:
> On 09Dec2001 04:59PM (+0100), Rodrigo Moya wrote:
> > On Sun, 2001-12-09 at 16:22, ERDI Gergo wrote:
> > > On 9 Dec 2001, Rodrigo Moya wrote:

> > But I think using the Bonobo/PreviewControl in the bonobo_get_object
> > call can be at least used to clearly specify that what you want is a
> > preview control, and not a normal control. Thus, the moniker
> > implementation can choose on how to generate the returned interface (a
> > zoomed thumbnail, a summary of the document, etc).

Well, thinking of it, using a plain Control would probably suffice;
a problem could be that a given component can only export Control *once*,
while it would be natural to model it as exposing it's (preview) contents 
through multiple Controls.
 
> The temptation to define new IDL interfaces just so you can use them
> in bonobo_object_get points to a missing capability in monikers as
> currently used in GNOME. You can only get an object based on one IDL
> interface it provides. You can't request a single object that has more
> than one interface, or request objects based on additional
> requirements.

bonobo_object_get is a simple API call (from a user perspective) for 
simple questions; for harder questions there's OAF. Maybe we can 
recognize some common "harder questions" that could be made easier
by some bonobo_object_get_a_little_harder... 
 
> It would be nice if you could have many Bonobo/Controls that handle
> the same MIME type, but specialized for different situations. One for
> embeddability as a full-size editing-capable view, one for use as a
> small preview, one for use as a full-size preview, etc.
> 
> And in this case, you want applications to be able to choose the right
> one based on attributes besides just a single IDL interface.

Ugly (I admit) as it is, empty subclasses are the easiest way to accomplish
this.

Getting back at the question of the document preview, it seems clear
to me that having the responsibility for that at the document host app
is the way to go.
 
That does raise some questions, such as would it
be necessary to start a full gnumeric, abiword, starwriter, gimp in the
background, just to have a little preview image? The point in having
a preview is to be able to see in instantly. How does MSOffice do this?

I can think of some solution, e.g. to have the document host app
generate the preview at document saving time, and add it to the saved
document (this could be a .png and/or a list of named properties for
accessibility); thus the preview could be shown without starting the
app, by just pulling the preview stream from the document.

For documents that don't or can't support that (ie. ps, pdf) at least a 
generated preview could be cached, not unlike thumbnails. 

--Dirk-Jan