SCons is a rather nice build system written in Python. It compiles many languages, including C and Java. But the problem is that not many people have it, and making your code unnecessarily hard to compile by depending on an uncommon build system is not a good idea. In this article I'll show how you can get your build scripts to automatically download (and cache) SCons as part of the build process...

I've tried installing Klik twice in the past, but the site was down both times. A osnews.com article prompted me to try it again and this time I got it installed.

Klik's main advantage over Zero Install is the large number of packages available for it. Its main disadvantage is that it's totally insecure. However, I've written klik2zero, a little Python script that creates Zero Install packages automatically from Klik ones.

If you compile ROX-Filer on a system with GTK 2.4, it will still work on a system with GTK 2.8. Compile it on a 2.8 system, and it will fail to run with 2.4. This problem isn't specific to ROX-Filer (or to GTK); recent versions of ROX-CLib and programs using it stopped working because they gained a phantom dependency on libglitz. Here's how to avoid these problems...

Federico has written a little Python script to help with profiling Nautilus. I've been wanting something like this for a while so I tried it on ROX-Filer. Turns out that with Zero Install's 0launch command (completely unoptimised Python) parsing a couple of XML files and searching for the best version, plus the filer's initialisation itself, it takes nearly two seconds to start the filer on my machine. Federico's script produced this plot:

I spent a bit of time this weekend hacking on the Xfce panel. The result is that you can now install programs by dragging a URL from a web-browser into the Xfce panel's launcher dialog (much as ROX users do with AddApp). This makes it easy to put ROX applications into your panel; just drag the links from the Zero Install software index to the dialog, as in this screenshot:

My current plans for ROX-CLib are:

• 2.1.8. This was done in March 2006. The major new feature: internationalization support. The messages in ROX-CLib are now translatable, there is a .po file, the .mo files are generated and stored inside the AppDir, and are used when found. Apps get their .mo files loaded if found.
• 2.1.9 was released November 2006. This includes:
  • More support for menus, simplifying the code that needs to be in the app.
  • Extended attribute support.
  • Support for building against GTK 2.4 using Zero Install.
  • 0compile support
• 2.1.10 sometime in the future, including:
  • Improved system tray interface
  • xxmlrpc for communicating with ROX-Session
  • libglade interface similar to that in ROX-Lib.
• 2.2.0, hopefully this will be 2.1.10 deemed stable.

Version 0.18 of 0launch was released yesterday. Notable new features include:

• Signatures in XML comments. This allows us to present feeds nicely in a web-browser, as discussed previously.
• FTP support (not just HTTP).
• Support for extracting from RPMs.
• As an added layer of protection against bugs in tar and cpio, the extraction process is sandboxed using plash, if available.

You can see all these features in action by trying the sample Tgif interface. This interface can be viewed in any web-browser that supports XSLT, and when run it downloads an RPM using FTP, extracts it with plash for sandboxing and then runs it.

I've been spending a bit of time playing with PLASH. Plash is a shell which grants the programs it runs access only to certain files. For example:

$ cat text

Because text appears on the command-line, the cat command is given read access to it (and nothing else). To get write access, you put => before the filename:

$ rm text
/bin/rm: cannot remove `text': Permission denied
$ rm => text
$

You can also give a process access to a file (or directory structure) without also passing its name as an argument. List such files after +, e.g.:

I'm still undecided about how to handle compiling from source with the injector. There are two models I'm considering:

• Each binary interface has a corresponding source interface. Executing a source interface creates a binary package, which can then be added to the binary interface's list of implementations.
• Source is another type of architecture (probably a low-priority one). So, the injector will pick a binary archive for your platform if one exists, or a source archive if one doesn't. Executing a source implementation still runs it, but it just takes longer the first time (sorry, can't remember who suggested this method).

I've added a 'Testers wanted' block to the news, software and developer pages. This shows all programs whose Current testing version field isn't empty. It should also remind people to mark their programs as stable after a while, instead of forgetting about it until the next release (as I usually do).

I've also created a new page type for release announcements (using Drupal's flexinode module) and added a little PHP to put an announce this release link at the bottom of each software page which will fill in some of the fields for you. The release process has been updated (and split into smaller pages).