The first step is to install RasMol. There are various OS X ports out there — but I used the dead handy Fink to do this in one line:

fink install rasmol

However, RasMol is a Unix executable and not an application in the OS X sense, i.e. a .app file, which means you can’t select it as a download handler in Firefox. So, we need to wrap it in some AppleScript in order to allow this. The following AppleScript — my first :-) — gives you a RasMol Launcher ‘droplet’ which does the trick:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

-- flag to indicate whether script has been invoked as a droplet
set filecount to 0
 
-- run X11 if not running, then run RasMol (command shell and visualization window)
on run_rasmol(filename)
	do shell script "open /Applications/Utilities/X11.app; export DISPLAY=:0; /usr/X11R6/bin/xterm -e /sw/bin/rasmol " & filename & " &> /dev/null &"
end run_rasmol
 
-- open subroutine invoked by OS X if we run this as a droplet (i.e. file[s] supplied)
on open (filelist)
	repeat with filename in filelist
		set filecount to 1
		set filename to quoted form of POSIX path of filename
		run_rasmol(filename)
	end repeat
end open
 
-- if no files supplied (e.g. user double-clicked icon) run RasMol wih no params
if filecount < 1 then
	run_rasmol("")
end if

Click to download

This script starts X11 automatically, if it’s not already running, and for each PDB file dropped onto it, loads it into a separate RasMol instance (command prompt and visualization window). This kind of script is called a ‘droplet’, and can also handle being started from another application with one or more files supplied. If it’s just double-clicked, the on open subroutine is never called, and it opens a blank RasMol.

To create the script, open Script Editor — it’s in /Applications/AppleScript — paste in the source code, hit Compile, and save it as an application bundle called RasMol Launcher. This is a .app file which is really a directory containing the script and its metadata. Most OS X applications are bundled like this.

N.B. You may have to change /sw/bin/rasmol to wherever you installed it to, but this is the default Fink location.

Now, when you next click on a .pdb file in Firefox, you can choose your new RasMol Launcher droplet just like any application, and hit OK, and it should pop up just as if you’d double-clicked a local file. However, see the note about Firefox limitations below.

Associating .pdb files with RasMol Launcher in Finder

Because of the way OS X manages file associations, you can only associate .pdb files with the launcher droplet on a file-by-file basis to begin with (see this thread for why). This isn’t very helpful.

To fix this, we need to go into the bundle and edit some metadata. Go into the bundle in Finder by doing Show Package Contents (ctrl-click menu) and open Contents/Info.plist in a text or XML editor (or Property List Editor if you have the Apple developer tools). Find the CFBundleSignature key and change its string (should be dplt) to RSML. Then add a new entry underneath this with the key CFBundleIdentifier and the string uk.org.biotext.RasMolLauncher. Finally, open the Pkginfo file in the same folder, and change its contents to just the string APPLRSML.

After doing all this, you need to get OS X to re-read the application’s metadata — the quickest way is to move it to another folder, and back again. Now you should be able to Get Info on a .pdb file, change the application it opens with to RasMol Launcher, and click Change All to apply this to all .pdb files.

Firefox limitations

One quirk about Firefox — I think it’s a bug but Mozilla don’t — is that sometimes, the “do this automatically from now on” option when downloading a file doesn’t work. i.e. you can check it, but still get asked next time. The reason behind this is that some web servers are configured to serve files with the Content-disposition: attachment HTTP header, but don’t supply a specific MIME type. Instead they’ll have something like Content-Type: application/download.

In these instance, Firefox doesn’t consider it safe to open the file with the default app based on its filename extension alone, even if you asked for the automatic option before. So it pops the same dialogue box up again. Sadly, one of the sites that does this is pdb.org itself.

However, you don’t have to go all the way through the application selection process again. On my version of Firefox at least, assuming “Open with…” is selected, you can just hit OK and it’ll fire up RasMol Launcher again.

Everybody (?) knows that in theory, if you have 64-bit Firefox on 64-bit Linux (x86_64), you can use nspluginwrapper to install 32-bit plugins, like the Flash Player. There’s some instructions here for example.

However, those instructions are flawed in two regards.

Firstly, Flash Player 10 doesn’t come with a .xpt file any more, but that’s not apparently a problem.

Secondly, and more mistifyingly, nspluginwrapper seems to require you to give the absolute path to the plugin’s .so file, for some reason. So if you get an error like this:

$ nspluginwrapper -v -i libflashplayer.so
*** NSPlugin Viewer  *** ERROR: libflashplayer.so: cannot open
shared object file: No such file or directory
nspluginwrapper: no appropriate viewer found for libflashplayer.so

Then try again with the full path to the plugin:

$ nspluginwrapper -v -i /home/bsm/clegg/.mozilla/plugins/libflashplayer.so
Install plugin /home/bsm/clegg/.mozilla/plugins/libflashplayer.so
  into /home/bsm/clegg/.mozilla/plugins/npwrapper.libflashplayer.so

Restart Firefox, and away you go, joy! No feeling for stability yet, but I’ll post again if there are any problems.

Incidentally, I first tried installing nspluginwrapper via yum, and got a whole bunch of unsatisfied dependencies:

Error: Package devhelp needs libgtkembedmoz.so, this is not available.
Error: Package devhelp needs libxpcom.so, this is not available.
Error: Package devhelp needs gecko-libs = 1.8.0.12, this is not available.

Then I just tried installing the RPMs from the nspluginwrapper home page (first the one marked Viewer, then the one marked Plugin) and it worked like a charm.

Hat tip to this thread on the Ubuntu Forums for finally revealing the key bit of information about absolute vs. relative paths.

UPDATE: Aaargh, sound doesn’t work. But that seems to be the fault of my ALSA drivers rather than Flash or nspluginwrapper. Apparently Flash can only use ALSA for sound, and not any of the other various Linux sound architectures, and only OSS works on this PC…

Andrew.