Toward the end of the forum thread there is a very nice set of udev rules that work perfect for me and are very clean. I put the following into /etc/udev/rules.d/85-yubikey.rules

ACTION=="add", ENV{ID_VENDOR}=="Yubico", RUN+="/usr/local/bin/gnome-screensaver-unlock"
ACTION=="remove", ENV{ID_VENDOR}=="Yubico", RUN+="/usr/local/bin/gnome-screensaver-lock"

I really dislike the scripts that are in the thread for locking and unlocking the computer. Gnome Screen Saver is a DBus enabled application so controlling it is very easy. Below are the unlock and lock scripts I’ve written. They use qdbus to send the dbus commands. This could be replaced with dbus-send but I use Qt and qdbus’s syntax is easier to work with.

gnome-screensaver-unlock

#!/bin/sh
 
user=`ps aux | grep gnome-screensaver | head -n 1 | awk '{print $1}'`
 
if [ -n $user ]; then
        GNOME_SCREENSAVER_PROC=`ps xa | grep gnome-screensaver | head -n 1 | awk '{print $1}'`
        export `grep -z DBUS_SESSION_BUS_ADDRESS /proc/$GNOME_SCREENSAVER_PROC/environ`
 
        su $user -c "qdbus org.gnome.ScreenSaver / SetActive false"
fi

gnome-screensaver-lock

#!/bin/sh
 
user=`ps aux | grep gnome-screensaver | head -n 1 | awk '{print $1}'`
 
if [ -n $user ]; then
	GNOME_SCREENSAVER_PROC=`ps xa | grep gnome-screensaver | head -n 1 | awk '{print $1}'`
	export `grep -z DBUS_SESSION_BUS_ADDRESS /proc/$GNOME_SCREENSAVER_PROC/environ`
 
	su $user -c "qdbus org.gnome.ScreenSaver / SetActive true"
fi

One thing that isn’t mentioned in the forum thread that is very important, this unlocking method is highly insecure. The locking portion is fine but unlocking shouldn’t actually be done in this way. The above udev rules only checks that a Yubikey is inserted. It does not which which Yubikey is inserted. Any Yubikey can bypass your password and unlock the computer. The unlocking script does not preform any additional checks against the yubikey. Due to this, I don’t have the unlock code enabled on my computer.

However, it is possible to make unlocking secure. You can use one of the two yubikey pam modules, Yubico’s yubico-pam and Securix Live’s yubipam. Yubico-pam requires internet access because it validates against Yubico’s servers. Yubipam does not need internet access but you will have to reprogram your Yubikey with a new AES key. The new key must be stored in the computer. Each has it’s advantages and disadvantages but using the pam module with Gnome Screen Saver (I haven’t actually tried so it might not work) will provide you with a secure unlock.

Thinking about secure unlocks there is a clever solution that allows for the Yubikey to be used with SSH without the need for the pam module. If I can find a way (I haven’t looked yet) to have an input that can capture the Yubikey’s output then it would be possible to handle the unlock in a secure manner without the need for the pam module…

The dock when closed feature was implemented via XEmbed. Basically I was creating my own window mimicking the window border of the application’s window. I would then remove the border from the application’s window and embed it into my window. Events would be passed from my window into the embedded window. This should work just fine in theory but it didn’t work out so nicely. Embedding caused five issues. The first four are serious and the last is only an annoyance.

The most serious issue was, it broke drag and drop. This looks to be an issue with X itself because I could recreate the problem using Qt and GTK’s embed support as well as writing the embed calls myself using xlib.

Another issue it caused related to support windows. When the main window was embedded it broke the connection between the main window and it’s support windows. So when docking the main window there were issues docking the applications other windows. This is an issue for applications such as XMMS and the Gimp.

Embedding didn’t get along very well with borderless windows. Applications like Chrome and XMMS draw their own window border in place of using the window manager’s decorations. These applications have special handling for moving when clicking and dragging their border. When they are embedded you end up with one of two situations. You can click and drag the window but only in the container window. So instead of moving the window you just move the window’s contents. The other situation is moving via the border doesn’t work at all. In this case resizing doesn’t work either. Oh, and the minimize, maximize, close buttons might not work either. In both cases you can still move the window using alt+left mouse button but this isn’t ideal.

Focus handling with embedded windows didn’t work correctly between different window managers and possibly different versions of Xorg. Some combinations it was fine. Others focus handling only followed the mouse. There were issues with the embedded window never getting focus or only getting focus when using alt+tab to select the window after it was docked.

The only annoying issue that I was okay with having was when undocking a window the window manager (compiz) would cause it to move a little bit. When undocking the position of the container window is recorded, the embedded window is removed from the container and moved to it’s location. Then the container window is destroyed. Compiz didn’t like placing two windows in the exact same place and kept moving the second window down and right by the size of the decoration and frame. This isn’t a very big issue but I really don’t want to have window manager specific work arounds in the code base.

The decision to remove iconify on close wasn’t taken lightly. It was only due to the large number of issues it created. There is not point in using KDocker if it is only going to make docked applications unusable. I have created a branch for iconify on close so I can hopefully get it working properly.

I’ve added three new pdf manipulation tools. Merge to combine multiple pdfs into one. Split to split a pdf into multiple files by page. And info to show information about the pdf. Info is especially handy when you want to work with split and need to know how many pages are in the document.

To stop issue with naming conflicts (pdfinfo is used by poppler-utils) and to keep the amount of pdf* names under control I’ve created a git/bzr like wrapper for all of Calibre’s pdf manipulation tools. pdfmanipulate is the base command. A subcommand (see them all with –help) is added after.

$ pdfmanipulate --help
Usage:
pdfmanipulate command ...
 
command can be one of the following:
[info, merge, split, trim]
 
Use pdfmanipulate command --help to get more information about a specific command
 
Manipulate a PDF.
...

$ pdfmanipulate merge --help
Usage: pdfmanipulate merge [options] file1.pdf file2.pdf ...
 
Merges individual PDFs. Metadata will be used from the first PDF specified.
...