Here we hope to clarify the architecture of ActivityWatch for you. Please file an issue or pull request if you think something is missing.
The below is a graph of the fundamental dependencies between projects, these do not reflect the folder structure.
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.
ActivityWatch currently has two user interfaces, aw-qt and aw-webui.
Some of the logic of ActivityWatch is shared across the server and clients, for these cases we moved some logic into separate libraries.
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)
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.