README: 2007 Mar 26 - 2007 Apr 15

Description

I'm mostly immune to manual time-tracking tools. Since my primary computer has, inherently, enough information to figure out what I'm working on, it should capture that for me.

Sun Apr 15 13:01:00 2007

I did a little more hacking here - a simple python script to figure out what's the top window and log it, using subprocess.Popen to call xwininfo and xprop.

This turned up some interesting tidbits:

xterm already has WM_NAME set via an old $PS1 setting
emacs only puts the buffer in the title for multiple frames; (setq frame-title-format "%b") fixes this.
firefox (using the conkeror extension) puts the "buffer" (page/tab) name in the title; it turned out to be easy to change this to the URL with a scattering of document.title = document.commandDispatcher.focusedWindow.location.href; statements.

Since I was having some reliability issues with figuring out the "top window", I tried using ratpoison -c 'windows %s%i' but something about running that 3 times/second (or possibly about using c-c to interrupt it) crashed ratpoison (1.4.0-beta4 ubuntu) which I'll try and diagnose later.

In the meantime, a discussion about some of my old perl code (the fact that I still set my X desktop with code that uses my pure-perl Xlib implementation, http://www.foo.be/docs/tpj/issues/vol2_1/tpj0201-0010.html was pointed out as one of the last chunks of perl in my life, since my "conversion" to python) inspired me to look at python-xlib again. Turns out that python-xlib has a nicely rich interface (windows as objects with methods, rather than a thin mapping to the C bindings, while still being appropriately close to the wire.) python-xlib gave me a number of advantages:

X errors (due to the transient nature of these particular windows) turn into Xlib.error.BadWindow exceptions, which I can handle cleanly
it takes less code to ask for the particular property via topwin.get_wm_name() than to parse them out of xprop output
once I lost the extra baggage of parsing code, it was easier to see simpler ways to look at the overall structure
using the interactive python interpreter to poke at window state directly made it much easier to decide that child.get_attributes().override_redirect was worth checking (turns out that were override-redirect windows which were higher on the list, but still not the "real" top window.)

The current version on_top.py still has a little debugging info, and only covers the logging and data-gathering parts of the effort. It doesn't cover actually mapping this information to what project I'm actually working on; I want to start out by collecting evidence, and after a few days of that will come back and figure out how to analyze it.

Mon Mar 26 00:25:00 2007

I've been sufficiently over-multi-tasked at work that it's time to put some effort into meta-project-tracking again.

I just noticed that xwininfo -stats -root -tree actually seems to list the windows in order, such that the first one mentioned is the top window, and since I use ratpoison, that's the one I'm looking at...