XUL ain't so bad after all ..

I've been doing quite a bit of XUL hacking lately and I think it's actually beginning to make sense. The main problems seem to be a lack of documentation and Javascript's usual habit of trying to continue in the face of overwhelming odds which means you don't get told about errors at the point of error, but some unspecified time later.

In particular, it took me a while to work out that if you set your browser.chromeURL property to XUL without a browser marked as type=content-primary, your entire XUL gets replaced with the target window content. Any linked Javascript then runs twice - once just before the XUL gets replaced, tricking you into believing that your XUL is fine - and then again afterward for some reason.

There's also a slightly odd interaction of command-line arguments with windows: the primary window gets window.arguments[0], subsequent window.open()'d ones don't and if your content is doing the open, you need to resort to slightly nasty tricks like setting properties in window listeners. Ugh.

In other news, I'll be at ESC UK in October and at IBC on September 14th and 15th so hope to run into people there.

In case you hadn't guessed, I like muddle. I was formally convinced (i.e., by practice rather than theory) a few weeks ago, when I had to work on a system that already had a muddle description (in fact, the same system into which "george" was being incorporated). With muddle, it was quick and easy to add new software to the system, trivial to update all the packages (muddle update is your friend for updating all the packages in a system from their individual revision control systems - having worked with a "build" system that didn't have this facility, that is so refreshing), and easy to rebuild individual parts. If we hadn't had muddle for this system, we'd still have had to build Makefiles or some other ad-hoc scripting mechanism to make the builds reproducible (been there, done that, ick). With muddle, that step can be avoided (it saves time, in deciding what to do), and the same mechanism can be used for multiple projects (again, it saves time, in learning an individual setup).

(There's a lot to be said for a solution that is ready-made, and avoids the need for deciding what solution to use this time - it's where ASCII, UML and XML have all scored in their time. It's not that the solution need be perfect, just that it be a decent solution that you could have chosen independently, and that everyone is already predisposed to agree on. Such can save months of discussion and reimplementing the wheel.)

Using file-system based tags is useful, too. If you look in the .muddle/tags/packages directories, you'll find the status of each package made visible. Delete one of the tag files, and muddle will believe you that that step is undone (so deleting all of them is one way of making it rebuild a package from scratch). Since checkout and deployment are intrinsically separate from the normal building process, they have their own tags, outside the above. And that's the right thing, too. Perhaps the biggest lesson, though, is to keep going back to the muddle README (this is the first section in the sphinx-ified documentation). It's a good read (it's what made me think muddle2 was really on the right track), but it is also quite information dense - almost everything in there is stuff that you will want to refer back to.

Adding a new program to a muddle build description

So I have a program (which I shall, for the sake of argument, call "george", because that is not its name) which relies upon ffmpeg and tstools, and which I want to incorporate into an existing muddle build.

This article describes how I did it. The resultant code is that used in the real system (except that the names have been changed).

First post..

Welcome to Kynesim's blog. This will be mostly technology with a side-order of comments on the UK tech business and the odd useful Linux hint. .. or you can read our official website.