Re: GdkPixbuf types



Mark Patton <mpatton jhu edu> writes:
> 
> I'm working on some language bindings and noticed
> a number of types in GdkPixbuf have not been registered.
> 
> Specifically: GdkColorspace, GdkPixbufAlphaMode, GdkInterpType
> GdkPixbufFrameAction, and GdkPixbufFrame.
> 
> Would you accept a patch that registered these types?
> I'll just add them to gtktypebuiltins_*.
> 

GdkPixbufFrame actually has been registered, but I did it this way:

 GType                gdk_pixbuf_frame_get_type       (void) G_GNUC_CONST;
#define              GDK_TYPE_PIXBUF_FRAME gdk_pixbuf_frame_get_type ()

Because we are trying to kill _init() functions for libraries that
don't inherently have them (i.e. everything below GDK), and because
the gdk-pixbuf types should be done in gdk-pixbuf so a language
binding of gdk-pixbuf doesn't depend on GTK, I think this is the right
way to do things. So IMHO the correct patch would add the get_type()
functions for all the types you mentioned. For enums, it should be
done automatically: look at pango/pango/makeenums.pl which has been
modified to generate this type of thing instead of the builtin type
stuff from gtk+/gtk/makeenums.pl.

I'm guessing GLib should ship with a more generic makeenums.pl script,
if you want to write that it would be good, but as a short-term fix
simply copying the one from Pango into gdk-pixbuf, and copying the
Makefile stuff from Pango, is likely fine...

For the boxed types we should likely have an equivalent to
gtk-boxed.defs and a script to generate those as well, instead of
doing it manually as I did for GdkPixbufFrame, but since
GdkPixbufFrame is the only boxed type in GdkPixbuf at the moment, I
would say we should just wait for a generic boxed script to be in GLib
instead of fooling with some elaborate script setup for now.

Havoc





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]