Architecture

Here we hope to clarify the architecture of ActivityWatch for you. Please file an issue or pull request if you think something is missing.

Dependency graph

The illustration below is a graph of the fundamental dependencies between projects, these do not reflect the folder structure.

digraph {
    //activitywatch [shape=box, label="activitywatch"];
    //"aw-server" [shape=box, style=filled, fillcolor="0.4+0.5+1"]
    //"aw-client" [shape=box, style=filled, fillcolor="0.2+1+1"]

    activitywatch -> "aw-server" -> {"aw-webui" "aw-core"};
    activitywatch -> "aw-qt";
    activitywatch -> "aw-watcher-afk" -> {"aw-client" "aw-core"};
    activitywatch -> "aw-watcher-window" -> {"aw-client" "aw-core"};

    "aw-client" -> "aw-core";

    "aw-server" -> "aw-analysis";
    "aw-analysis" -> "aw-core";

    subgraph {
        rank = same; "aw-watcher-afk"; "aw-watcher-window";
    }

    //subgraph {
    //    rank = same; "aw-core"; "aw-client";
    //}



    /*
     * Legend, causes sigsegv...
     * http://stackoverflow.com/a/4752766/965332
     */
/*
    { rank = sink;
      Legend [shape=none, margin=0, label=<
      <TABLE BORDER="0" CELLBORDER="1" CELLSPACING="0" CELLPADDING="4">
       <TR>
        <TD COLSPAN="2"><B>Legend</B></TD>
       </TR>
       <TR>
        <TD>Foo</TD>
        <TD><FONT COLOR="red">Foo</FONT></TD>
       </TR>
       <TR>
        <TD>Bar</TD>
        <TD BGCOLOR="RED"></TD>
       </TR>
       <TR>
        <TD>Baz</TD>
        <TD BGCOLOR="BLUE"></TD>
       </TR>
       <TR>
        <TD>Test</TD>
        <TD>HELLO</TD>
       </TR>
       <TR>
        <TD>Test</TD>
        <TD CELLPADDING="4">
         <TABLE BORDER="1" CELLBORDER="0" CELLSPACING="0" CELLPADDING="0">
          <TR>
           <TD BGCOLOR="Yellow"></TD>
          </TR>
         </TABLE>
        </TD>
       </TR>
      </TABLE>
     >];
    }
*/
}

Server

Known as aw-server, it handles storage and retrieval of all activities/entries in buckets. Usually there exists one bucket per watcher.

The server also hosts the Web UI (aw-webui) which does all communication with the server using the REST API.

Clients (watchers, importers, and observers)

Since aw-server doesn’t do any data collection on it’s own, we need watchers that observe the world and sent the data off to aw-server for storage.

These utilize the aw-client library for making requests to the aw-server.

For a list of watchers, see Watchers. For a list of importers see Importers.

User interfaces

ActivityWatch currently has two user interfaces, aw-qt and aw-webui.

  • aw-qt - Manages the server and watchers to make ActivityWatch easy to use for end-users.

  • aw-webui - Offers visualization and an overview of the database. Hosted by aw-server in the bundle.

Libraries

Some of the logic of ActivityWatch is shared across the server and clients, for these cases we moved some logic into separate libraries.

aw-core

The aw-core library contains many of the essential parts of ActivityWatch, notably:

  • The Data model

  • The datastore layer

  • Event transformation and queries

  • Utilities (configuration, logging, decorators)

aw-client

Writing these clients is something we’ve tried to make as easy as possible by creating client libraries with a clear API. A client could both be a watcher which sends data as well as a visualizer which fetches and presents data from the aw-server.

Currently the primary client library is written in Python (known simply as aw-client) but a client library written in JavaScript is on the way and is expected to have the same level of support in the future.

aw-analysis

There are also plans to create a library called aw-analysis to aid in different types of analysis and transformation one might want to make using ActivityWatch data.