Mood to Burn Bridges

Whoa, really long time no blog.

I can’t say I’ve been really busy with GNOME-related stuff: work mostly blocked me from doing much. After GNOME 2.16 I’ve released gnome-utils 2.16.1 containing a couple of fixes to Screenshot, and one of them was written by Ross; I’ve also released not one, not two but three versions of the Gnome2::GConf perl module wrapping GConf, two of them today, thanks to the awesome work of Laurent Simonneil, who provided two patches for fixing the schema objects handling and for wrapping the recursive unsetting in the Gnome2::GConf::Client class. Those two patches are what Laurent needed for creating a FUSE-based file system (written in Perl using the FUSE and GConf bindings) for browsing the GConf database.

You can find the latest releases of Laurent’s GConf-FS, as well as the latest Gnome2::GConf module release, on CPAN.

now listening: Neko Case, Furnace Room Lullaby

Documentation

Davyd, the GTK+ Perl bindings come with documentation in the perldoc format (which works upon man); each object has its unique perldoc page, so if you need to know all the methods of the Gtk2::TreeView widget, all you have to do is open a terminal and type:


$ perldoc Gtk2::TreeView

And you’ll be greeted by a screenful like this:

TREEVIEW(1)         User Contributed Perl Documentation        TREEVIEW(1)

NAME
       Gtk2::TreeView

HIERARCHY
         Glib::Object
         +----Glib::InitiallyUnowned
              +----Gtk2::Object
                   +----Gtk2::Widget
                        +----Gtk2::Container
                             +----Gtk2::TreeView

INTERFACES
         Glib::Object::_Unregistered::AtkImplementorIface

METHODS
       widget = Gtk2::TreeView->new ($model=undef)

           * $model (Gtk2::TreeModel)
...

Support of man pages, by the way, is sorely missed inside GTK+ itself: instead, you’ll have to use devhelp or point your browser to a long URI; I love devhelp, but I’m usually coding (with) development releases of many libraries, all installed inside a jhbuild sandbox so in order to make it find the autogenerated API documentation you’ll have to build devhelp inside the sandbox too – which is unnecessary pain I’d like to avoid inflicting upon myself.

Anyway, perldoc to the rescue: at the end of the object page you’ll find the SIGNALS section – if the object’s class exports signals, that is – which looks like this:

SIGNALS
       set-scroll-adjustments (Gtk2::TreeView, Gtk2::Adjustment, Gtk2::Adjustment)
       row-activated (Gtk2::TreeView, Gtk2::TreePath, Gtk2::TreeViewColumn)
       boolean = test-expand-row (Gtk2::TreeView, Gtk2::TreeIter, Gtk2::TreePath)
       boolean = test-collapse-row (Gtk2::TreeView, Gtk2::TreeIter, Gtk2::TreePath)
       row-expanded (Gtk2::TreeView, Gtk2::TreeIter, Gtk2::TreePath)
       row-collapsed (Gtk2::TreeView, Gtk2::TreeIter, Gtk2::TreePath)
...

As you can see, you have the signal name, the arguments of the callback and the eventual return value. The “gotcha” is that there are no named arguments, so you’ll have to know the C counterpart of the signal; this might be a worthy addition to the API documentation generation module.

Another dirty trick is to use the Data::Dumper module inside a callback you don’t know which arguments passes:


sub my_unknown_callback {
    use Data::Dumper;

    print STDERR Dumper(@_);
}

Which will print whatever the callback gives you – even descending into hashes and arrays if it knows how to print their contents.

If you don’t want to use a terminal and the perldoc command, there’s the Gtk2::Ex::PodViewer widget on CPAN, which comes with a podviewer application which you can use to browse the entire Perl documentation available on the system,or you can download PodBrowser which does a bazillion things more.

Tap Dancing on a Mine

I’ve just released version 1.031 of the Gnome2::GConf Perl module binding libgconf. In this release, thanks to Laurent Simonneau, I dropped the Gtk2 dependency, making Gnome2::GConf depend only on the Glib Perl module (and the libgconf C library, obviously).

Gnome2::GConf is mostly in maintenance mode these days so, even if this is supposed to be a development release there are no known issues preventing it from working in a stable environment. I don’t plan any more releases in this development cycle (remember that Gnome2::GConf is part of the GNOME Platform Perl bindings and as such it follows the GNOME release schedule) unless upstream API changes.

You can get Gnome2::GConf either from Sourceforge.net or from CPAN (as soon as both update their state).

On a releated note: as the next release of Gtk2 will support GTK+ 2.10, and it’ll have printing support, I plan to discontinue the Gnome2::Print module binding libgnomeprint and libgnomeprintui; obviously, I’ll still maintain this module, but I don’t plan making any new releases unless for (serious) bug fixing.

Glib::Builder

I’ve began working on a new build environment for Glib, Glib::Builder.

Glib should use it, and provide it for Gtk2, Gnome2 and the other Perl bindings; well, hopefully, and when it’s finished, that is. It should also supercede not only ExtUtils::Depend but also Glib::MakeHelper and a bunch of the code we are currently using inside our Makefile.PL files. Also, it should be easier for us to port a single module to Module::Build, if we ever decide to ditch ExtUtils::MakeMaker.

How does it work?

Simply by using the right tool for the job – that is Perl and pkg-config. Each Glib-based extension will provide a pkg-config file, and inside it will export some variables useful to retrieve all the stuff that currently is exported by ExtUtils::Depend; using pkg-config we can make all these data available to every project out there that can’t rely on ExtUtils::Depend – like the programs exporting an embedded Perl interpreter (gedit, gaim, xchat, etc).

How should it look like?

This is how the Makefile.PL for a Perl module named Foo::Bar, and binding libfoo-bar would look like using Glib::Builder:

  use Glib::Builder;

  # optional code generation using Glib::CodeGen goes here

  my $build = Glib::Builder->new(
      MODULE_NAME => 'Foo::Bar',
      VERSION_FROM => Bar.pm,
      PKG_REQUIRES => {
        'bar-2.0' => '2.0.0',       # C library we depend on
        'glib-perl-2.0' => '1.100', # Perl bindings for Glib
        'gtk-perl-2.0' => '1.100',  # Perl bindings for GTK
        'foo-perl-1.0' => '0.800',  # Perl bindings for Foo
      },
      XS_FILES => @xs_files,
      PM_FILES => %pm_files,
      TYPEMAPS => qw(foo-bar.typemap),
      PKG_CONFIG_FILES => qw(foo-bar-perl-2.0.pc.in),
      DOCTYPES => 'foo-bar.doctypes',
      COPYRIGHT_FROM => 'foo-bar-copyright.pod',
      ENABLE_API_DOC => 1,
    );

  $build->create_build_files if $build;

As you can see, every dependency check is done using pkg-config, which resolves for us all the stuff needed for creating the dependency chain. Glib::Build checks if the pkg-config file exports a specific variable, named perlincludedir, which should be exported by Perl wrappers for Glib-based libraries; the location inside this variable should hold all the typemaps, doctypes and header files needed for inheritance. Another variable, named perllibdir will include the location of the shared objects needed for compiling. The Foo::Bar module would also allow other modules to access its exported data by providing a pkg-config template file, which will create a pkg-config file with all the locations automagically resolved.

This will allow the creation of modules embedded into other Glib-based projects, just by using pkg-config and some auto-foo magic; Glib::Builder could even supply some m4 macros for it, or some Perl script to be used inside Makefile.am or configure.ac files.

All neat and stuff, but where’s the code?

Still living in my source tree. I plan to hack on it this month, but I’ve also got this semester’s finals, and some other stuff going, so I can’t really promise a release date. I really want this to be done, though. Also, since Glib, Gtk2 and the other gtk2-perl modules require special code, I’ll have to add functions for it, in order to keep their Makefile.PL as similar as possible to the template Makefile.PL: those are not (so) special cases of Perl wrappers, so I don’t want them to be treated as such.

Gnome2::GConf 1.021

The “An Address Indicates Where It Is” release.

New release of the Perl bindings for GConf, in time for the incoming GNOME 2.13.4 release.

This version sports a bindings for the Gnome2::GConf::Engine::get_for_addresses method of the Gnome2::GConf::Engine class; this method allows the creation of a Gnome2::GConf::Engine for a list of addresses. Many thanks to Laurent Simonneau for letting me know that the method was missing.

The get_for_addresses method was added in the GConf 2.7 cycle, and if you compile Gnome2::GConf against a newer GConf version, you’ll get it. You should be extra careful with it, and check for its usage, since I can’t test it (as well as all the Engine-related methods) using the automated testing platform we use for all the Perl bindings. But, hey: that’s what beta releases are for, aren’t they?

You can find the tarball of this release on the gtk2-perl project page at SourceForge, and hopefully you’ll find it on CPAN too.

[]
[]
[]
[]