A few days ago, Elias Probst asked me to provide some shell functions to easily fetch the current activity so that he could use it with the TaskWarrior - to separate tasks for different activities. These are now avilable in the KActivities repository and … I’m not going to explain them in this post. Maybe the next one.

When he said the name “TaskWarrior”, I just had to see what it is.

In a nutshell, it is an awesome command-line tool for task management. It supports tags, custom annotations, separating tasks from different projects etc. and sorting tasks by automatically calculated urgency (you can check out the docs to see how it is calculated). It has a couple of different TUIs and GUIs including one for Android (works on BlackBerry 10 as well).

It can use multiple different databases specified via an environment variable. At first, I wanted to implement the activity-task-separation that way. It worked ok, but created problems with syncing tasks between different devices, and you could not list tasks from all activities in one command.

After that, I decided to change the approach and use the project tag of a task for activities. I have written a small Python wrapper that uses the activity name as the task’s project (lately, I’ve been using Haskell for things like these, but in this case I chose Python because more people have it installed on their systems).

If you do not specify the project tag manually, the wrapper will automatically tag it with the name of the current activity; and if you do specify a project, the wrapper will prefix it with the name of the activity like this:

As seen in the screenshots, it only shows the tasks from the current activity by default. It is also possible to list all the tasks from all activities by calling ‘task.py all’ (I’ve created aliases t = task.py and ta = t all for convenience):

TaskWarrior All Activities
TaskWarrior All Activities

Potential problems

It is never advisable to use the activity names directly, since those can be changed, but I decided to do it this way because it would be really ugly to have UUIDs as project names.

I hope this will not create problems for the users - I don’t expect people to change the activity names that often.

One of the possible future developments would be to also tag the tasks with activity:UUID tag and renaming projects when the activity names change, but we’ll see whether that is the best way to do it. A downside is that this might create problems for synchronization because ‘the same’ activity will have different IDs on different devices.