Shelxtl XP, written by George Sheldrick, used to work very well under OSX 10.4. With the X11 that comes with OSX 10.5 and later, however, performance is poor. PROJ rotation of small structures is painfully slow, but for larger structures or extended atom lists, such as what you get after GROW or MGEN, rotation can be fine. The official explanation is that the slow down is caused by "many layers of inefficient code". However, large atom lists seem to rotate quite well with PROJ, so that cannot be right. If it were the reason, then why did it work so well under OS X 10.4, and why would the performance bog down be worse for small atom lists ? Perhaps a fresh compile would fix it, but the source code is not available. I had a fix for this issue on OSX 10.5 and 10.6, but that solution does not work on OSX 10.9 so I had to find a different workaround.

This document describes a simple fix for the unsatisfactory PROJ rotation in XP on OSX 10.9.x and later. It probably also works for OSX 10.7 and 10.8, but I haven't tried. Also described here is how to use an unmodified XP executable without having to hand edit any of the new SHELXL-2014 instructions (e.g. RIGU) that the now deprecated XP does not understand. How it does this will be explained below. In addition, a way of setting some run-time preferences that can't be set using the sxtl.ini file is described. Lastly, a shortcut to automatically convert XP-generated *.plt files into PostScript (and PDF) files is included. This may sound like a lot of work, but really it's not too complicated. Once the scripts are in place it is almost completely transparent - you can work pretty much the way that you are used to working.

Update 2017/04/02: The fix here works well on a 15" MacBook Pro (2016) - the one that only has usb-c ports - running Macos Sierra v10.12.4 and later. Sometimes, it seems to run better if the xp-proj-enabler window is set to 'iconic' in the xp-launcher script. There's a commented out line for this in the script, so it should be easy to set. Try it with and without and pick which works better.
Aside: I did an experiment in which I disabled three of the four cores on the new MacBook Pro. With only one core, proj rotation (without my fix) was smooth, but too slow. I also tried it with all the cores enabled but hyperthreading disabled, but that was still choppy. It therefore seems that there are two problems. One could well be "many layers of inefficient code", but the other seems like a race condition issue in which cores get stuck waiting for each other to catch up. Either way, the following fix is still good. Also worth mentioning is that it is possible to make xp-launcher more sophisticated. On my laptop, it queries the system for the screen resolution, and then sets a different WSIZ in XP for whether there is an external monitor attached. This also works on the Retina Mac screens to allow well-sized XP windows for the higher resolution settings. If you're interested in how to do this, please send me an e-mail.

Here's what to do:

1) Get the following files from the UK X-Ray Facility website:
These scripts, as well as other programs and workarounds are kept here. The scripts are just text files that contain either bash or expect code.

2) Copy these files to /usr/local/bin and make them all executable. Depending on how you have your Mac set up, you may need to be 'superuser' (or use 'sudo') to do this. Something like the following ought to work - type these lines on a terminal or xterm command line and hit return:

sudo cp xp-launcher /usr/local/bin/.
sudo cp xprun /usr/local/bin/.
sudo cp xp-proj-enabler /usr/local/bin/.
sudo cp xpdraw /usr/local/bin/.
sudo cp plt2ps /usr/local/bin/.

sudo chmod 775 /usr/local/bin/xp-launcher
sudo chmod 775 /usr/local/bin/xprun
sudo chmod 775 /usr/local/bin/xp-proj-enabler
sudo chmod 775 /usr/local/bin/xpdraw
sudo chmod 775 /usr/local/bin/plt2ps

3) Rename your copy of the executable file for XP to 'xpx'. If you are squeamish, you may want to make a backup copy beforehand. It might be easier if you change directory to /usr/local/bin, i.e. like this:

cd /usr/local/bin
sudo cp xp xp-backup
sudo mv xp xpx

4) Rename your copy of xp-launcher to 'xp':

sudo mv xp-launcher xp

5) I find that it helps to use a custom xterm for XP. To automatically start such a custom xterm, you can use a .xinitrc file in your home directory. Click here to see what mine looks like. This file is read whenever X11 starts. My .xinitrc file opens a yellow on near-black xterm on the far right of the screen with the title "xterm for XP", and changes the directory to the place where I keep all my working structure files. You may want to modify it to suit your aesthetics and workflow. I think the syntax is straightforward enough, but feel free to ask me if you need help.

If you have followed the above instructions properly, you should now have everything in place to trick XP into civilised behaviour on newer Macs. There are, however, a few things that you may want to tweak. Before going into more detail on such tweaks, here's a brief explanation of what happens when you launch XP from an xterm command line using the method described here.

If you have used a variant of my .xinitrc file, when you start up X11 you will automatically get a near-black xterm with yellow foreground. The window position and size are optimized for my flaptop, so you may want to experiment with the "-geometry 82x67+1168+0" numbers in the last line. For me, an 82 column x 67 row xterm positioned snug against the top-right side of the screen works well. This size is not just pulled out of thin air; it is set that way on purpose (see below).

Once the xterm window has launched you need to change directory to the place where your structure is located. My .xinitrc file automatically changes the directory to ~/Structures, but you can make it whatever you like. Hopefully the syntax is obvious enough. Once in the directory of choice, you start XP exactly as you would expect, i.e. by typing "XP filename" at the xterm prompt:

xp filename

Now, rather than starting XP directly, the xp-launcher script that you downloaded, installed and renamed (to xp) will run. There are some detailed notes within the file to explain what it does, so there's little point in repeating it all here. However, a brief explanation is in order.

The first thing to happen is that xp-proj-enabler opens a small xterm in the top-left corner with an innocuous print loop running in it. Strange as it may seem, it is this seemingly useless print-to-the-screen loop that cures the choppy rotation problem in PROJ. The xp-proj-enabler window will be hidden from view by the XP graphics window. As an alternative you can minimize it to the dock if you like (there's a commented out line in xp-launcher that does this via the -iconic flag). You might also try experimenting with the "sleep 0.05" line in xp-proj-enabler. A smaller number makes the rotation smoother, but slower. You could also replace the "sleep" instruction with one or more "wait" instructions. This can make it even smoother, but the speed will depend on your system. On my new flaptop (2016 MBP, 15") this gives better results than a sleep instruction.

The next thing to happen is that xp-launcher creates a backup of the *.res file. It then edits the working copy of the *.res (using perl) to insert "REM" in front of all the SHELXL-2012/3/4 instructions that XP doesn't understand. A more detailed description is included within the xp-launcher script, which explains the handling of *.res vs *.ins files. I tried to make it behave as similar as possible to running XP in the regular way. There are, of necessity, a few differences but it does a pretty good job for the most part. One major advantage of starting XP this way, as opposed to hacking the binary executable (ask me for details), is that as more new instructions are added to SHELXL, it is trivial to just REM them out with additional lines of perl in xp-launcher.

Once the working copy of the file has been edited, the expect script xprun is invoked to actually start the XP executable [which was renamed to 'xpx' in step (4) above]. The advantage of doing it via an expect script, rather than simply calling the XP executable directly, is that expect allows you to set a few preferred defaults that cannot be set with Bruker's sxtl.ini file. You can modify xprun to do different things from mine - the syntax should be pretty obvious. My copy is set to specify an XP graphics window that is 1166 pixels wide. On my flaptop, such a window size fits perfectly side-by-side with, and is the same height as the 82x67 "xterm-for-XP" text window. Notice that I also have a commented out "WSIZ 800" entry that works better with most lecture theatre projectors (useful for teaching). As with the other scripts, the xprun text file includes more detailed notes.

The last two scripts available for download above are used to automate creation of PostScript and PDF files of ellipsoid and packing plots etc. They are not strictly necessary for smooth running of XP on the Mac, but they are very useful. In short, they convert any *.plt file in the working directory into *.ps and *.pdf files. To use them, you have to create the XP plot file (i.e. *.plt) in the usual way (e.g. with TELP). Then, instead of using the XP command "DRAW" to generate PostScript files, you use the bash script xpdraw (which in turn uses plt2ps, an expect script). This can be done from within XP like this:

unix xpdraw

Or after quitting XP, like this on the command line:

xpdraw

The rationale behind these scripts is to minimize the amount of repetitive typing you need to do. If you do a lot of structures, it is a tedious time sink to have to explicitly DRAW each and every *.plt file individually. A burden that is automated by xpdraw and plt2ps.

Aside from xp-proj-enabler, the rest of these scripts can be used on linux installations too, but you may have to manually install expect (e.g. using yum or whatever installation tool you use). If you try these things and they don't behave the way you expect, please ask me, as it probably means that this how-to is not clear enough. I have this all (and more) running on my flaptop and on a Mac Mini and several linux boxes (sans xp-proj-enabler) in the UK X-Ray Facility, and it all works flawlessly.