gdkpixbufloader-API shortcoming

[Magnus Bergman <magnusbe algonet se>]

A small shortcoming in the gdkpixbufloader-API causes me trouble. The
problem is this:

Let's say my loader libpixbufloader-foobar can handle the two (very
similar) formats image/x-foo and image/x-bar. Then an application
identifies an image as either foo or bar it invokes my loader. But the
loader has no way of telling if it's supposed to handle a foo-image or
a bar-image. I guess that the idea is that the loader should be able to
easy distinguish between the two formats by fingerprinting the first
few bytes. But since both foo and bar lack a decent header that cannot
be done. (I must stress that this is not a hypothetical problem but a
very real one I have encountered more than once then writing loaders
for obscure formats).

The solution is some way for the loader to know why it was chosen.
Either which mimetype or which extension (of those supplied by the
loader) was a match. Perhaps just a function which could be called by
the loader like:

gdk_pixbuf_why_me(gpointer handle,gchar **matching_mimetype,gchar **
matching_extension);

Or are there some plans for a totally new API for pixbuf loaders since
I have seen some other shortcomings of the current one. Someone
requested about the same thing as me (but for using an external library
which already supported all image formats supported by gdkpixbuf and
then some). Another thing mentioned is the one to one mapping between
loader and image format which is bad then then saving images (even if
the loader can distinguish between different variants then loading it
does nothing for saving). A suggested solution (read ugly hack) was to
duplicate all of the code for each format (or create a library which is
called by a small wrapper for each format). But that is obviously not
an optimal solution.

I did't find anything about this in bugzilla. But I'll wait with filing
a bug until I know if there is a plan already.