Posts

Posted on

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.

Posted on

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.

Posted on

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.

Posted on

Ubuntu Linux: followup

I’ve solved the problem with my ATi Radeon 7000 graphic card. I’ll leave this for future reference, you never know…

The Symptoms

ATi Radeon 7000, in combination with an Acer AC711 monitor (17″), just goes wild under XFree86. With the default configuration, X loads with an resolution of 640×480, and a virtual resolution of 1024×768. No matter what modeline I put inside my XF86Config-4 file, and no matter what option I specified for the radeon driver, I could get X to use an higher resolution.

The Solution

The only way of making a ATi Radeon 7000 work with my 17″ monitor was to enable the Radeon framebuffer device inside the kernel (you might want to load the module during the boot sequence, but I strongly suggest recompiling the kernel with the framebuffer device built-in), and change the Device section inside the /etc/X11/XF86Config-4 file like this:

Section "Device"
        Identifier      "ATi Radeon 7000 VE (RV100 QY)"
        Driver          "radeon"
        Option          "UseFBDev"      "true"
EndSection

I’ve highlighted the line you should add

By telling X to use the framebuffer device, the card successfully reaches a usable resolution, and the virtual desktop is gone for good.

Posted on

Ubuntu Linux

Yesterday, I’ve downloaded the first official release of Ubuntu Linux – codenamed Warty Warthog. It seems – as I’ve been reading on Planet GNOME and Planet Debian – that this distro is the Next Best Thing® for desktop usage, so I decided to give it a try (currently, on my box I’m running Debian Unstable with some packages from Experimental).

I’ve turned my Dummy Mode on, and launched the installation. Well, not exactely “turned off” – since I actually had to carefully choose the right partition inside the partition table, in order to keep my precious / intact.

The installation worked pretty much flawlessy: it was better than any installation procedure I’ve done in years; it seemed more like a LiveCD booting than a disk installation.

Unfortunately, here cometh trouble. I’ve a crappy Radeon 7000 graphic card and an Acer AC711 monitor; this combination yields major PITA, since X seems to work only when using the kernel’s framebuffer device, by setting the “UseFBDev” option to “true” inside the /etc/X11/XF86Config-4 file. Ubuntu’s kernel image comes with the Radeon framebuffer device compiled as a module – thus I’m unable to activate it before GDM spawns.

Hence, I’ll have to turn my Dummy Mode off, and recompile a kernel with the radeonfb module compiled statically and invoked inside the kernel command line.

So long for a dummy mode installation.

Posted on

Late Night Hacking

Another night of late hour hacking session.

Trash applet

I’ve hooked up a working version of Michiel’s trash applet; it now has a stub menu entry that recalls the online help, and I also added the possibility to open up a Nautilus window with the trash: URI.

GNOME Trash Applet
Uh oh, time to empty the trash bin…

libgnomepim

I’m still learning ORBit2 implementation of CORBA, in order to write the user daemon serving the GnomePimClient object. I thought about dumping the entire concept of the user daemon and using FAM to watch and update the XML files.

JavaScript

I’ve never learned proper JavaScript programming; I always dissed it, maybe beacuse of the bad habit, in the DotBomb era, of using it for everything (especially when not needed), making web pages practically unusable. Last night I had to write a simple countdown function which periodically updates the content of a XHTML entity; in just ten minutes I grasped the basics of the Document Object Model structure exposed inside the language interpreter, and had my function basically being written by itself. JavaScript (or, better, ECMAScript) surely has come a long way to finally being usable for serious client-side web programming.

Posted on

Trash Applet

Skimming through the gnome-devel list, I found the announcement of a simple Trash applet for the GNOME panel, made by Michiel Sikkes (here‘s the site, with a screenshot).

I think it’s a great idea: sometimes the Trash icon is simply buried under screen clutter, especially with the new spatial paradigm that Nautilus uses. The panel, on the other hand, is always on top.

Since Michiel’s code is something short of a proof of concept, I fleshed it out, adding state recognition, and some menu shortcuts which will open a Nautilus window showing the trash contents, or empty the trash bin. It works pretty well, for a two hours hack. ;-)

This actually is the first time I touch some C code, besides a project for a class final exam, in a very long time – I had almost forgot how much fun is hacking just for fun.

Posted on

Gnome2::Print (and future plans)

Gnome2::Print

It’s been a long way, but in the end the Perl binding for libgnomeprint (and libgnomeprint-ui) has been finally completed. Hurray for me. :-)

I’ve just committed the code that binds Gnome2::Print::Paper and its methods, inside the 0.93 release of the Gnome2::Print module. I began maintaining this module the past august, soon after this email; soon after that, I began the Gnome2::GConf binding, that ended up inside the modules included inside the GNOME Platform Bindings. I’m proud of both, even though I rarely used the Gnome2::Print binding – I’m not really into printing data.

Future

As soon as I return to own my life, after this semester’s finals, I’ll be able to begin working on a GStreamer Perl binding set. I already gave a preliminary look on this library, but didn’t really dig into it. I will also try and complete the GTK2-Perl tutorial, which is still missing a large chunk of chapters.