Re: A couple of small bugs + patches



On 03/01/01 Dave Carrigan 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()).

Thanks Dave for pointing out the bug.
The return value from an XS function should be of the expected type,
if we know it (optionally with an appended _OrNULL if it can return NULL). 
So if the function can return only a Gtk::MenuItem or NULL, we should use:

Gtk::MenuItem_OrNULL
get_active(menu)
        Gtk::Menu       menu

that is the actual code I'm going to commit.
Using Gtk::Widget_Up has the same effect from the perl code side of things, but
my solution will provide for more useful automatically created documentation:-)
Obviously, Gtk::Widget_Up is the correct solution if we don't know the type
of the object returned from a function.

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

There is a hash table that maps Gtk+ object types to perl package names,
so the magic is to get the type of the widget, do a lookup and bless
the reference (there are corner cases, but that is it, basically).
Anyway, I'm probably going to make the output object types be *always*
blessed in the most descendent class, because I see no reason for
the current behaviour (maybe if Kenneth reads this he can comment on
why it was done that way).
The Sink variants are there to handle the gtk+ refcounting issues:
you may want to read docs/refcounting.txt in a gtk+ source directory.
Basically a widget is floating when it's created (its reference count
of 1 belongs to no one) and it gets sunk when it's added to a container
(the container takes ownership of that reference count). If the widget
is created and returned to perl, perl takes ownership of that reference
count instead.

lupus

-- 
-----------------------------------------------------------------
lupus debian org                                     debian/rules
lupus ximian com                             Monkeys do it better




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]