Chronometrist - past, present, and future

↩ blog

← Previous: What software documentation must address
→ Last: Chronometrist - past, present, and future

<2022-04-28T03:51+05:30>

Past and present

In case you do not already know, Chronometrist is a time tracker/visualizer I've been working on (and using) since 2018.

I use it because -

  1. I tend to lose track of time as I work, so this provides me with the awareness of where my time went. At times, that awareness is all I need to break out of an obsessive spell of working on something.
  2. I like discovering patterns in how I spend my time.
  3. It also doubles up as an exercise tracker and a machine-readable diary, among other things.

Most FOSS time trackers I've used have been lacking in some way or the other. Some have a rigid UI, some don't permit easy editing of your data (e.g. via human errors in tracking), some aren't very flexible in the data they store (Chronometrist can attach arbitrary key-values to recorded time).

  • Most also don't have any equivalent of Emacs' hooks, so I can't use them for automation, e.g. opening a certain file or launching a certain program when I start a certain task.

It's been an Emacs Lisp application all this time, which stores data as Lisp plists in a text file. This has served me well, but…

The future

In March 2022, I started working on the long-awaited Common Lisp port of Chronometrist, which aims to create -

  1. a greater variety of backends (e.g. SQLite)
    • I'm considering writing Org and Klog backends as well. If completed, they would make Chronometrist a pandoc of the time-tracking world.
  2. a common reusable library for frontends to use,
  3. a greater variety of frontends, such as -
    • a CLIM (Common Lisp Interface Manager) GUI - a vastly more capable GUI toolkit than Emacs. I'm looking forward to displaying actual colorized, customizable line graphs 1 to visualize time.
    • Qt and Android interfaces using LQML,
    • a command line interface (CLI), for UNIX scripting;
      • The Emacs Lisp codebase will probably become an Emacs frontend to a Common Lisp CLI client.
    • a terminal user interface (TUI), for those so inclined; 2
    • (maybe) a web frontend (e.g. via Parenscript or CLOG),
    • and perhaps even an interface for wearable devices!

The port is also driven by the desire to have access to Common Lisp's better performance, and features such as namespaces, a de facto standard build system, multithreading, SQLite bindings, a more fully-featured implementation of CLOS (including the MOP), reader macros, and optional type annotations, checking, and inference. Common Lisp is my preferred language and I want to see more software written with it.

The design I have in mind for the CLIM and mobile frontends aims to conform to the 7 principles of malleable software. Not only do I intend for them to be as configurable as Emacs, but also in a way that non-programmers can modify the program as easily as they can use it, without requiring programming knowledge. Of course, Emacs-style configuration-as-a-program is also available to those who require even more flexibility.

Unrelated to the Common Lisp port is the extension of the data model. I intend to add -

  1. Support for "events" - named timestamps with key-values. Useful for recording things like weight, medication consumed, waist circumference, and so on.
  2. Support for adding key-values to dates
  3. Support for recording concurrent intervals. This should allow for much greater flexibility in what can be recorded. Those who (like me) don't wish to record concurrent intervals will be able to configure their clients to prevent their creation.

The request

If this vision sounds appealing to you, I request that you financially support my efforts on Liberapay. Ideally, I'd like to work on my personal projects (such as this one) full time - recurring donations are the only way I can think of for making that happen.

Is there a feature you'd like to see added to the above? Or perhaps you'd like to work with me on the project? I'd love to hear from you - please get in touch with me.

Footnotes:

1

Instead of the sparklines used in the Emacs Lisp implementation.

2

Technically, Emacs applications are TUIs when run with emacs -nw. The McCLIM implementation of CLIM also has an incomplete terminal backend (think ncurses, but minus the C) - when completed, a CLIM frontend could provide a TUI "for free".