Re: BonoboPreview initiative - png in a control

[Chris Phelps <chicane reninet com>]

I have been quite for long enough now...this was a planned silence to
allow everyone's ideas to be presented before I went off about how it
could feasably be done and the like.
So far most of what I have heard is pretty off-kilter imho, as it doesnt
have anything to do with a *workable* file selection dialog, but rather
some improvements for nautilus or the like. I am not proposing any type
of thumbnailing system...rather a component that will present the
contents (or some of the contents) of a file in a read-only manner,
probably via the canvas, similar to a GnomePrint preview, only scaled
smaller (maybe 200x300 pixels or so), which would embed itself to the
right of the file list in the dialog when needed (not when every file is
selected...maybe a middle-click, or possibly a dnd action into an empty
"preview" area...I havent decided on that part yet.

Ok, so to refocus the topic here -> No thumbnailing will be done...that
is complete crack and everyone ought to know it.

Later,
Chris

On Mon, 2001-12-10 at 07:54, Jens Finke wrote:
> 
> 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
> 
> 
> 
> 
> _______________________________________________
> gnome-devel-list mailing list
> gnome-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-devel-list
-- 

http://glimmer.sourceforge.net - My pet project
http://uberhackers.dhs.org - My personal website

./configure --prefix=/dev/mocha --enable-caffeine