Re: Gdk-pixbuf savers?

One idea that might be suitable for a higher-level library is a saver
and saver options api.

i.e. each saver has its own dialogue box options if they are required
for things like quality settings/image options, etc.

The library could just handle redirecting image save calls to the
requisite module, or even handle the whole thing from a file requestor.
It might also have some image quantification code, etc, that it uses
internally to convert images before they go out.

Something like the gimp savers I guess, but available from any app
that wanted to save images.

I dont think its worth putting into gdk-pixbuf really though, it could
be pretty big.


> On Sat, 13 Nov 1999, George wrote:
> > 
> > I have to agree with Federico here. Unless the image libs itnerface is
> > sufficently braindead or hard to use it really doesn't help anything to have
> > an extremely thin wrapper that does absolutely no abstraction except for
> > having all the names begin with gdk_pixbuf_.  If saving does require all
> > kinds of weird code that can be done in gdk_pixbuf then it should be there.
> > If the saving function are just gonna call an image library saving function
> > with the same exact arguments, then it makes no sense to have these
> > functions.
> > 
> A cheesy PNG saver that didn't take any parameters (just saved in RGB or
> RGBA, raw data basically) would be convenient (using libpng directly is a
> lot of docs to read), plus save people I'd guess 40-50 lines of
> hard-to-write error-prone code. Also it would keep libpng dynamically
> loaded, instead of requiring a link at startup.
> I don't see any point in a full-featured save interface either though, it
> should just be good enough for something like gnome-iconedit or screen
> shots, then you can use a real application (such as Gimp or EOG) to
> convert to other formats.
> Havoc
> -- 
> To unsubscribe: mail with "unsubscribe"
> as the Subject.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]