D-Tracker

Default Theme

Motivation

For the past years I used the hamster timetracker in the organization I work and for some of my personal projects, but since the last year it was removed from the debian repositories and most of their builds were broken. So after some time thinking about it I set myself to build an alternative.

The focus on implementation was to:

Selected Tools

For the tools, I needed each one of them to be simple to compile, light on resources and cross-platform. The main points were dependencies would simplify my work were:

Following my last experiments with graphical interfaces I found some cool alternatives. From those I selected the tekui toolkit, it is cross-platform, lightweight, has most of the UI elements I need and is simple to use with Lua.

Since this is a single user application and I wanted to be able to run it isolated in a folder without needing to install it to the system, I decided to use sqlite as database to have persistance of the tasks data. Sqlite is just a single C file, it's lightweight, easy to compile and the database for the application is just a regular file. Also to interact with it from lua the lsqlite binding can be used.

To have dates in a sqlite database one possible approach is to have the dates in the ISO8601 format. Also we need to check the duration of tasks and use dates for multiple other cases. With these needs in mind I selected the date library from Tieske. It is just one lua file with handling for multiple date formats, durations and support for ISO8601 in Lua.

For the creation and exposing of a command line interface the lua argparse library can be used. It is only a lua file, and allows a simple way to parse and register commands.

Implementation

One of the initial concerns was to guarantee that the application always asks for the tasks data to the database. So when we have a GUI and a CLI operating on the data it is updated.

To have this possibility of having a GUI and a CLI also all the logic which implements each of the use cases should be isolated, be the only place modifying the database, and receive only the specific data needed for its actions.

With this in mind and having all the objectives set, the next step was starting the implementation. So I started by defining the main d-tracker features that I used:

The implementation of the wanted features was done without much trouble. Some of the main points that gave me more work during the implementation were:

Themes

Creating multiple themes was simple, the GUI toolkit allows for creating themes in CSS and already had multiple base themes. This way the base theme was made while trying to follow the hamster look and most of the other themes are the base tekui themes adapted to d-tracker elements.

The following themes were created:

Default Theme
Klinik Theme
Stain Theme
Monochrome Theme
Gradient Theme
Mint Theme

Plugins

Plugins were created to make a clear distinction that the core of the system doesn't depend on them and they can be optionally deactivated. The plugins can register hooks for events which will be triggered by the main application actions.

The current events which the plugins can listen to are:

Theme Switcher

Right now the only plugin that was implemented was the Theme Switcher plugin. This plugin allows for switching the current theme directly in the UI without having to edit configuration files.

This plugin registered hooks for:

Mint Theme

CLI

To allow for users who like to do everything in the terminal to use d-tracker and to allow integration with other tools for automation, a CLI interface was implemented with the help of argparse.

This interface made available the main controllers already implemented to the GUI but now from the command line. The following commands were created:


list-today-tasks      List today tasks
list-tasks            List tasks between a time range
list-projects         Lists the projects available in the database
delete-task           Delete a specific task
add-task              Add a new task
edit-task-time        Edit the time of a specific time
edit-task-description Edit the description of a specific task
edit-task-project     Edit the project of a specific task
export-today-xml      Export today tasks to a xml file
export-xml            Export tasks in a time range to a xml file
stop-in-progress      Stop the current task in progress

Continuous Integration

Unit tests were implemented for all controllers, to validate that the database operations work well and for every cli command. New tests are also added case by case when new errors are found to avoid regressions.

To implement the unit tests busted was used. It's a really nice library that tells the developer to define the tests as a specification and when the code passes the test it means it passed the specification. You can check an example here.

This setup was really simple, just a YAML file in the path ".github/workflows/" with the instructions needed to install the dependencies in the last ubuntu, compile d-tracker and run the tests. You can check it here.

Tests were run locally while in development but I also took advantage of the github workflows which are free for open source projects. This way I have the project being built and the unit tests being run for each commit and pull request in the repository, including the linux and windows builds.

Result

The result really pleased me, by implementing d-tracker now:

Repository

If you want to try d-tracker you can download it here, to check out the code go to the repository.