Up North

I ran into a slight problem when I tried to create a type registered subclass in Ruby/GTK+. This is done by adding type_register in your class definition. This worked fine until I tried to pass arguments to the super class constructor through the super() call.

In my previous example, I passed the arguments like usual to the super call. It turns out that when you have registered your class with the GObject type system (which I didn’t do in that example) it overloads the super() call and you need to pass the arguments as a hash instead.

Here is an example subclassing Gtk::Button that sets the button up defaulting to underline mnemonics.

require 'gtk2'

class MyButton < Gtk::Button
  type_register

  def initialize(label)
    super({:label => label, :use_underline => true})
  end

  def signal_do_clicked(*args)
    puts “Clicked”
  end
end

w = Gtk::Window.new

b = MyButton.new(”My _Button”)
w.add(b)

w.signal_connect(:delete_event) do
  Gtk.main_quit
end

w.show_all
Gtk.main

Kudos to Kou for showing how to do it.

It’s not only in the upstream GTK+ project that there has been a lot of happenings lately. The Ruby GTK+ bindings team got a new maintainer after the old maintainer Masao Mutoh decided to step down and turn the reins over to .

Kouhei seems set on doing a new, much anticipated release of the bindings as soon as possible. The last release was done over a year ago (2006-12-29) and a lot of improvements have been done after.

I’d like to extend my thanks to both Masao and Kouhei for their efforts and willingness to take care of maintaining the bindings for this excellent language.

I also raised the question about moving the project over to GNOMEs infrastructure to get closer to upstream development and make it easier for people to participate. The suggestion seems to have been well received and many have said that they would love that. I’m pretty sure it would put some more light on the project and help the continued development positively.

Davyd is spot on when bringing up the use of subclassing in GTK+. This is a step that comes natural for most people used to OO programming but (probably due to having to write a lot of boiler plate code) often is neglected by GTK+ application developers.

While many feel it’s daunting to subclass GTK+ widgets in C, it can be really nice when writing applications in other languages. Just like Davyd showed, Python is such a language, so is Ruby which I will show a similar brief example of here for those that are trying to get into Ruby/GTK+.

require 'gtk2'

# Defining OpenFileDialog
class OpenFileDialog < Gtk::FileChooserDialog
  @@CWD = nil

  def initialize(parent_window)
    super("Open file", parent_window,
          Gtk::FileChooser::ACTION_OPEN, nil,
          [Gtk::Stock::CANCEL, Gtk::Dialog::RESPONSE_CANCEL],
          [Gtk::Stock::OPEN, Gtk::Dialog::RESPONSE_OK])

    self.default_response = Gtk::Dialog::RESPONSE_OK

    self.current_folder = @@CWD unless @@CWD.nil?

    signal_connect :response do |dialog, response|
      @@CWD = self.current_folder if response == Gtk::Dialog::RESPONSE_OK
    end
  end
end

# Using OpenFileDialog
2.times do
  d = OpenFileDialog.new(nil)

  d.run do |response|
    puts "filename = #{d.filename}" if response == Gtk::Dialog::RESPONSE_OK
  end

  d.destroy
end

The second half simply to try it out. For a nicer paste, see http://pastie.caboo.se/148847.

But it’s so hard in C!
Writing all the boilerplate by hand is a lot of work and error prone. However, here are two tips for making life easier.

The first way is to implement a dummy object that you later copy and query/replace. A nice tool for using this method is Regexxer) that lets you easily change the dummy name into your object name. I suggest you hook up your dummy object in the Makefile in order to make sure it always builds.

The other solution is to use a generator script such as Spuug to generate all the boilerplate for you. It makes it very easy to create new subclasses when you need them.

Update: As Johannes pointed out in a comment, Anjuta also comes with a generator for subclassing.