Re: Independent image loaders in gdk-pixbuf
- From: Matthias Clasen <maclas gmx de>
- To: gtk-devel-list gnome org
- Cc: otaylor redhat com
- Subject: Re: Independent image loaders in gdk-pixbuf
- Date: 28 Sep 2002 01:53:51 +0200
On Wed, 2002-09-25 at 13:40, Matthias Clasen wrote:
> >
> > You could make this a struct, even, which might contain:
> > *) mime-type (image/jpeg)
> > *) format name (JPEG)
> > *) common suffix(es) (jpg jpeg)
> > *) description (Blah Blah....)
>
> I'm currently working on implementing the following API:
>
> GSList * gdk_pixbuf_get_formats (void);
> GSList * gdk_pixbuf_get_writable_formats (void);
> GSList * gdk_pixbuf_get_mime_types (void);
> GSList * gdk_pixbuf_get_writable_mime_types (void);
> GdkPixbufLoader * gdk_pixbuf_loader_new_with_mime_type (const char
> *mime_type,
> further info)
I tried your struct approach instead, and settled on the following api:
typedef struct _GdkPixbufFormatInfo GdkPixbufFormatInfo;
struct _GdkPixbufFormatInfo {
gchar *name;
gchar *description;
gchar **mime_types;
gchar **extensions;
gboolean is_writable;
};
GSList *gdk_pixbuf_get_formats (void);
GdkPixbufFormatInfo *gdk_pixbuf_loader_get_format (GdkPixbufLoader
*loader);
This looks good to me as far as the API is concerned, but the
implementation is a bit messy, since it involves adding getters for all
the fields in GdkPixbufFormatInfo to GdkPixbufModule, dumping all this
information (and some more) to the gdk-pixbuf.loaders text file (the
description has to be dumped as a domain/msgid pair for I18N, ugh !)
then parse it all again. This complexity is necessary because we need
the information before loading the module (which may be linked against
big image libraries).
A much more elegant implementation would be to have two dlopened objects
per image loader:
* one containing a get_info and a check_format method
* one containing the loader itself and the fill_vtable method, may be
linked against image libraries
gdk-pixbuf would always dlopen the first one, since it needs get_info
and check_format. The second one would only be dlopened when we are
actually loading an image of the given format (like the current loader
modules).
One advantage of this approach is that every loader can implement its
own check_format method, performing whatever checks it considers
necessary, and we don't have to invent a (restrictive) format for
parameters to a generic check_format method.
I'm willing to try this approach if the overhead of having two
dlopenable objects per loader and always dlopening one per image format
is not rejected beforehand.
Matthias
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]