One of the reasons that xmonad is so small is that it leaves some window manager features to external programs. For example, it doesn’t have any sort of menu. Most xmonad users use dmenu to provide a program launcher. (I also use it to run internal xmonad commands with my XMonadContrib.Commands module.)

dmenu is originally by Anselm R. Garbe, author of the window managers dwm and wmii. He follows strict anti-bloat principles and endeavors to keep his programs free of extraneous features. This is a respectable goal. On the other hand, there are several patches that multiple users have found useful that are not included in dmenu: Xinerama support, a history feature, and so on.

dmenu is maintained in the Mercurial distributed version control system. This makes it trivial for me to maintain my own version of dmenu, synced with upstream changes, that includes these extra features. It’s even easy for me to share this with the world. (I’d like to think of this as an “extra features edition” rather than as a “fork”.)

You can check out my version with Mercurial:

hg clone http://www.davidglasser.net/hg/dmenu/

or just grab a tarball of the latest version.

On a related note, I’ve been very happy with Mercurial. Its user interface is very nice, the underlying principles are sound, and the work-in-progress book by Bryan O’Sullivan is well-written and helpful. xmonad uses the distributed version control system darcs, and I tried to do similar tasks (keeping my local config in my personal repository while syncing with upstream) in darcs. While darcs has many interesting ideas, I ran into the serious performance problems almost immediately; and because darcs doesn’t really have any idea of a “changeset identifier” other than the log message, it’s pretty hard to use the command line to find out about various patches. Mercurial, on the other hand, was a breeze. There are certainly things I prefer about Subversion (documented internals with a stable API being the most obvious), but I should definitely experiment more with Mercurial (if for no other reason than to learn lessons that can be applied to Subversion and svk).

Subversion prides it on being a respectful community — Ben Collins-Sussman mentioned in his opening spiel that it was one of the big factors in Subversion’s success. I’m happy to report that these are not lies, and that these are pretty great folks.

Yesterday, we dropped by Google to hack for a while. My first plan was to work on my Advanced Algorithms homework. That plan quickly changed to hacking on ZVM, a Python Z-Machine implementation. Turned out there were at least two of us not already on board with ZVM who had implemented Z-Machines before!

We got distracted away from that pretty quickly by noticing that there were a whole lot of changes nominated in the Subversion 1.4.1 STATUS file that really needed to be reviewed and backported in order to get the release out. So we took a couple hours and got the 1.4.x branch to an almost release-worthy state. Maybe tonight!

In a long discussion about distributed version control last night at Karl Fogel’s, most folks realized that none of us had really spent serious time working with a distributed version control system. (Well, other than SVK, which honestly already has most of the features we were talking about…) To get more experience, we’re going to play around with Mercurial during the Summit.

There’s going to be a shared developer’s blog for reporting on the summit, if interested.

Hiveminder! Hiveminder is a collaborative task organizer. Sure, there are many other to-do trackers out there. Hiveminder’s biggest strengths are in its intuitive and simple way of letting you set up “… but first” and “… and then” style relationship between tasks and its support for sharing tasks between people, one-on-one and in groups.

Today, when I look at my main “to-do” page, I see the next steps I need to to for my research, the SVK bugs and features I’d like to work on, a reminder to renew the hosting for this website (with a due date of… today… ooh, should deal with that right now… done), all in one spot.

Technology-wise, the Jifty framework we wrote has some very nice advantages. (Disclaimer, or bragging, or something: Jifty was designed mostly by Jesse Vincent (“the boss”), but I did most of the implementation of its first draft. Of course, since then I think every line I wrote has been replaced.) For example, all code that actually changes anything in the database goes through specific “action” objects; while we haven’t finalized a public API for Hiveminder, this means that eventually everything you can do through the site will be achievable via an API, without any special custom coding.

Another nice technical feature in Jifty is the concept of individually-addressable “page regions” inside web pages, which can be updated via AJAX in a single click. This feature is nothing new for AJAXy webpages… until you try Hiveminder again without Javascript and find out that everything still works. Sure, there are a few extra page reloads, and some fancy UI features like drop-down menus can’t be used, but other than that the site works exactly like it does with Javascript… and without Hiveminder’s code having to have any special cases at all. Hell, I just added a comment to a task about an SVK bug using lynx… just because I can.

Of course, I’m being distracted from work now, so I’ll click on the “pag” tag to show only my research-related tasks and get back to editing this paper…

That’s because OmniGraffle has (at least) two formats for its files: a flat XML file, and a “bundle”, which is actually a special folder containing a bunch of files. By default, OmniGraffle makes flat files, but if you add an image to your document it will magically turn into a bundle and store the image in the filesystem.

If you’re using this with Subversion or SVK, this is a problem for at least three reasons. First of all, most version control systems don’t deal too well with files suddenly turning into directories behind their backs. Secondly, if you add more images, OmniGraffle will add them to the directory, but Subversion will have no idea that these new files should be under version control, and you’ll have to manually svn add them.

More annoyingly, the bundle format used by OmniGraffle puts a file in the bundle which sets the bundle’s icon, and the file is named Icon\r. With a carriage return in it. Yeah. I’m not sure what they or Apple were thinking (as far as I can tell this is one of many ways to set a document bundle icon and I can’t find other apps that use this one), but putting control characters like a carriage return in file names just sucks. And to tie back into the point of this post, Subversion just won’t let you check in that file.

There’s a solution, though, at least for OmniGraffle! Just type the following line in your terminal:

defaults write com.omnigroup.OmniGraffle PrivateGraffleFlatFile 0

(Or if you run OmniGraffle Pro, you apparently should do

defaults write com.omnigroup.OmniGrafflePro PrivateGraffleFlatFile 0

though I haven’t tested this.)

This will make OmniGraffle make all future files as the flat-file format and never sneakily turn into bundle format. Hooray!