Re: gdk-pixbuf-save

[Owen Taylor <otaylor redhat com>]

"David N. Welton" <davidw@linuxcare.com> writes:

> Ok, this is a good idea.  I think there is some possibility for
> discussion in this area, though.  The current interface was something
> I put together when it looked like Federico was not at all interested
> in putting this functionality in.  However, if "gdk-pixbuf-save" is
> not a seperate library, then it is possible to carry this data through
> the life cycle of an image (in some cases).  I.e., at load time, you
> could get some information about the image, store it, and possibly
> access it when you go to save it.
> 
> I get the feeling that people would not like to get too complex, so it
> shouldn't be anything that must be used, or that adds a lot of
> overhead - but it might be convenient.

This sounds too complicated to me. If this was to be implemented,
the way to do it, in my opinion is stay with the key-value strings,
but keep a list with the image (that can be overriden when
saving) and have a function to query that list:

 char *gdk_pixbuf_get_extra_data (GdkPixbuf *buf, const char *key);

But all-in-all, I think it is over-complicated, and not all that
useful. The save functionality is not and should not be sufficient
to implement the GIMP's save plugins.
 
> In a c++ program I was working with, these seemed to be causing some
> problems, so I ifdef'ed and commented everything out aside from the
> original fatal error handler.  I'm afraid I don't understand the
> interaction between all these pieces well enough to really get a
> handle on what the problem was.  (Nor was it the only problem - using
> c++ filestreams on a totally unrelated text file caused corruption on
> saving a jpeg, in a different part of the program...wierd!).
> 
> >  /* Destroy notification function for the pixbuf */
> >  static void
> >  free_buffer (guchar *pixels, gpointer data)
> > @@ -168,6 +190,8 @@
> >  	/* setup error handler */
> >  	cinfo.err = jpeg_std_error (&jerr.pub);
> >  	jerr.pub.error_exit = fatal_error_handler;
> > +	jerr.pub.output_message = error_handler;
> > +	jerr.pub.emit_message = error_handler2;
> 
> These are the things I commented out.

Hmmm:

 - I don't think we need to setjmp/longjmp for warnings,
   and you definitely want to keep setjmp/longjmp to 
   a minimum

 - But it makes me nervous that you are saying that 
   setjmp/longjmp caused problems with these extra
   error handlers when we used it for fatal errors
   in the existing code.

Regards,
                                        Owen