On Tue, Mar 16, 2010 at 03:45:17PM +0000, Richard W.M. Jones wrote:
On Tue, Mar 16, 2010 at 02:53:29PM +0000, Daniel P. Berrange wrote:
> GObject is the primary root object, but things don't neccessarily need
> to inherit from GObject. Since you're trying to directly expose libguestfs'
> own object(s) you'll probably need to register them as base types using
> the GType APIs. This section of the API docs gives a semi-useful intro to
> GTypes
>
>
http://library.gnome.org/devel/gobject/stable/chapter-gtype.html
>
> Ultimately this comes down to a call to g_type_register_static()
>
>
http://library.gnome.org/devel/gobject/stable/gobject-Type-Information.ht...
>
> but it is not very well documented because 99% of apps just inherit
> from GObject instead of introducing new base types like libguestfs
> would need todo.
Unfortunately this doesn't work. The handle (guestfs_h *) is wrapped
inside a GType:
typedef struct _GuestfsH {
GObject parent;
guestfs_h *h;
} GuestfsH;
I can now register this easily enough, but GObject won't automatically
unpack that handle when it passes it to the other functions. ie. The
other functions would receive a GuestfsH, instead of a guestfs_h *,
and they won't know what to do with the former.
Oh I see - this struct is actually attempting to create a GObject subclass
containing a guestfs_h *. This definitely don't work, because of the
mis-matched ptrs you mention. I thought you were registering 'guestfs_h *'
itself as the type without the 'struct _GuestfsH' wrapper. This avoids
GObject entirely introducing a new base type.
Daniel
--
|: Red Hat, Engineering, London -o-
http://people.redhat.com/berrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org -o-
http://deltacloud.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|