Avant Window Navigator (Awn) 0.4 Progress Report: June 2009

I've been a bit quiet about Awn in my blog. This is partially because I've been working on two major areas: libdesktop-agnostic and Vala/GObject Introspection (as explained in my previous post, On Bindings).

Since my work on libdesktop-agnostic is directly related to Awn, I'll address it here (even though it may be boring to most of you). I currently have abstractions for configuration, desktop entries, and virtual file systems (e.g., GIO). The area that needs the most work currently is the configuration support. What will ultimately happen is that there will be a class which lets you have per-instance configuration for a given app(let), regardless of the backend that is being used. What this means is that Awn users won't be shackled to using GConf if they want a stable dock. Plus, if a user wants to switch backends for some bizarre reason, they don't have to recompile Awn to do so. Obviously, they'd have to migrate the settings themselves, but that's the price one pays.

Anyway, on to Awn. Here's a screencast I took (CC-BY-SA 3.0 licenced!) of a development version of Awn in an Ubuntu Jaunty virtual machine (hooray for VirtualBox!):

(Direct link to YouTube video)

The bar colors are kind of ugly, mostly because I was testing some of the color-related code on that VM.

Obviously, the features shown in the video (orientation, panel style, and applet loading indicator) aren't the only new features in 0.4. I'll be showing off more shininess in successive videos.

Moonbeam has covered most of the current status of Awn 0.4, which I will repeat here, briefly, for those of you who are scared of clicking on links:

• Moonbeam is working on an API that allows applets to have text and graphics overlay the applet icon. Think Awn plugin support for applets.
• He is also rewriting Awn System Monitor so that one can monitor multiple things from the dock, among other things.
• Certain panel/task animations still need to be implemented.
• Plugin (not applet) support still needs to be implemented.

I'd like to take a moment to talk about the Awn plugin system, particularly to those who actually write the plugins. The D-Bus plugin API that was in 0.2.x and 0.3.x will be deprecated in the 0.4 series, and removed in the 0.6 series. There will be a new API in the 0.4 series.

With regards to what I'm working on - in addition to libdesktop-agnostic integration, I will most likely be working on implementing the D-Bus plugin API, once Moonbeam is done with the API mentioned above.

On the Awn Extras front, I have the Garbage applet waiting to be added. This is waiting on Vala support being re-activated (which is dependant upon adding GObject Introspection support to Awn), and porting the applet to the 0.4 API. There is also an rTorrent frontend and a social aggregator applet that I have on the backburner (both written in Vala), which may or may not make it into 0.4.0.

And finally, a note for Ubuntu users: we are not making available PPA builds of 0.4 until there are no feature regressions in the rewrite. This release is targeted for the official Karmic Koala repositories, just as 0.3.2 was targeted for the Jaunty Jackalope repositories. We anticipate building packages for Hardy and above.

Remember, the best way to keep track of new developments in Awn/Awn Extras is to subscribe to Planet Awn. Be with us next time for "Autohide and Seek", or "The Incredible Shrinking Dock"!

On Bindings

One of the more interesting areas in software development, to me at least, is language bindings. Being able to interface with a library written in one language in another language is kind of satisfying, as it allows me to develop without having to reinvent the wheel. There are two specific projects that I use and work on so that I can enhance the software that I develop: GObject Introspection (G-I) and python-spidermonkey.

GObject Introspection

As a quick overview, the goal of this project is to give C libraries the tools to provide enough metadata about their API so that bindings can be written with minimal effort. Given the time and effort that I have put into maintaining the Awn bindings, it is not very surprising that I would be willing to help out getting this framework working for Awn. My ultimate goal is to eliminate the bindings/python folder in the Awn source tree. It is basically a mixture of a Scheme definition file plus a very bizarrely formatted "override" file for custom definitions, all integrated into autotools to produce a C library that is ready to be dynamically loaded into python via import. To meet this goal, I am contributing to the PyBank project, which is a prototype Python module that interfaces with the GObject Introspection library to read compiled library metadata files (called "typelibs") on the fly so that classes, functions, etc. can be loaded and called at runtime. In addition to myself, a Google Summer of Code student and a Sugar Labs developer are also working on the module, with Johan Dahlin overseeing it all. So far, I've contributed a unit test suite, ported from the gjs project (JavaScript bindings for GLib-based libraries based on the Spidermonkey VM) and working type bindings for various simple types (e.g., int64 and float).

I have also put some coding effort toward G-I integration in Vala. Vala supports G-I by both reading GIR files (the XML serialization of G-I metadata) to produce VAPI files (short for Vala API files), and writing GIR files when producing a library written in Vala (e.g., libdesktop-agnostic). I have contributed mostly what amounts to workarounds in the GIR reading code, with regards to Vala/G-I behavioral inconsistencies. Didier 'Ptitjes' has done much, much more solid work than I have on both fronts, which I greatly appreciate.

python-spidermonkey

This project, as the README states, lets you [execute] arbitrary JavaScript code from Python[, and allows] you to reference arbitrary Python objects and functions in the JavaScript VM. As I've stated in an earlier blog post, I use this in my custom website build system to both validate and pack my JavaScript code, via JSLint and Packer, respectively. Since I published that post almost two years ago, that project was revived twice - once by a Mozilla employee (and co-founder of Humanized, which is quite awesome) named Atul Varma, and the latest incarnation is on github. Since it is based on the original implementation in C, and not the Python-based ctypes version, the Base2 recursion problem does not exist, and so I have happily written modules and scripts which wrap the two JavaScript utilities. Recently, I have made them available in a public project on Launchpad called python-jsutils. I haven't really announced it until now because it currently relies on a change I made to python-spidermonkey which allows one to iterate over a JavaScript array, instead of having to write "unpythonic" code like for x in range(0, len(foo)): #.... While it is in my fork, it has not been merged to the "official" repository.

Announcement: OAuth Client Library

For the past week or so, I've been working on various web services-related libraries, in the hopes of writing some sort of Launchpad dashboard applet for Awn. I think it would be nice to have new/recently changed bugs in Awn/Awn Extras at a glance in the dock, among other things. The first somewhat complete component is an OAuth client library. I finished the initial implementation (plaintext signature only) in under nine hours, and after the Awn 0.3.2 release (and a bit of frustration), I added HMAC-SHA1 signature support with the help of RFCs 2104 and 2202 (using GLib's checksum API). I've tested it with both the OAuth example Python server and the Launchpad API.

Also included in the source are two small test programs: one tests the HMAC-SHA1 implementation, and the other tests the OAuth implementation in its entirety. The latter uses .ini-style config files to define keys/secrets/URIs/etc. for a service.

There are a few things that still need to be done, in order for it to be a "complete" implementation. I probably want to replace my handwritten HMAC-SHA1 implementation with a libgcrypt-based one (although I'd have to figure out how to create bindings for Vala), which would also enable me to add RSA-SHA1 signature support. Additionally, I should probably add an asynchronous equivalent to the current synchronous API. Finally, it would be nice if it integrated better with libsoup's existing authentication structure. Currently, I just generate an Authorization: header to be manually added.

The next component I'm working on is a WADL dispatcher library. I don't like the idea of a library generating code (as I presume wadl2java does). We'll see how this turns out.