I decided to take Ubuntu Precise Beta 1 for a spin to test out its support for multimonitors. Traditionally, this has left something to be desired. I’ve always thought of my second monitor as a monitor in its own right. By that I mean, rather than merely being a blank extension of pixels for the primary monitor, it should be considered a monitor in its own right, with the benefit of being able to drag between the two.

When Unity was first launched it met with considerable criticism. One thing I think it did right, however, was to have a task bar (which later displayed the ‘global menu’) on both monitors. Ubuntu Precise has taken this a step further, as can be seen from the image here:

Here we can see that there is now a dock on both monitors displayed by default. In addition, there is a slight traction of the mouse as it switches from the monitor on the right, to the one on the left. The mouse hangs just perceptively as you move over the join between the monitors. Whilst this may sound annoying, it actually alterted me to the best feature of Precise’s multimonitor support: the ‘snap’ feature - dragging to an edge to expand a window to half a monitor - now works for the inner edges of the two monitors.

This is such an improvement over Oneiric's multi-monitor handling. At last, they are represented as two joined screens, but with the functionality of two independent outputs. This gives first-class citizenship to the second monitor, and makes it much more than merely a scratchpad for extending the primary.

I’ve recently started using a Wacom Bamboo tablet for drawing diagrams for my notes (a tablet Salman Khan uses for his Khan Academy talks). With Windows 7 I didn’t have any issue getting the tablet up and running, however, Ubuntu was a bit of a different story. As Ubuntu is my primary operating system, there was a certain urgency to getting things fixed.

There are many posts online about how to fix Ubuntu Oneiric (and older) to work with the latest 2011 line of Bamboo Pen tablets (in this case the CTL470). The issue lies with the fact that the drivers included with Ubuntu Oneiric do not support the newest line, which will be supported in Precise Pangolin (12.04) when it is eventually released.

Having dug around and found some truly extensive solutions (lots of custom compilation, different sources for script a, b and c, no integration with apt etc.) I stumbled accross a PPA which contains the newer Wacom support. It can be enabled with a simple:

sudo add-apt-repository ppa:lekensteyn/wacom-tablet
sudo apt-get update
sudo apt-get install dkms wacom-dkms

One reboot later and the tablet was immediately recognised and worked. There is an ongoing issue with the Oneiric version of GIMP which is unable to function with tablets, and has an extensive Launchpad report on the topic, however Inkscape and other applications worked immediately.

As I’ve mentioned previously, I’ve started using Compass and SCSS to handle the CSS styling of my site. SCSS has the advantage of mixins, variables, nesting and inheritance, which can make for much more readable style files. Automatic generation of tidy, compressed CSS output is then as simple as:

compass compile

What I hadn’t used before, however, was perhaps the killer feature of Compass itself. Compass comes with plugins, and an extensible architecture, allowing you to import CSS defaults (such as reset.css and 960gs) without cluttering your main CSS file, and still leveraging the power of the SCSS system. For those unused to grid layouts, 960gs is my personal goto, but there are others out there.

There is a 960 grid plugin for Compass available via nexmat on Github. It makes working with SCSS and grids as simple as a couple of lines of code.

All you need to do is to add to your Compass config (e.g. config.rb):

require 'ninesixty'

And then to your SCSS file (e.g. page.scss):

@import 'compass/reset';
@import '960/grid';

That enables the 960 mixins, and then you need to utilise the grids. There are two options, first, to create a class based grid system (analogous to the original 960gs you are probably familiar with):

.container_12 {
    @include grid-system(12);
}

Alternatively, you can make your own ‘Semantic Grids’, attaching the grid mixins to your own elements. Details can be found in the README over at Github.

When perusing the HackerNews thread on vim-powerline today, I found two new great vim plugins for the price of one! vim-powerline generates a really nice coloured vim statusline and, in the comments, I found gmarik’s vundle.

Vundle can be summarised as a combination of the best of vim-pathogen, and the ease of ruby’s bundler. It simplifies adding new vim plugins to a line in your .vimrc, and a call to :BundleInstall. The plugin is cloned from its git repository, and hooked up to vim. As a result, I’ve been able to eliminate a whole chunk of git submodules from my dotfiles repository, giving me a tidier setup, and gives me a really simple method to install, update, and manage vim plugins.

Full documentation can be found in the git repository, or in the README. All told, a great plugin, and it has really simplified my git/dotfile setup (which, incidentally, can be found here).

Whilst porting an old Drupal 6 site onto Drupal 7 on to a new stack: Varnish, Nginx, PHP-FPM and APC, I ran into a roadblock with the image module of Drupal 7. This is a new core module which essentially takes the function previously encapsulated in imagecache.

As implied by the name of the module, it handles images, specifically, it handles the adding of an image field to a content type in Drupal, and also allows the settings of image display presets - different versions of the images for different uses. The image module then allows you to customise the variant of the image (size, colour, shape etc.) for each display context, for example, in a list, you might use a thumbnail, the node itself a large image, the front banner a medium image etc.

The issue I ran into was not being able to get the other variant preset versions of the image on my Drupal installation. I could get the full sized, original image, but the other variants were not displayed and simply gave 404 errors back to the browser. I checked the permissions (usually the issue) but these were all consistent for allowing the PHP-FPM pool user to create within that folder.

In actuality, the issue came down to Nginx config. The image module has a series of folders it creates under 'styles/' within the public folder for Drupal uploads. For new variants of an image to be created, a 404 needs to be sent to Drupal, and then the new variant is made (rather than at the point of upload, something I didn't realise). Therefore, I needed to make sure that Nginx sent the 404s for those URLs back to Drupal for the logic to work. This is done as follows:

location @rewrite {
    rewrite ^/(.*)$ /index.php?q=$1;
}

location ~ ^/sites/.*/files/styles/ {
    try_files $uri @rewrite;
}

For those unfamiliar with Nginx config, this essentially says that for requests matching ^/sites/.*/files/styles/, Nginx should try the URI requested, and then if that fails, pass to @rewrite. @rewrite then rewites that request to Drupal, which can then handle the appropriate creation logic. With that in situ the different versions of the images are created correctly and the URLs resolve as expected.