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:

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).

I've been using subversion (a CVS replacement) to manage the zero-install software ever since SF.net announced they'd be supporting it in the new year (this was in 2004, I think ;-). It's been working well, except that it was on my local machine so no-one else could access it.

SF.net have finally deployed a beta subversion service to certain projects, including zero-install, and they've imported my local repository. You can check out the latest by following the instructions.

You should be able to get the whole thing like this:

$ svn co https://svn.sourceforge.net/svnroot/zero-install/trunk zero-install

It would be good to get the ROX-Filer manual imported into the new site properly:

• Pages would show up in searches.
• We could provide sensible nagivation (not just one big page).
• It would fit in with the style of the rest of the site.
• People could comment on pages.

However, I don't want two copies being edited individually. We need to be able to generate the filer's manual from the web-site copy.

The problem is that Drupal doesn't have an import filter for DocBook (the format used for the manual). Converting to HTML is easy, but that loses the markup and if we do that we can't go back (Drupal's export can't regenerate tags such as 'filename', although it can cope with chapters, I presume).

The new website is nearly ready, but there's one big decision left to make... what shall we call it?

Having 'drupal' in the URLs is a bit silly, as all the URLs will break if we later move to something else (already made that mistake with phpwiki ;-)

Moving it to the top-level could work (e.g. rox.sourceforge.net/ROX-Filer), but there's quite a lot of junk there already which we probably don't want to move in case people are linking to it (we still had rox_filer.php3 linking to the newer rox_filer.html, which redirects to the even-newer phpwiki, which will shortly redirect to drupal... we've been very good at keeping old links valid so far!)