Re: GtkImageView

[muppet <scott asofyet org>]

On Feb 13, 2008, at 3:25 PM, Jeffrey Ratcliffe wrote:

> I held off releasing the Perl bindings for gtkimageview 1.5.0 because
> the author wanted to add the GTypes and a couple of other things. This
> he has done, and I have updated the bindings to match
> (http://trac.bjourne.webfactional.com/). There are, however, a couple
> of things that I don't understand:
>
> a. there is an enum (not a gobject), GdkPixbufDrawOpts, which is used
> in both gtkiimagetool.h and gdkpixbufdrawcache.h. I find I have to
> include the newSVGdkPixbufDrawOpts and SvGdkPixbufDrawOpts definitions
> in the bindings twice, once for each header file, to avoid errors
> missing the SvGdkPixbufDrawOpts symbol. What am I doing wrong?

It's a struct (data structure), not an enum (enumeration of constant  
values).

You've marked your newSVGdkPixbufDrawOpts() and SvGdkPixbufDrawOpts()  
functions with the C storage class keyword "static", which means that  
the function is visible only within that C file.  Since you need to  
share the functions between two files, remove the static keyword from  
those functions in one file, and remove the definitions altogether  
from the other file.


> b. compiling gives me the message:
> GdkPixbufDrawOpts is not registered with the GLib type system.

That's because it's a plain structure without a GType.  This message  
comes from the Glib module when you try to look up the name to get  
information, most likely as part of the documentation generation  
process.   ...  Yes, you have the xsub declaration

   void
   gtk_iimage_too_paint_image (tool, opts, drawable)
           GtkIImageTool * tool
           GdkPixbufDrawOpts * opts
           GdkDrawable * drawable

xsubpp will see that you want GdkPixbufDrawOpts for the opts argument,  
and will look that up in the typemap, where you have it defined as a  
T_GPERL_GENERIC_WRAPPER (gtkimageview.typemap).  That typemap says to  
use newSV$typename and Sv$typename to marshal this type.

Then, the documentation generator scans through the code and sees this  
xsub wants a GdkPixbufDrawOpts argument, and asks the Glib type system  
to describe that type.  Glib says, "GLib doesn't know anything about  
that name", which is true.  This should be a non-fatal error.

You can either ignore it, or change the xsub to look like this:

    void
    gtk_iimage_tool_paint_image (tool, opts, drawable)
            GtkIImageTool * tool
            SV * opts
            GdkDrawable * drawable
       C_ARGS:
            tool, SvGdkPixbufDrawOpts (opts), drawable

which says, "here's an xsub which is a wrapper for a C function, but  
when you go call it, pass this string as the argument list", and we  
call the marshaling function by hand.

Still another option, more correct but more work, is to register a  
GBoxed wrapper for the structure.  Then everything will Just Wonk.



> c. Gtk2::Gdk::Pixbuf::Draw::Cache::get_method segfaults at the moment
> if it not fed with the requisite two GdkPixbufDrawOpts. As the Perl
> version of GdkPixbufDrawOpts is a hash, what is the best way of
> checking that the hash is a Gtk2::Gdk::Pixbuf::Draw::Opts? isa doesn't
> work, because it is a hash, not a gobject. Should I be blessing the
> hash?


You're not doing anything in SvGdkPixbufDrawOpts() to verify that you  
actually have a hash, so you can wind up either crashing or giving  
back a structure filled with garbage, and causing a later crash.

Torsten recently added to Glib some useful functions for this purpose,  
including gperl_sv_is_hash_ref():

    GdkPixbufDrawOpts *
    SvGdkPixbufDrawOpts (SV * sv)
    {
        HV * hv;
        SV ** sp;
        GdkPixbufDrawOpts * opts;

        /* Make sure it is what we think it is before we try to  
dereference and parse it */
        if (! gperl_sv_is_hash_ref (sv))
            croak ("Expected a hash reference for  
Gtk2::Gdk::Pixbuf::Draw::Opts");

        hv = (HV *) SvRV (sv);

        ...




Blessing the hash would help you do even more validation, but is not  
strictly necessary.  If your user is allowed to supply a plain old  
hash of his own making, then requiring a blessed hash will be  
breakage, but if the user is supposed to use one of your methods to  
create one of these things, then blessing the hash is A Very Good Idea.





--
The one difference between Dali and a crazy man is very simple: Dali  
is not crazy at all.
  -- Salvador Dali