Question about Gtk::Builder and connect_signals

Looking at the source code of Gtk::Builder#connect_signals, I see
the following code:

  def __connect_signals__(connector, object, signal_name,
                          handler_name, connect_object, flags)
    handler_name = canonical_handler_name(handler_name)
    if connect_object
      handler = connect_object.method(handler_name)
    else
      handler = connector.call(handler_name)
    end
  ...

This suggests that its possible to connect a ruby object
“connect_object” to a Gtk object defined in a glade file. How does one
do this?

I was going to subclass Gtk::Builder and implement my own
connect_signals so I can do this, but maybe there is already a
better way?

Jon R. wrote in post #1028799:

Looking at the source code of Gtk::Builder#connect_signals, I see
the following code:

  def __connect_signals__(connector, object, signal_name,
                          handler_name, connect_object, flags)
    handler_name = canonical_handler_name(handler_name)
    if connect_object
      handler = connect_object.method(handler_name)
    else
      handler = connector.call(handler_name)
    end
  ...

This suggests that its possible to connect a ruby object
“connect_object” to a Gtk object defined in a glade file. How does one
do this?

I was going to subclass Gtk::Builder and implement my own
connect_signals so I can do this, but maybe there is already a
better way?

I’m not sure what you expect, but maybe you can look at this discussion
I had with Michal :
http://www.ruby-forum.com/topic/2488975

We disagree, but afaik, nothing has changed, and it’s somewhat what you
are trying to do.

regards

Simon

Simon A. wrote in post #1028945:

I’m not sure what you expect, but maybe you can look at this discussion
I had with Michal :
http://www.ruby-forum.com/topic/2488975

We disagree, but afaik, nothing has changed, and it’s somewhat what you
are trying to do.

Thanks Simon. I did see that discussion, but I think I’m too new to Gtk
programming to understand the discussion completely.

For what its worth, the way I solved my problem was to add a small layer
to my Gtk::Builder subclass that does two things… first I add the
ability to attach a Ruby object to a named Gtk object from the glade
file. Then, in the connect_signals code, I look to see if an
attached object exists for the Gtk object, if so, I automatically
connect a method with the same name as the handler if it exists. If it
doesn’t exist or if there is no attached object, it calls the block as
before, but instead of only passing in the handler name, it also passes
in the Gtk object and the signal name.

This gives me as much flexibility as possible and still be able to keep
the code simple. I’m not sure about user data, as I’m not entirely
clear what its used for, but maybe my solution gets around the need for
them?

I can post my code if it helps.

Rather than wait, I may as well just post the code in case its something
that others may find useful at some point. Feel free to add
suggestions.

(note that this is a work in progress… should ignore the stuff below
the TODO: section at the bottom)

Jon R. wrote in post #1028799:

This suggests that its possible to connect a ruby object
“connect_object” to a Gtk object defined in a glade file. How does one
do this?

I was able to answer my own question… The idea is that in the Glade
designer, its possible to associate another object in the window as the
recipient of the signal. The idea is that you assign an object to the
signal handler and the handler name should match the name of a function
provided by the object. This allows you to handle a signal without
writing any code.

This means that we are still left with no way in Ruby-GNOME2 to assign a
signal handler based on the object and signal its associated with. This
is easily accomplished by passing these as parameters to the
connect_signals block.

Since adding these to the connect_signals block doesn’t affect existing
implementations, I’d like to propose that we add these to the
Ruby-GNOME2 project.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs