At Thu, 14 Dec 2000 02:23:24 +0900,
Kevin Smith wrote:

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

don't be sorry ;) 

(btw, I wasn't yelling.  it's just that gtk+ use capital in the
source.)

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

hmm.. it doesn't _have to_ be that way.  it just that drawing.rb from
sample is implemented in that particular way.

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

I now understand what you mean.

Gtk+ already have a function gtk_button_pressed() so that Ruby/Gtk
choose to wrap that function with Gtk::Button#pressed instead of using
that method name as default signal handler. (note: Ruby doesn't have
method overloading like java)

Also there is not way for non-C-like language binding to change
default signal handler.  That might change for Gtk+ 2.0.

I remember talking with Hiroshi IGRARASHI on IRC about unifing signal
and method.  but we didn't reach any point nor any code output.

As I said earlier, Ruby/Gtk's signaling system isn't the best. I have
been frustrated, too.

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

yes.  It'd be very nice to learn from libsigc++.

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

well I have had take a look at Gtk-- and libsigc++ before.  slot and
signal concept is nice.  (Qt is also using slot and signal concept,
IIRC.  but with moc)

Problems are that libsigc++ use C++ template, I don't like C++, and
I'm not good at it ;) So, I don't think I will implement Ruby/Gtk-- or
Ruby/Gtk with libsigc++, but if you (or someone else) are willing to
do, let me know. I'd love to see your work.

btw, Keven, could you fold your lines if possible? I don't mind
reading unfold mail with my MUA, but it might help ML archive.  Take a
look at this:

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/7162

regards,
--
         yashi