Guadec 2005

All set and done.

After a bit of struggle between PayPal and my credit card, I filled the registration for this year’s GUADEC, that will be held in Stuttgart, Germany.

GUADEC Registration

Stuttgart, here we come…

DBus Perl Bindings/2

After four hours straight of hacking, double-checking references, learning D-Bus and the intricacies of Perl XS programming, I have a preliminary draft of perl bindings for D-Bus.

At the moment, they do nothing, since there isn’t much more than the DBus::Connection object, but they are loading correctely, and the approach is right.

The API should resemble the C one, with a perlish twist. A simple service lister program should be:

  use DBus;
  # we could use this class method...
  my $bus = DBus->get_session_bus;
  # or just the DBus::Bus class...
  #my $bus = DBus::Bus->get('session');
  # the result is the same: $bus will contain a reference to the session bus.
  # but it is also a perl hash reference, so it could hold something, such a string:
  $bus->{service} = 'org.freedesktop.DBus';
  # then we could use them in order to get a service
  my $service = $bus->get_service($bus->{service});
  # $service is also a perl hashref, so we could use it to store some more strings:
  $service->{path} = '/org/freedesktop/DBus';
  $service->{interface} = 'org.freedesktop.DBus';
  # and the get the object:
  my $object = $service->get_object($service->{path}, $service->{interface});
  # here's the remote method call:
  print "Service: $_\n" foreach ($object->ListServices);
  0;
dbus-perl screenshot
Obligatory screenshot of the bindings

I plan to make the low-level bindings work as soon as this weekend.

Future plans: creating a DBus::Object::Subclass pragmatic module, similar to Glib’s Glib::Object::Subclass, that permits the creation of D-Bus aware objects. This could be tricky, but I’m really optimistic.

Glib::KeyFile/2

After being in Florence with Marta for just about two days, I’ve received the “go ahead” from the gtk2-perl team, and committed my patch for the GKeyFile bindings (closing bug #301171). Now you can parse the .desktop files directly in Perl. Hurray for me.

Gtk2::Recent and recent-files

Gtk2::Recent status: Finally, the libegg/recent-files bindings for Perl hit the gtk2-perl CVS server (well, at least the authenticated CVS server; anonymous CVS should be updated in 24 hours).

recent-files status: On a related note, I mailed James Willcox (the recent-files maintainer), asking him if this library is still actively maintained, and stepping up for help (triaging bugs, reviewing patches, applying them, and possibly development).

I’ve some ideas, like the creation of a Gnome library based on the actual recent-files code, depending on libgnomevfs and some other stuff, which monitors the recent files file and their state (if local, with the option for remote file checking, maybe using a GConf preference). It will have a RecentMenu widget, composed of RecentMenuItems, for visualization – thus simplifying the code:

  RecentModel *model = gnome_recent_model_new (RECENT_MODEL_ORDER_MRU);
  GtkWidget *menu = gnome_recent_menu_new (model);
  GtkWidget *menuitem = gtk_image_menu_item_new (GTK_STOCK_CLEAR);

  g_signal_connect (G_OBEJCT (menu), "activate", G_CALLBACK (on_recent_activate), NULL);
  g_signal_connect (G_OBJECT (menuitem), "activate", G_CALLBACK (on_clear_activate), model);

  gnome_recent_menu_set_show_trailing_separator (GNOME_RECENT_MENU (menu), TRUE);
  gnome_recent_menu_append_item (GNOME_RECENT_MENU (menu), menuitem);

  gtk_widget_show (menuitem);
  gtk_widget_show (menu);

Then, you could simply attach this menu as a GtkMenuItem submenu.

Future plans: See here for some neat ideas (not from me) about the recent stuff handling.

Glib::KeyFile

I began working on a perl binding for the key file parser inside Glib. I have an implementation almost ready, albeit not usable right now.

I’d like to translate a key file structure to the more perlish equivalent of an associative array; that is, I want to translate this:

  [Section]
  # comment
  stringkey=astring
  intkey=42
  boolkey=false

Into this:

  print $keyfile->{Section}->{comment}; # prints "comment"
  print $keyfile->{Section}->{intkey}; # prints "42"
  ...

While skimming through the gkeyfile.[ch] files, I’ve also noticed that you can’t create a key file in code, even though the infrastructure is in place (you can create an empty object, and you can remove groups and keys from a filled object). Thus I’ve created a bug inside Gnome’s bugzilla with a proper patch to expose the addition of groups and keys (here). I’ll notify the gtk-devel mailing list, and see if someone wants to review (and apply) my patch.

On the language binding friendlyness side, I’ve also made a patch that transforms the GKeyFile structure in a reference counted object, but I won’t submit it, since it seems that no structs inside Glib core are refcounted. Pity, but I learned something new.

gtk2-perl lives!

I’ve put up a stub page for the gtk2-perl bindings on the Gnome Live! wiki.

I’ll soon fill it up with pointers to developer resources, programs and tutorial. I’d like that every gtk2-perl developer use it for public coordination and planning, instead of relying on private email and the mailing list.

DBus Perl Bindings

I’m the process of writing the Perl bindings for DBus, <ad-campaign-mode>the New! And! Improved! IPC mechanism, which is spreading throughout the entire Linux desktop scene</ad-campaign-mode>.

Since I’m binding the GLib interface, the choosen namespace is DBus::Glib; I also plan to add the low-level stuff inside the DBus namespace.

I’ve used the gtk2-perl code generation environment, in order to strip down the development time, but since it requires the Gtk2 perl module (and, thus, the gtk+-2.0 library), I was planning to re-create some stuff by hand.

The DBus perl bindings, aside for the general usefulness of having a complete binding set for DBus, are what I plan to use in order to “understand” DBus – since I’ll use it for another project. What’s that project about, I’ll leave it for another post.

GConf’s User Interface

Last month I have found some time to hack again on the Gnome2::GConf module, the Perl bindings to GConf. IOI wrapped the GConfEngine low-level stuff, and rewrote the entire error handling layer.

While I was at it, I began thinking of a simple Perl module containing GConf-bound widgets, as a commodity module. The code itself was pretty much trivial, but as soon as I began working on it, I began feeling that a more complex approach was in order. I coded a GInterface in C, in order to implement it in Perl – but that would have required a modified version of GConf, dependent on Gtk.

Therefore, I started working on a complete C library, connecting GConf to Gtk and, with a serious lack of imagination, I called it libgconfui.

The GConf-bound widgets are, for now, a Entry and a Label; but I’ve also implemented something neat: a configuration group, which is an object to which we add a set of configurable widgets. If the state of a widget inside the group changes, the entire group might commit its contents to GConf, or to a GConf changeset. This would mean that creating a preferences dialog, either using the implicit or the explicit apply paradigm, should be easy enough to do. You should just bind a GConf key to a configurable widget, and BLAM!, each changes is handled by libgconfui.

GNOME Keyring Kills Babies

I’ve just downloaded the gnome-keyring-manager application, written for the GNOME Love effort, in order to see its new UI; along the way, I decided to give a look to the gnome-keyring library.

The more I look at gnome-keyring.h, the more I regret had having breakfast this morning.

Using gpointers all over the place, no GObjects, no signals and properties, basically impossible to bind it for the usage with other languages apart from C. It looks like someone took each point I dislike in the current GNOME-VFS implementation in order to build a library.

It’s utter madness, and lack of proper software engineering, that which drives this library; and its authors really did propose it for inclusion in the Developer Platform? For Sauron’ sake, do not include it!

I know it’s meant to be a private library, but please: we should try to enforce a certain coding policy for GNOME libraries, even private ones like this; as it is, gnome-keyring is something I’d like not to touch with a ten-feet pole.