Re: A couple of small bugs + patches

[Dave Carrigan <dave rudedog org>]

Christian Borup <borup borup com> writes:

> Charlie Schmidt wrote:
>
> > ill leave it to paolo too, but in my opinion is it better to leave it as
> > a GtkWidget.  what if it *ISNT* a GtkMenu (for whatever reason), the only
> > thing that every object *must* be in Gtk is a GtkWidget (ok, sure a
> > GtkObject, but thats opaque).  but whatever.
>
> I don't agree. If it isn't a GtkMenu it should be blessed into whatever
> class it is, having it blessed as a GtkWidget is not helpfull at all.
> The perl programmer should not have to pay for C not having classes...

That's my thought as well. Plus, what I probably wasn't making clear, is
that my patch doesn't coerce the object to be a GtkMenu, it coerces the
object to be whatever its real class is. Gtk appears to have enough
capability for object introspection to identify the object's class and
it looks to me like perl-gtk uses that ability to bless objects into
their proper class (see newSVGtkObjectRef()).

I'm not exactly sure the magic behind this, but if you declare that an
xs function returns a Gtk::Widget, it returns Gtk::Widget. If you
declare that an xs function returns Gtk::Widget_Up, it returns an object
that is the correct subclass of Gtk::Widget.

So, with my patch, if $optionmenu->get_menu somehow returned a
Gtk::CTree, that would be correctly blessed into the Gtk::CTree class.

I'm still trying to figure out exactly how the Gtk::Widget_Up magic
works, as well as figure out what exactly the *_Sink classes are...

Cheers,

-- 
Dave Carrigan (dave rudedog org)            | Yow! It's the RINSE CYCLE!!
UNIX-Apache-Perl-Linux-Firewalls-LDAP-C-DNS | They've ALL IGNORED the RINSE
Seattle, WA, USA                            | CYCLE!!
http://www.rudedog.org/                     |