I'd like to fix all of this issues in gnome-print rather than working
around it on the bindings side.

About GnomePrintConfig, as you may have noticed GPC is not a GObject,
i don't know how to expose it's type, you talk about exposing it as a
Boxed type, I don't know what does that mean but if you point me at
another library that is doing so I can clone whatever it is doing.

About enumerations, I'll get to it.

About GnomePrintReturnCode, the thing is that the return value might
not always be inside the ones defined by GnomePrintReturnCode, there
is some code inside which does something like: static gint

gnome_print_ps2_stroke (GnomePrintContext *ctx, const ArtBpath *bpath)
{
	GnomePrintPs2 *ps2;
	gint ret = 0;

	ps2 = GNOME_PRINT_PS2 (ctx);

	ret += gnome_print_ps2_set_color (ps2);
	ret += gnome_print_ps2_set_line (ps2);
	ret += gnome_print_ps2_set_dash (ps2);
	ret += gnome_print_ps2_print_bpath (ps2, bpath);
	
	g_return_val_if_fail (ret >= 0, ret);

	ret = gnome_print_ps2_fprintf (ps2, "S" EOL);

	return ret;
}

So even thought each call will return a GnomePrintReturnValue, the
result might not be within the defined values. Does this changes things?

For boxed types, there are lots of examples in pango and gtk+ for
this.  The _get_type() routine for a GnomePrintConfig boxed type would
look like this:

GType
gnome_print_config_get_type (void)
{
    static GType type;
    if (!type)
        type = g_boxed_type_register_static("GnomePrintConfig",
                          (GBoxedCopyFunc) gnome_print_config_ref,
                          (GBoxedFreeFunc) gnome_print_config_unref);
    return type;
}

In the Python language bindings, we handle the memory management of
boxed types in a standardised way (rather than once for each type). 
If I know the GType for a boxed type, the way of copying (or ref'ing)
a boxed pointer is:
    newboxed = g_boxed_copy(type, boxed);
and to release newboxed:
    g_boxed_free(type, newboxed);


About the GnomePrintReturnCode stuff, fair enough.  Although it does
mean that the return code on functions like that can only indicate an
error; not what sort of error occurred (I don't know how much of a
problem that is, really).

ok, i'll do the GnomePrintConfig _get_type thing. Any other object
that is not exposed right now?

About the GnomePrintReturnCode comment, I agree. It end up meaning
success/error in most cases. It has the advantage of making the code
more explicit, or in certain cases where you know a call will return
you an enumed type.

Created attachment 11102 [details] [review]
patch, a bit overkill using gtk-mkenums

Created attachment 11103 [details] [review]
patch, the simple version

jamesh,

I attached two patches. The first one is using glib-mkenums but it
seems to be a bit overkill, given that we only have one enum (plus the
return value which we are not going to use).

Patch 2 is the simple case which exposes the Unit enums types.

Both patches exposes a type for GnomePrintConfig.

I wanted to keep the non-simple patch in bugzilla in case we ever want
to do it by generating the code.

Is the simple patch good for you? Do you need anything else?

It is probably better to use glib-mkenums.  It is a little more work
up front, but in  the long run it is easier (you don't have to worry
if you add enum types or add extra values to an enumeration).

The glib-genmarshal stuff could be omitted from the Makefile.  It
doesn't look like you have any signals that need marshal functions
generated for them.

FIXED in cvs. Reopen if I'm missing something.