>> Keep in mind that this is based on a 10 minute look at Ruby/GTK.  It
>> seems like Ruby/GTK ends up sending something like
>> 'caller.event(widget)', where GTK-- would send 'widget.event'. So in
>> Ruby/GTK I would have to catch the event, and then figure out who it
>> was aimed at, unlike GTK--. I could be wrong.
>
>I might be wrong, but in Gtk+ world, 'event' is something that your
>window system send to your application.
>
>We have Gtk::Widget#event but that just maps gtk_widget_event.  and
>this method takes event, not a target widget. (btw, gtk_widget_event
>is marked as "INTERNAL FUNCTION")

Sorry. I was speaking generically, not about a specific method named 'event'. Let me dig up the sample code to explain myself...Ok. from drawing.rb:

signal_connect("button_press_event") { |w,e| pressed(w,e) }
...
def pressed(widget, ev)
...

This seems to say that both the widget and the event will be passed to the pressed method, which will then have to delegate the event to the appropriate widget. Instead, I would expect to be able to connect "button_press_event" for a given widget to the widget itself, causing widget#pressed(event) to be called. Perhaps I'm missing something because the example is so brief.

>if those events and signaling system are what make Gtk-- more OO than
>Ruby/Gtk, lets create better signaling system for Ruby/Gtk ;)

Because the GTK-- folks have already thought it through, and it would be nice to be able to leverage existing GTK-- documentation. If it's easier to re-wrap GTK+ directly in a GTK-- style than it is to wrap GTK--, that sounds fine to me.

Perhaps you could take a quick look at GTK-- and see what you think. I would be very interested to hear your opinion. Their homepage is gtkmm.sourceforge.net. Hmmm...looking at some GTK-- source now, it seems cryptic, but if you know GTK+ it's probably more comfortable. I like GTK-- because there are several OO wrappers for GTK+ and it seemed like it was the most popular and best supported.

Kevin