GnomeCanvas and some under-the-hood GBoxed changes

["muppet" <scott asofyet org>]

at long last, i've committed the new GnomeCanvas bindings to CVS.  they were
held up by one nagging problem in Glib-Perl which is now fixed.  (hence the
double announcement :-)


for users:
==========

there is now a GnomeCanvas-Perl module available in cvs, at
gtk2-perl-xs/GnomeCanvas.  libgnomecanvas doesn't actually depend on the Gnome
libraries, so i thought it best not to make the perl wrappers depend on Gnome,
either -- you only need Glib and Gtk2.

i've ported the canvas_demo app from the libgnomecanvas source; run canvas.pl
from the canvas_demo subdirectory (after make install) to try it out.

there are still some bugs, and i need help finding them --- somebody please
write a program using GnomeCanvas and tell me what doesn't work or what isn't
implemented!

this hasn't been released on sourceforge, yet, as it requires the bleeding
edge CVS version of Glib-Perl, which won't be released until this coming
friday.


for binding developers:
=======================

i made an important under-the-hood change to the functions that wrap and
unwrap GBoxed objects; basically, they now look to a vtable to find out what
functions to call for a given type.  the vtable is registered when the GType
is registered; 99% of the time you[1] pass NULL here to get the default
wrapper, which is the current opaque object.

why does this matter?  it allows GdkEvent to be mapped to various other
specific subtypes despite the fact that only GDK_TYPE_EVENT is actually
registered with the type system, and it allows GnomeCanvasPoints to be used as
plain perl array references rather than cumbersome single-use opaque types. 
it also would've removed most of the stumbling blocks i had with GdkRectangle
a few weeks ago.

before everybody and his brother realizes that this means we could implement
GdkEvents as hashes and starts asking me to, i'll load you down with my
philosophy on why that's a really bad idea:

1. 95% of the time you need only one member from a GdkEvent.  converting the
entire thing into a hash every time when you only need one member is a
collosal waste of processing power.  this is a good rule in general.  i know
two decent arguments for treating GdkEvents as hashes:
   a. that's what gtk-perl did - it would make the code easier to port
   b. hashes are easy to print with Data::Dumper
reason a is all well and fine, but there are enough changes that i think we're
safe in reminding people that this is a different version of the bindings. 
besides, mostly you only have to remove the braces ($event->{member} becomes
$event->member).
reason b is easily taken care of by a specialized function that does something
like what Data::Dumper would do.  (i haven't written it, but it would be easy
to do...)

2. in general, keeping the opaque pointer lets you keep the pointer to the
real thing.  if you have functions that can modify data within the struct,
they can work on the real thing by reference.  if you convert a boxed object
to a hash, you lose this ability.

3. on the other side of the coin -- in some cases, such as
Gnome::Canvas::Points, it simply makes no sense to have an opaque type when
you know that all you really need is a list of values.  this is where it makes
sense to use a wrapper class override.




[1] and actually you don't even do it yourself, the code created by
Gtk2::CodeGen does that for you.

-- 
muppet <scott at asofyet dot org>