Aaron Bockover

I have been a pretty quiet blogger for the last few months. This is due mostly to the extensive amount of work that has gone into Banshee during this time. After I would reach some milestone where blogging would be appropriate, I’d want to write about it, but just wouldn’t have been able to bring myself to do it. I’m trying to change that now, and as a start, I’ll be writing about new stuff that’s happened in Banshee land in the 0.11.x series.

Scripting Banshee with Boo

Okay, Boo is awesome. During the Mono Summit last November, I wanted a way to be able to work with Banshee’s internal APIs inside of an already running instance. I turned to Boo, and wrote an embedded interpreter which references the loaded Banshee assemblies in the running appliciation domain. It’s called BooBuddy, and I’ll write more about that later. What I’ll share in brevity now is simply that if you’re running Banshee 0.11.2 or later, try pressing CTRL+SHIFT+S and see what happens.

With Boo integrated as an interpreter in Banshee, I decided at the same time it would be a good idea to allow the running of Boo “scripts.” That is, Banshee would load boo files at startup, compile them, and invoke the assembly entry point. Try dropping a .boo file in ~/.gnome2/banshee/scripts and see what happens [1]. In the same location, the .boo files can have normal Banshee plugins coded in them, and they will be compiled and loaded into the normal plugin system. The script’s entry point will be invoked after the script is compiled as well.

This means that it’s possible to write useful snippets of Boo that do cool things against Banshee’s core. Any public API in Banshee is accessible to these Boo scripts, just like plugins. I have been working on adding hooks into useful functionality in core APIs to allow scripts specifically to do extra useful stuff.

Just a few minutes ago, Peter Johanson was crying about spaces in file names that Banshee writes when importing audio CDs, etc. The format of the output path is configurable in the preferences dialog, but it’s very simple. I do not want to expose more complicated formatting options in the UI. I think it’s accepted at this point in time on a UNIX system that ‘File Names Like This.mp3′ are not evil. Now, I wouldn’t name a shell script or a piece of code with that kind of name, but I like my documents and music to have names like that. They look better. I care.

But other people are more hard core traditionalists, and want ‘file_names_like_this.mp3′. What to do? Write a Banshee script, of course. I quickly added a hook to the path formatter, and within seconds, generating those traditional file names with a script like the one that follows was easily possible.

Banshee.Base.FileNamePattern.Filter = { songpath as string |
    songpath.Replace(" ", "_").ToLower()
}

Update: Below is probably a more realistic example, in case you actually want to take advantage of this feature.

Banshee.Base.FileNamePattern.Filter = { songpath as string |
    @/[ ]+/.Replace(@/[^0-9A-Za-z\/ ]+/.Replace(songpath, "" ).ToLower(), "_" )
}

Without the script, for people who like pretty file names:

With the script, for you hard core traditionalists:

So, now that this cool functionality has been exposed publicly on the intarweb, I hope we start seeing some cool Banshee scripts starting to float around. You can even post them on the new Banshee Community Forums.

[1] I made a few changes today that allows mixing ’script’ code and plugins in the same .boo file. Also, before this commit, Banshee looked for an explicit public Main method with no arguments. This meant the script had to provide a def Main(): declaration for anything to happen. With the very latest SVN checkout, no def Main is needed at all, as the Boo compiler will generate an entry point automatically if none is given in code. Assembly.EntryPoint is invoked instead, which is much better than looking for a Main().