Edd Dumbill's Weblog: 'gnome' articles

GObject subclassing in Ruby

2006-01-31T20:23:24Z

Thanks to everybody who wrote in with suggestions following on from my initial Ruby GNOME investigations yesterday.

After talking at cross purposes for some time in a bug report with a Ruby GNOME developer, I was pointed to a good example of how to do what I wanted: subclassing a GObject in Ruby.

This is something that the Mono Gtk# bindings do so well, I'd forgotten the required mechanics. Here's a simple subclass of button. I've highlighted the required magic in bold.

class MyButton < Gtk::Button
   attr_accessor :hitcount
   # tell the GLib object system this is a new type
   type_register
 
   def initialize(text)
     super("label" => text)
     self.hitcount = 0
   end
 
   # rather than overriding 'clicked', we must
   # override the signal_do_clicked method
   def signal_do_clicked(*args)
     self.hitcount+=1
     super
   end
 end

The type_register call registers the new class with the GLib type system (something the Mono bindings do for you automatically). The second key was knowing the name of the default signal handler, which turns out to be of the form signal_do_signalname.

So, to follow up yesterday, I hadn't found a bug, merely a gap in the documentation. Thanks to Masao Mutoh for taking the time to answer my questions.

For comparison, here's the same implementation in Gtk#. There are pros and cons of both languages. Ruby's succinct attr_accessor is balanced by the neat GObject-aware subclassing and the constructor inheritance of C#.

class MyButton : Button {
        private int hitcount;

        public MyButton (string text) : base (text)
        {
                hitcount = 0;
        }

        protected override void OnClicked ()
        {
                hitcount++;
                base.OnClicked ();
        }

        public int HitCount {
                get
                {
                        return hitcount;
                }
                set
                {
                        hitcount = value;
                }
        }
}

Join the conversation about this post

Beginnings with Ruby GNOME

2006-01-31T02:37:24Z

A while back I started porting the GTK examples from Mono: A Developer's Notebook to IronPython and Boo, the results of which are available in my Subversion repository.

Although I've not finished that task yet, I thought I'd investigate the state of the Ruby GNOME bindings by porting those same examples. They have the advantage of increasing gently in complexity.

Before I go on, you can find the work in progress posted in the ruby-gnome/monodn branch of my Subversion repository.

Now for a few observations. At the basic level, Ruby GNOME has a lot in common with all the other GNOME bindings out there. One distinguishing feature however is signal handlers, which take a Ruby closure as an argument. Look at this handler for closing the window, for example:

w = Gtk::Window.new("My Window")
w.signal_connect("delete_event") { Gtk.main_quit }

This is fine for simple handlers. Developers wanting to reuse handlers might wish to specify a method here to use. The best way of doing this I've found is:

def my_handler(but)
     ...
end
 
button.signal_connect("changed", &method(:my_handler))

This involves a little bit more magic, as you can see.

I've also run into an unexpected barrier with subclassing and the class default signal handler. The subclassing example from the Mono Notebook shows an example of overriding the clicked method of a Button. In C# this looks like this:

class MyButton : Button {
 ...
 protected override void OnClicked ()
 {
    hitcount++;
    base.OnClicked ();
 }

In Ruby I would write this:

class MyButton < Gtk::Button
 ...
 def clicked
   self.hitcount += 1
   super
 end

However, when you click the button it's clear the overridden method isn't being called. I've filed a bug with what I think is the underlying problem. In this instance, I worked round it by adding a signal handler in the constructor:

self.signal_connect("clicked") { |b| b.hitcount += 1 }

At the moment it feels like I'm writing rather C-like Ruby, rather than it being idiomatic. But then again, I am porting examples from C# in as literal manner as possible, in order to facilitate comparison.

Join the conversation about this post

Linux fonts: still wanting

2006-01-22T16:02:26Z

Fonts on Linux have had a chequered history. Mostly, they've been bad. Once, there was an excuse for this: GNOME and KDE were unable to render anti-aliased text, and there was a paucity of decent free TrueType fonts. Now, with Xft, Freetype and Bitstream Vera fonts things are different.

Unfortunately, it's hard to find Linux distributions that have gone the extra mile to make the fonts look good by default. Let's take a brief look through default fonts in various operating systems.

Mac OS X offers a great default, which looks good on all modern machines. No user configuration required.

Windows default is blocky, as there's no anti-aliasing to speak of, but the hinting on the fonts is excellent and they're crisp. If you dig a bit and find the crazily hidden Display properties - Appearance - Effects dialog, you can turn on ClearType.

Windows ClearType offers a pleasing level of font smoothing. Now, let's look at the GNOME default, taken from a screenshot on the GNOME 2.12 start page.

This is pretty much how default GNOME looks on any machine. In particular, it's the default look you get when you install Ubuntu. This corresponds to a setting of full hinting in the font preferences, with the font Bitstream Vera Sans. The quality of the type, however, is poor. It has a spidery and ungainly quality to it.

In and of itself, Vera is not an ugly font. There's some combination of the font's hinting and the Freetype hinting engine that conspires to make things ugly. On my desktop I've tried to work around this by altering the font settings somewhat.

The effect isn't perfect, but a lot better to look at. The font is Bitstream Vera Sans as before. To get this, I had to switch off any hinting then slowly play with the DPI setting until I get letterforms that rendered neatly.

Alas, this brings problems of its own. For a start, not all popular GNOME applications respect this setting. Firefox often gets its own idea about such matters as screen DPI, and OpenOffice.org2 completely ignores my hinting preferences and gives me nasty looking menu bars. Murray Cumming's recent GNOME for bad eyesight blog post also gets into many of these issues.

For most users without time or inclination to hunt this down the choice is either to live with the ugliness, or opt for an operating system that gets it right.

(Lest I seem churlish here, I should celebrate the amazing work done with internationalization on the Linux desktop, which continues to bring computing access to many in the world for whom choice is a luxury.)

There is one Linux distribution that makes a reasonable job of good-looking fonts. The Fedora Core 4 distribution ships with a different default font and out of the box settings giving reasonably attractive letterforms. Courtesy of OSDIR, here are GNOME and KDE screenshots. However, I'm pretty sure it doesn't solve the rest of the font integration issues.

I'm no typography expert, but I find that good-looking fonts enable me to work more effectively. And on the advocacy side, I want my Linux desktop to look as good or better than the OS X and Windows alternatives.

Lots of great effort was made getting us to the point of anti-aliased rendering and the licensing of the Bitstream Vera Fonts. Having got this far, it seems a shame not to hunt down the remaining irritations in font handling.