Blockers when subclassing Gtk::Container

When subclassing Gtk::Container I’ve found that overriding “abstract”
methods seems to go unnoticed by the underlying gtk system…

When I override Gtk::Container#add and do child.parent=self inside it I
get
this:

/usr/lib64/ruby/site_ruby/1.8/rubygems/custom_require.rb: line 27
Gtk-WARNING **:GtkContainerClass::add not implemented for `FooTest’

This message is generated by the “abstract” add method
(gtk_container_add_unimplemented()) in gtkcontainer.c and it tells me
that
Ruby-GNOME2 has not updated these function pointers when I call
type_register in the ruby class definition of FooTest.

Likewise, it seems that my overridden Gtk::Container#size_allocate and
Gtk::Container#size_request methods are not called by my FooTest
object’s
parent.

I’ve attempted to hunt down this problem myself, but I’m not sure where
to
go next; I’ve noticed that the only two implementations of type_register
are
found in the C code for GLib::Object and Gtk::Container and that there
are
only subtle differences in how they function. I’m pretty sure it’s meant
to
either update the function pointers or install some hook that update
function pointers when abstract methods are added to a Gtk::Container
subclass, but I can’t find evidence that this has even been implemented
yet?

On 8/20/07, wo boo [email protected] wrote:

This message is generated by the “abstract” add method
(gtk_container_add_unimplemented()) in gtkcontainer.c and
it tells me that Ruby-GNOME2 has not updated these function pointers when I
call type_register in the ruby class definition of FooTest.

Can you paste your FooTest code somewhere?


Guillaume C. - Guillaume Cottenceau


This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Hi again. Digging through the mailing list for an answer to my problem,
I
found the “treemodel” discussion from mid-July 2007. Can anyone confirm
or
deny my suspicion that my problem extending Gtk::Container is related to
this? That is, overriding any existing method for a native GTK class
will
leave it in some “meta state” where Ruby code calling Gtk::Container#add
will (in the correct manner) call the overridden Ruby method, but any
GTK
library C code doing gtk_container_add() on the same object will instead
get
the super-method - the native method for the GTK class?

I’m very interested in finding a general solution for this and possibly
help
implementing it. The “treemodel” thread also mentioned that there were
problems with the Ruby garbage collector. Can anyone elaborate on this?
I
don’t see how overriding methods is a lot different from installing
signal
handlers, which seems to work just fine. In both cases Ruby-GNOME2 will
callback to Ruby code based on something that happens internally in the
native GTK library.

I’ve posted an example of subclassing Gtk::Container that does not work,
here:

http://pastebin.com/f1171f0ee

and here it is in plain text:

require ‘gtk2’

class Foo < Gtk::Container
type_register
def initialize
super()
set_flags Gtk::Widget::NO_WINDOW
end
def add child
# !! following code generates this warning: “Gtk-WARNING
**:GtkContainerClass::add not implemented for `Foo’”
child.parent = self
end
def size_allocate
# this method should be called by gtk subsystem, but it isn’t
puts “called size_allocate”
end
def size_request
# this method also should be called by gtk subsystem, but it
isn’t
puts “called size_request”
end
end

class App < Gtk::Window
def initialize
super()
foo = Foo.new

    button = Gtk::Button.new("hello")
    foo.add button

    add foo
end

end

app = App.new
app.show_all
Gtk.main