A web-based UI for ActivityWatch, built with Vue.js
Getting started with setting up the development environment is pretty straightforward:
# Start an instance of aw-server running in testing mode (on port 5666, with a separate database),
# This is what the web UI will connect to by default when run in development mode.
aw-qt --testing
# or, to run without watchers:
aw-server --testing
# Install dependencies
npm install
# or, to get exact versions of dependencies:
npm ci
# start aw-webui in dev mode
npm run serveAlternatively, you can run make dev to install dependencies and serve the application locally.
You might have to configure CORS for it to work, see the CORS section below.
You may also want to generate fake data so you have something to test with, see: https://github.com/ActivityWatch/aw-fakedata/
To build the production bundle, simply run the following:
# Install dependencies
npm ci
# Build for production
npm run buildNote: Running a development version of aw-webui with an old aw-server can lead to issues due to version incompatibilities.
You can run a development version of aw-webui with your main version of ActivityWatch by building it (or fetching the latest build from CI) and replacing the contents of the static directory of your aw-server (or aw-server-rust) installation. For simplicity, back up the original directory for easier switching back.
The assets are stored in the following directories (relative to your installation directory), depending on if you use aw-server-python (default) or aw-server-rust:
- aw-server-python:
activitywatch/aw-server/aw_server/static/ - aw-server-rust:
activitywatch/aw-server-rust/static/
You can copy the assets manually from your make build or npm run build output to the above locations.
Once you've put the files in the directories, you may have to do a hard refresh in your browser to invalidate any stale caches.
Instead of copying files, aw-server-rust supports loading the web UI from a custom path via the --webpath flag. This is especially useful on platforms where the server bundles static assets into the executable (e.g. Windows):
# Point aw-server-rust to your local build output
aw-server-rust --webpath /path/to/aw-webui/distThis avoids having to copy files and makes it easy to switch between development and production builds.
If you want to actively iterate on aw-webui with your local production data (with your production server running), you'll want to use a development build, automatically update it, and connect to your production data. To do this, in aw-webui source directory, in one terminal window run:
AW_SERVER_URL="'http://localhost:5600'" npx vue-cli-service build --watch --dest=../aw-server/staticIf you want to add debugger statements in your code and otherwise break linting rules, you'll need to add a --skip-plugins=no-debugger to that command.
Then, in another terminal (with your venv activated) run:
python3 -m http.server --bind 127.0.0.1 27180 --directory ../aw-server/staticDistributions that need their own categorization scheme (a research build, a company-wide deployment, ...) can ship one or more preset category sets with the bundle, instead of patching the built-in defaults:
AW_PRESET_CATEGORY_SETS="$(cat mypreset.json)" npm run buildwhere mypreset.json holds a list of category sets (the same shape the
categorization settings page imports/exports):
[
{
"id": "mypreset",
"categories": [
{
"name": ["Work"],
"rule": { "type": "regex", "regex": "^Work$" },
"data": { "color": "#0F0" }
}
]
}
]When a build ships presets, the first preset in the list is active by default on installs with no stored categorization. Remaining presets are available in Settings → Categorization for the user to enable. Users who already configured categories keep theirs — presets only show up as additional sets. A set the user has edited and saved always wins over the preset definition with the same id.
Embedders that can set a global before the app boots (Tauri, Android WebView,
custom launchers) may instead assign the same payload to
window.__AW_PRESET_CATEGORY_SETS__, which avoids rebuilding the bundle.
Regex compatibility note: preset regexes are validated against JavaScript
syntax, but they are also passed to the Python-backed categorization engine for
server-side queries. Use patterns compatible with both engines: basic groups,
quantifiers, character classes, and anchors are safe. Avoid JS-only
constructs such as named-capture-group syntax ((?<name>...)) — use the
Python form ((?P<name>...)) or omit named groups entirely.
Malformed presets are logged and ignored rather than breaking the UI.
See src/util/presetCategories.ts.
Tests can be run with:
npm testThere are also E2E tests. You need to have an aw-server and the web UI running in development mode (with npm run serve, as instructed above). After you have that setup, you can run the tests with:
make test-e2eFor development, you'll also have to add/change CORS configuration in the aw-server configs by adding cors_origins = http://localhost:27180 to your
configuration file /activitywatch/aw-server/aw-server.toml under respective sections (server-testing section when running server in testing mode).
One of the first things that happen in the application is the execution of src/main.js. This loads things such as bootstrap-vue and a bunch of other stuff that's globally used (filters, resources).
The main.js file then loads the src/App.vue file, which is the root component of the application.