- From: Owen Taylor <otaylor redhat com>
- To: gtk-devel-list redhat com
- Subject: Re: gdk-pixbuf-save
- Date: 28 Jun 2000 18:45:55 -0400
"David N. Welton" <email@example.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.
- I don't think we need to setjmp/longjmp for warnings,
and you definitely want to keep setjmp/longjmp to
- 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.
] [Thread Prev