Re: gdkpixbufloader-API shortcoming

["Dominic Lachowicz" <domlachowicz gmail com>]

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 <magnusbe algonet se> 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.