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 :|