A possible (though non-optimal) solution is to create 2 loaders - 1 for image/x-foo and 1 for image/x-bar. You can share 99% of the code, and then pass the mime type to your decoder function, based on which DLL got invoked. This is what the GDI+ based loaders do on Windows, for instance.
Best, Dom On Wed, Jun 11, 2008 at 3:19 PM, Magnus Bergman <[EMAIL PROTECTED]> wrote: > 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. > _______________________________________________ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list > -- Counting bodies like sheep to the rhythm of the war drums. _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list