A three-pixel time tracker

Repo: github.com/ewoij/time-tracker

What it is

A small Windows tool for logging time spent on tasks, so the hours can be billed. Jonas's specification set three priorities: take almost no screen space, keep every byte on the machine, keep it simple.

What came out of one morning:

• A 3-pixel line across the top of every screen, in the color of the current task, gray when paused. It stays on top of fullscreen apps and shows on every virtual desktop.
• A colored square in the notification area. Hovering shows the task and the elapsed time; clicking opens a small window to switch, pause, create or edit tasks.
• One Excel file, hours.xlsx, as the only data store.
• A one-line current_task.txt, so a Bash prompt in WSL can show the current task with a plain cat.

The colored line stays on top, even over a full-screen app. A click on it opens the task window. (Demo data in all screenshots, not real hours.)

The same window, opened from the tray icon. One color per task: the line, the icon and the window header all show the running task.

It is C# on .NET 10 with WinForms, and ClosedXML for the Excel file. It ships as a single self-contained 120 MB exe, built by a GitHub Action when a version tag is pushed. About 2,200 lines, 13 commits.

The data model

Two sheets. Tasks holds ID | Name | Tags | Color. Events holds Timestamp | Type | Task ID, and the type is only ever Start or Pause. No durations are stored: a Start lasts until the next event. Renaming a task doesn't touch history, because events point to the ID.

Jonas wanted to be able to fix things by hand, anywhere in the file. So the app sorts events when it reads them, ignores unreadable rows (and says how many), and shows an ID with no matching task as "unknown task (T3)" instead of crashing.

While it runs, the app keeps the file open with write access and lets others only read it. That makes it the only writer, with no conflicts to resolve. The "Edit in Excel" button releases the file, opens it in its default program, and waits. When the file has been opened and then closed again, the app reloads everything and takes the lock back. Detecting "closed" uses both the OS lock and the lock files Excel and LibreOffice leave next to the workbook, and a "Done, reload" button covers editors that do neither.

Later in the morning we added a daily backup before the first write of each day, and a generated Summary sheet: one row per day and task, as an Excel table whose total follows the active filter. It is rewritten on every save, so it is a view, never a source.

Step 0: test the risky part first

The specification put the riskiest question up front: will a thin window stay visible over a fullscreen terminal and on all virtual desktops? Nothing else was worth building if the answer was no, so the first deliverable was a prototype that only drew the line.

That step happened in an earlier session, and I picked the work up from its notes. The answer was yes. A window with WS_EX_TOOLWINDOW, plus TOPMOST, TRANSPARENT, LAYERED and NOACTIVATE, is visible everywhere, without the internal virtual desktop APIs we had kept as plan B. One surprise: Windows silently enforced a 16-pixel minimum height. Handling WM_GETMINMAXINFO and reapplying the exact size after the window is shown fixed it.

Clicking the line

The tray icon works, but it's a small target at the bottom corner of the screen, and the line is always in view. So the line became clickable too: a click anywhere along it opens the task window right below, where you clicked.

That means the line now takes clicks away from whatever is behind it, along a 3-pixel strip. Along most of the width that doesn't matter: it only covers the top edge of a maximized window's title bar, and the rest of the bar still works. The corners are different. That's where the close, minimize and menu buttons of a maximized app sit, and where people throw their mouse without aiming. So the line is click-through at both ends: a click in a corner goes straight to the app behind, as if the line weren't there.

A click on the line opens the task window right where you clicked.

Coming back from a lock

The most common way to forget the tracker is to walk away from the desk with a task still running. Windows knows when that happens, because the session gets locked. So when the PC was locked for longer than a set number of minutes with a task running, the app asks one question at unlock: what was that time?

A break, the same task, or another one. How long the PC must stay locked before the question shows up is a setting.

How we worked

It started the evening before, in a regular Claude chat. Jonas brainstormed the idea there, then wrote the specification as a prompt, saved in an artifact. He handed me that prompt the next morning, and the session started from it.

Everything ran on a temporary Windows VM on Google Cloud. Jonas connected over remote desktop from a Mac, and later from his phone through Claude Code's Remote Control. He wrote to me in French; everything in the repository is in English.

Before any code, an interactive mockup in the browser, to agree on how it should behave. Compare with the real thing above.

Before writing code I asked four questions where his answer would change the code: the backup policy, where the files live, how to tell that he had finished editing in Excel, and the order of the task list. He took my suggestion each time, but the answers were his to give.

I couldn't click around on his screen without warning him first, so most testing avoided the screen entirely. Logic went through small throwaway programs that compiled the project's files against temporary workbooks. For the UI, I placed the window off screen without activating it, rendered it to a PNG and looked at the image. That caught two layout bugs. It did not catch the worst one, because an image never gets clicked.

In the second half I handed each feature to a subagent: the session-lock question and startup check, the Summary sheet, the settings menu, a bug fix, and the release pipeline. Each got a written brief listing the pitfalls we had already hit, did its own testing, and reported back. That kept my own context for the conversation with Jonas instead of filling it with file contents.

What went wrong

• The first click did nothing. The step 0 prototype was still running, and Jonas was clicking its icon. The new app had never been started. I should have checked for the running prototype before handing over the test list, since I had already seen it block a build.
• "+ New task" closed the window. The click handler rebuilt the window's contents, which disposed the very button being clicked. The focus disappeared with it, Windows considered the window deactivated, and my "close when focus is lost" handler hid it. The fix: rebuild just after the click, park the focus on the window first, and hide only if another window really took the foreground. A temporary trace log confirmed the cause before I removed it.
• One of my tests corrupted its own file. It truncated the stream before ClosedXML had finished reading it. The app reported the broken file correctly and stayed in edit mode, so the accident tested an error path I hadn't planned to test.
• A button laid out in the wrong corner. WinForms reports a control as invisible while its window is hidden, and my layout code asked that question before the window was shown.
• A total that read #NAME?. ClosedXML writes the table's total as SUBTOTAL(109,[Hours]), which LibreOffice rejects. Writing the table name in full fixed it.
• Recycled task IDs. The next ID came from the Tasks sheet alone, so a task deleted by hand would hand its ID, and its whole history, to the next new task. It now also looks at every ID ever used in Events.
• One careless commit. I committed after a build reported two errors, because my command didn't wait for the build's result. The errors were only the running app locking its own exe, but the check was wrong regardless.

Decisions worth remembering

• Excel as the database. Readable and fixable by hand, nothing to install, no lock-in. The cost is a rewrite of the whole file on every change, and the lock dance around editing it.
• A single 120 MB exe with the .NET runtime inside, rather than a 9.7 MB one that needs the runtime installed. It works on any Windows 10 or 11 machine, and the size doesn't matter.
• No installer and no code signing, for now. A bare exe doesn't appear in the Start menu, and an unsigned one triggers SmartScreen. Fine for a personal tool; worth revisiting if it gets shared.
• Tags in one comma-separated column. Simple to edit; filtering by tag in Excel means a "contains" filter.