Re: gtk2 news

[muppet <scott asofyet org>]

Christian Borup wrote:

> On man, 2002-09-09 at 18:43, Scott Smith wrote:
>
> > * After wrapping the libraries:
> >
> > While basic wrappers for the libraries would be nice,
> > all we'd be left with is perl code like:
> >
> >    use libgtk;
> >    my $winptr = libgtk::gtk_window_new();
> >    libgtk::gtk_window_set_title($winptr,"My Title");
>
> This would be silly. 
> XS will do all the wrapping for you.
> You just give the XS compiler a couple of hints, and the methods will be
> placed in the right packages.
>
> The hints in this case would be:
> MODULE = Gtk::Window    PACKAGE = Gtk::Window   PREFIX = gtk_window_
>
> This makes gtk_window_new() become Gtk::Window->new() in Perl.

careful ---- the XS function would have to know that a string argument 
was coming.

GtkWidget *
gtk_window_new ( class, type=GTK_WINDOW_TOPLEVEL )
       char * class
       GtkWindowType type
   CODE:
       RETVAL = gtk_window_new ( type );
   OUTPUT:
       RETVAL


in most cases such a trick isn't necessary, because the object itself 
supplies the class.


as you pointed out, this overcomes the problem of defining the method 
interface from the functional interface --- they are one and the same.



> Again XS will do this translation for you. This is what typemaps are
> for.
>
> Using a hashref is actually a pretty neat idea. If the plain C pointer
> was used the object would be opaque to the Perl side of things. So
> subclasses would have nowhere to put object private data (I do know
> about set_data/get_data - but those present other problems).

another reason to use a hashref containing the C pointer instead of a 
plain blessed C pointer as the type is preventing accidental destruction.


i've run into this problem before when using blessed C pointers as objects:

   sub dosomething {
       my $object = shift;
       my $childobject = 
$object->get_child_object_from_pointer_held_deep_within_object;
       ...
   }


note that i'm not creating a new widget for $childobject here --- a new 
object is being created from a pointer to an exsiting object.

at the end of the block, since $childobject is local, it's DESTROY 
method will be called...  if you don't have proper reference counting 
going on, this will actually destroy the object right there, which can 
wreak havoc on your program.

if you keep the C pointer in a hash ref and use the hash ref as the 
object, the GObject reference counting can continue normally and the 
objects don't die early.

then again, am i full of crap?   what if the typemap used GObject 
reference counting to keep the objects alive?  is that a better 
solution, or are there still holes there?  you still run afoul of the 
fact that you might already have an perl object for that GObject...  (in 
my opinion, this is the messiest aspect of the whole shebang.