XMonad with Ubuntu, dvorak, Pidgin and Skype

The last two days I have been playing around with XMonad, a tiling window manager for X, written in my favourite language Haskell. I now have a setup that is to my liking. It is intended for Ubuntu, using the dvorak keyboard layout, with key bindings that are a mixture of Gnome and XMonad default bindings.

The thing that I'm most proud of, however, is that I made a customized version of XMonad.Layout.IM that allows for multiple buddy lists. The buddy lists from Skype and Pidgin are placed on the right side of the F10 workspace, while chat windows are automatically placed in the remaining area.

I realize that the target audience (Ubuntu users, typing on dvorak, interested in alternative window managers, and using Pidgin and Skype) may be quite small, but in case my configuration file, or parts of it, are useful to somebody, I put it on the Haskell wiki.

This requires XMonad 0.8 or above. This version is in Ubuntu Intrepid. Ubuntu Hardy ships with an old version, so there you will need to install XMonad by hand.

Full screen forms in .NET

Today I tried to make a form take up the whole screen (including the taskbar) in C# on the .NET platform. .NET WinForms does not offer functionality to do this, so I nosed around the web. All results that I found used platform-dependent P/Invoke calls to accomplish this goal. However, I wanted to keep my code platform-independent, so I created a pure, managed .NET solution.

First, we need some member variables to remember the window state, so we can come back out of full screen mode:

private FormWindowState m_previousWindowState;
private Bounds m_previousBounds;
private FormBorderStyle = m_previousBorderStyle;

The code to switch into full screen mode then becomes:

m_previousBorderStyle = FormBorderStyle;
m_previousWindowState = WindowState;
m_previousBounds = Bounds;
// Stay on top of everything else.
TopMost = true;
// Remove the window border.
FormBorderStyle = FormBorderStyle.None;
// We cannot change the Bounds of a maximized form.
WindowState = FormWindowState.Normal;
// Set the size of the form to the size of its screen.
Bounds = Screen.FromControl(this).Bounds;

The code to switch back simply restores all this:

TopMost = false;
FormBorderStyle = m_previousBorderStyle;
WindowState = m_previousWindowState;
Bounds = m_previousBounds;

It's really quite simple, and I don't know why people make it more complex than it should be.

gluLookAt documentation is wrong

Today I noticed a strange omission in the documentation for the GLU function gluLookAt. As the specification says, the function is designed to place the camera at a certain point in the scene, point it at a certain other point, and roll it such that a certain given vector points upward in the view.

First, the function computes a front vector, F, by subtracting the eye point from the centre point. This normalized version of this front vector is called f and is the vector that should be mapped to the −z axis. To find the side vector, the one that maps to the x axis, the cross product between the normalized front vector and the normalized up vector UP' is computed. Both vectors have unit length, but the user may have specified an up vector that is not perpendicular to the front vector, so the result s might not have unit length. If we used it like this, then the resulting matrix would include a scale component in the x direction, resulting in a scaled scene. Hence, the side vector s has to be normalized as well, which is exactly what the Mesa source code for gluLookAt does in line 134:

/* Side = forward x up */
cross(forward, up, side);
normalize(side);

However, the gluLookAt documentation does not mention this! It says “s = f × UP'”, and follows by plugging this s straight into the resulting matrix M. If you implement the algorithm precisely as stated in that manual page, like I did, you will end up with an incorrect matrix.

Note that, after computing the side vector, the ‘official’ up vector is recomputed as the cross product between the side vector and the front vector. If you did it correctly and not follow the documentation literally, both have unit length. Since these are guaranteed to be perpendicular you should end up with a unit-length up vector that does not have to be normalized afterwards; and indeed the Mesa code does not do this. But if you did follow the documentation, then your up vector will also be wrong, resulting in a scene that is scaled in the y direction as well.

I am trying to get in touch with the OpenGL people about the problem in the documentation. I'm curious to see what will come of it.

Blogger clients for Linux

Since Blogger is so annoying, I gave a couple of dedicated blogging clients a try. Here is a short summary of my findings. An important requirement for me is that the client runs on Linux (Windows is optional, but not required). WYSIWIG editing is not important to me, as long as there's some kind of preview feature. And there must be a way to post images.

BloGTK

A GTK program, written in Python. Last updated in 2005. Couldn't get it to work, obviously.

Drivel

Another Gnome program. It is not in the Ubuntu repositories and the most recent Ubuntu package is for Dapper, which is ancient and fails to work. Then I noticed that image upload is not supported, so I didn't bother trying to build from source.

Bleezer

A Java program, runnable from the web via Java Web Start. The password that you type into the program is shown in plain text on the screen so at that point I gave up. I do not want to use a program with such disregard for basic security and user interface conventions.

Gnome Blog

Sits in the way in your system tray. Not what I was looking for.

ScribeFire

A Firefox plugin. Ironically much better than all the standalone applications. For now this is my program of choice. The image upload does not work for me, however, so I filed a bug about that. ScribeFire seems to be pretty well maintained so I expect that they'll get back to me soon.

News flash: Blogger still sucks

Just need to rant again. Sorry. Some more things that are wrong with Blogger and have been around for ages:

• When inserting an image, the <img> code is inserted at the top of the post, not in the place where the cursor is. You need to scroll all the way back up, cut the code, then find the place where you were typing in the annoyingly small box, and paste it there.
• The following crap is Blogger's idea of good image code: <a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://…"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;" src="http://…" border="0" alt=""id="…" /></a> The part where the cursor is specified and then immediately overridden is my favourite. I haven't looked at the “deselect gracefully” bit but I suspect it is equally awful. And don't these guys know that you can specify CSS in a separate file instead of repeating it on each and every element?
• The preview does not use the actual CSS from the blog, so the formatting will come out all different from the preview.
• When toggling to preview mode and back, you are thrown back to the beginning of the post, and you'll have to scroll back to the place where you were typing. Did I mention that that box is annoyingly small?

A picture on the title page in LaTeX

In LaTeX, there is by default no way to put a picture on the title page or cover page that is produced by \maketitle. Surprisingly, no package seemed to exist for this either. Until now, because I wrote it.

The package titlepic.sty, which can be downloaded from CTAN, is very simple and easy to use. Install it by putting it in your texmf tree and rehashing, or simply drop titlepic.sty in the same directory as your .tex source document. It works with the default document classes article, report and book.

Include it as normal, with \usepackage{titlepic}. Then, along with the usual \title, \author and \date, put a command like the following:
\titlepic{\includegraphics[width=\textwidth]{cover.jpg}}
The argument to \titlepic will usually be an \includegraphics command, but it can actually be pretty much anything. The output produced by this argument will be typeset centered on the title page when you invoke \maketitle. (When you use the article document class, be sure to pass it the titlepage option, because articles do not have a title page by default.)

There are three optional arguments that control the vertical layout of the title page:

tt

Put both the title (and author, and date) and the picture at the top of the page, separated by a fixed amount of space.

tc

Put the title at the top of the page as with tt, but center the picture vertically on the page.

cc

Separate the title and the picture by a fixed amount of space, and center both together vertically on the page.

A full manual is also available. I hope this is of some use to someone. Enjoy!

Note: titlepic only works with the “standard” document classes article, report and book!. You may have some luck with other classes such as AMS, but no promises.

LaTeX clever references

When you're referencing a section in LaTeX, you'd usually write something like
… as we saw in section \ref{sec:cake}.
But this is somewhat inconvenient. LaTeX knows that it's a section, right? So why the need to specify this? Worse, if you ever change it into a subsection, your reference will be wrong.

Luckily there's the command \autoref from the hyperref package. However, this too has some drawbacks, mainly that it does not provide a capitalised version. A better alternative is to use the package cleveref. It is not in the Ubuntu repositories, but you can simply download and extract the archive, then run latex cleveref.ins to obtain cleveref.sty and dump it in the directory along with your document.

Load the package with
\usepackage{cleveref}
and make sure it's the last package to load; that is, even laster that hyperref.

Using \cref the previous example becomes:
… as we saw in \cref{sec:cake}.
This will produce the text “… as we saw in section 3.”. At the start of a sentence you'd use the capitalised version \Cref:
\Cref{sec:cake} gives the recipe …
You can even write:
See also \cref{sec:cake,sec:lie,eq:recipe,thm:delicious}.
This produces “See also sections 2 and 3, eq. 5 and theorem 1.” Although I doubt that anyone would use this very often, it's still pretty cool.

You can customize the word that is printed before the number. For example, some people like them to be always capitalised. (I don't, but my supervisor does, and who am I to argue?)
\crefname{chapter}{Chapter}{Chapters}
\crefname{section}{Section}{Sections}
\crefname{subsection}{Section}{Sections}
\crefname{subsubsection}{Section}{Sections}
\crefname{figure}{Figure}{Figures}
\crefname{table}{Table}{Tables}
Etcetera. Note that subsections and subsubsections are usually all referenced to as sections.

Finally, as a bonus, here's how you make it work with references to \subfloats from the subfig package:
\crefname{subfigure}{Figure}{Figures}
(Capitalise according to taste, or even write “subfigure” if you like.)

For more options, see the cleveref documentation.