Fixing window-picker-applet

As you're all too aware of, I own a netbook, and I run Arch Linux, so I'm always trying to optimise my experience by tweaking things here and there. One thing that caught my eye was the Ubuntu Netbook Remix interface, which has 6 major parts:

1. Desktop switcher - switches between netbook/desktop modes.
2. Go Home applet - displays the desktop window, which is the launcher window under UNR.
3. Human Netbook Theme - Ubuntu's infamous dirt-brown colour branding.
4. Maximus - Maximises and optionally removes decorations from windows. Remembers settings.
5. Ubuntu Netbook Remix Launcher - The main interface, displayed instead of the normal desktop.
6. Window Picker Applet - An alternate window switcher that shows the full title of a maximised window, and the other windows as icons.

Being a power user, I wanted #4 and #6. I don't use Maximus, but I found I could get its effects from hacking my Metacity theme. Exactly how I'll leave for another time.

Instead, I did some work on Window Picker Applet. Here are the results, at the middle-top of the screen.

If you're using Window Picker Applet now, you'll notice something is amiss: how can my notes be active, and yet my VIM terminal in the back still shows in the title bar? Try it now: open and maximise a window, and then open a smaller window in front of it.

The problem here is that Window Picker Applet 0.4.21 (I haven't tested later ones yet) assume that the front/active window is the only one that matters. Since I don't use Window Picker Applet with any of the other netbook remix stuff, this made working with multiple windows a bit irritating, as if people like me hadn't been accounted for.

I've written a fix for this.

This replacement for task-title.c in the Window Picker Applet source correctly accounts for the maximised window, even if there are non-maximised windows in front of it. Why isn't it a patch? Simply put, I had to rewrite the majority of the source. There was a core assumption in task-title.c that the "active" window was the only one that needed to be tracked.

When I walked into this source code, I didn't know anything relevant about it beyond C. No GNOME programming, no GTK+, no GObject, nothing. I was amazed that the pseudocode programming process actually helped here. I was skeptical of PPP, but here, where I didn't know anything about GTK+ programming, it really helped. I can't imagine PPP working for any language/framework/API that I'm more than familiar with, but it seems to work great for unfamiliar APIs and the like. Of course, it wasn't like I wrote all the pseudocode followed by filling in all the actual code: I cycled between writing out my sloppy plans as comments, filling those gaps and doing it again and again until I realised I had no comments left to fill.

I never thought pseudocode would ever, ever be useful beyond my crummy highschool software classes. I sure proved myself wrong here.

tl;dr: If you want my window-picker-applet fix, get the applet source version 0.4.21 or later and replace task-title.c with my own version. ./configure && make && make install, and adjust to taste/platform.