DEV Community: Plexescor (Abhijot Singh)

I Built a Native Wayland Activity Tracker in C++23 at 16 — HPR's Journey from 10MB Hobby Project to a Real Tool

Plexescor (Abhijot Singh) — Thu, 18 Jun 2026 10:25:36 +0000

I Built a Native Wayland Activity Tracker in C++23 at 16 — HPR's Journey from 10MB Hobby Project to a Real Tool

Six weeks ago HPR didn't exist. Today it has an AUR package, a Lua 5.4 extension engine, native backends for Hyprland, GNOME, KDE, Cinnamon, and niri, a real user on Fedora GNOME 50, and its first Ko-fi donation.

This is the honest story of how that happened.

Why I built it

I'm Plexescor. I'm 16, self-taught, living in Hanumangarh, India. I wanted to know where my time actually went while coding. Every existing option was either:

A Python daemon eating 200MB of RAM
A cloud service requiring an account
An Electron app
X11-only with broken Wayland support

I run Hyprland. None of them worked properly. So I built my own.

v0.2 — The thing that actually ran

The first public release was embarrassingly simple. It tracked your active window, accumulated time per app, and wrote everything to SQLite. That's it.

But it worked. On Hyprland, GNOME, KDE, and Windows. The cross-platform part was the hardest — each compositor exposes window focus completely differently:

Hyprland: hyprctl activewindow IPC call
GNOME Wayland: no native API, required a custom shell extension
KDE: KWin D-Bus scripting via qdbus6
Windows: GetForegroundWindow() Win32 API

Four completely different implementations for one question: "what window is focused right now?"

RAM was ~10MB. CPU was 1-3%. Startup was instant. The architecture was already right even if the features weren't there yet.

v0.3 — Foundation work nobody sees

This release was almost entirely backend refactoring. I rewrote the event system into a proper pub/sub EventHub — a centralized in-process bus with typed std::variant payloads. Every thread that needed to talk to another thread went through it instead of directly touching shared state.

The shared state model also got locked down properly:

namespace AppState {
    struct AppState {
        std::string currentWindow;
        std::map<std::string, uint64_t> timeLog_PerApp;
        std::map<std::string, uint64_t> timeLog_PerTab;
        std::map<std::pair<std::string, std::string>, 
                 std::vector<uint64_t>> switchHistory;
    };
    extern AppState state;
    extern std::mutex stateMutex;
}

Lock, copy, release, work on the copy. One rule. Every thread follows it.

Not glamorous. Nobody cared. But v0.69's extension engine stress testing 1000 simultaneous threads only worked because the foundation was solid.

v0.4 — First version that felt real

Historical data view via date picker. Insights engine. Custom themes via interpreted .slint mode.

The interpreted mode deserves explanation. Slint normally compiles your UI into the binary at build time. I added a second code path that loads .slint files from disk at runtime instead. Users can now modify HPR's entire visual design without touching C++ or recompiling. Just edit the file, hit RELOAD UI, changes are live.

This was also the release where I made the architectural decision that still holds: one .db SQLite file per day, one folder per month.

~/.local/share/HPR/HPR_DB/

05-26/
01-05-26.db
02-05-26.db

A normal day is 19KB. A full year is under 50MB. You can open any specific day in DB Browser for SQLite without touching HPR. Delete last month by deleting the folder. No export step, no proprietary format.

v0.5 — Going open source

HPR originally had a free tier and a premium closed-source tier. I killed that entirely in v0.5.

Everything, current and future, is free forever. The premium version's source got merged into the main repo.

This release also added browser tab tracking without any browser extension — HPR just reads the window title. When Chrome is focused, the title contains the tab name. Parse it. Done. Works on every supported platform because they all already had window title getters.

KDE Fedora users also stopped being second-class citizens. I added auto-detection for qdbus6 vs qdbus-qt6 vs qdbus at startup so it just works regardless of distro.

v0.6 — The release that made HPR actually useful

Three things shipped together that changed what HPR was:

VS Code project tracking. No extension. No plugin. VS Code puts the project name in its window title: filename - projectname - Visual Studio Code. Strip the suffix, find the last separator, extract the project name. Works everywhere already because the window title getter existed on every platform. Per-project time breakdowns with zero setup.

Cinnamon support. org.Cinnamon.Eval D-Bus lets you evaluate JavaScript inside the live Cinnamon process. I use it to query global.display.focus_window directly. Works on both X11 and Cinnamon's experimental Wayland session with no code branching.

Native system tray on Linux. No GTK. No Qt. Pure libdbus-1. HPR registers as org.kde.StatusNotifierItem — the same protocol Discord and Steam use. Works with Waybar on Hyprland, KDE's tray, and Cinnamon's panel out of the box.

This was also the release that landed on the AUR:

yay -S hpr

v0.69 — The extension engine

This is the release I'm most proud of technically.

HPR now ships a sandboxed Lua 5.4 extension engine. Drop a .lua file into ~/.config/HPR/extensions/ and HPR loads it automatically. Each extension runs in its own isolated VM on a dedicated OS thread. A broken extension cannot affect HPR's tracking loop, UI, or any other extension.

The minimal extension:

function onTick(delta)
    print(HPR.getCurrentWindow_E())
end

That's two lines. It runs.

What you can actually do:

Read the active window in real time
Query live time logs per app, per tab, per VS Code project
Run shell commands (dangerous ones are blocked at the API level with an explicit blocklist)
Full HTTP GET/POST with custom headers
Spin up an embedded HTTP server inside your extension
Direct SQLite access — write your own tables, query any past day by date
Subscribe to HPR's internal EventHub — window switches, midnight rollover, UI ready, custom events between extensions
Push data into HPR's Slint UI and register callbacks for UI interactions
Register a fully custom window detection backend for any compositor HPR doesn't natively support
Override 26+ core C++ functions directly from Lua via the Function Overriding API

Stress test: 1000 simultaneous extensions. HPR started in under 300ms, settled at 5.6% CPU, database came up clean after a hard kill.

The first real extension I shipped alongside it was an ActivityWatch URL Parasite — it impersonates an ActivityWatch client and feeds HPR's tracking data into ActivityWatch's API, letting HPR users show up in AW dashboards without running AW's own watcher.

v0.7 — Hot reload everything

No more restarting HPR to pick up changes.

Each loaded extension now has RELOAD, DISABLE buttons. A top-level RESCAN button picks up new .lua files dropped into the folder without restarting. The RELOAD UI button reloads the entire Slint interface from disk without losing tracking state.

Iterate on your theme in real time. Fix an extension bug and reload it without losing your day's tracking data.

v0.8 — niri and the full feature set

niri support landed. Uses niri msg IPC. Works out of the box.

App Limits and Goals shipped as the first genuinely productivity-focused feature. Set a daily cap on any app — HPR sends a notification when you hit it and optionally force-quits the application automatically. Goals work the other way — set a minimum daily target and track progress live.

Advanced users can intercept the limit-reached event via the Function Overriding API and run custom Lua logic — suppress the notification, send a webhook, log it somewhere, anything.

Multi-day historical queries replaced the single date picker. Three modes: single day, last N days, custom date range. Multiple daily .db files merge on a background thread without pausing live tracking.

v0.9 — Pattern analysis and the timeline

The Day Construction Timeline maps your entire day onto a zoomable, scrollable canvas. Not just numbers — a visual record of exactly what you were doing and when.

Gap detection handles reboots and closed sessions properly. If HPR was closed for 5 hours, the naive approach stretches your last active app across the entire gap. HPR's reconstruction engine detects focus gaps and caps the preceding segment to 1 minute before transitioning to Unknown. Your logs stay accurate.

Advanced Pattern Analysis added 9 cross-day metrics. The one I find most useful personally: Focus Dip Hour — the specific hour where your concentration crashes and application switches spike most consistently across all your historical data. Mine is 3PM. Knowing that is useful.

The full metric list:

Escape Pattern — average daily switches from work app to browser
Return Rate — how often you immediately bounce back after a browser escape
Average Focus Session duration
Most Distracted Day of the week
Productive Days this week
Screen Time vs your N-day average
Focus Dip Hour
Deep Work Before Noon percentage
Weekend vs Weekday work app usage

v0.9.1 — Headless mode

HPR can now run without a UI entirely. Tray-only mode. Useful for servers, minimal setups, or anyone who just wants the tracking running in the background without a window.

Where it is now

Platform support: Hyprland, GNOME, KDE Plasma 6+, Cinnamon, niri, Windows 10/11.

Install:

# Arch Linux
yay -S hpr

# Windows
# Inno Setup installer on GitHub releases

# Linux manual
chmod +x installHPRConfigAndUi.sh && ./installHPRConfigAndUi.sh && ./HPR

First donation: $20 from Jesse Kramer. Completely voluntary. For a free open source tool built by a 16-year-old. I stared at the Ko-fi notification for a while.

GitHub: github.com/plexescor/HPR

What I actually learned

The hardest part wasn't the code. The hardest part was the Wayland ecosystem. Every compositor does everything differently and documentation is either nonexistent or buried in mailing list threads from 2019. The KDE js:: filter in the window name normalizer exists because KWin's own JavaScript runtime briefly appears as the active window during injection and silently accumulates time in your logs if you don't catch it. I found that at midnight staring at weird data.

Timing bugs are subtle. Using system_clock for duration measurement is a classic mistake — NTP corrections and DST transitions corrupt your accumulated totals. HPR uses steady_clock for measurement and system_clock only for display timestamps. Different clocks, different jobs.

Ship early. v0.2 was embarrassingly minimal. I shipped it anyway. The feedback shaped everything that came after.

The architecture matters more than the features. The EventHub, the single mutex over shared state, the one-file-per-day database layout — these decisions made every subsequent feature straightforward to add. Bad early architecture would have made the extension engine impossible.

What's next

The foundation is done. What comes next is polish, more compositor backends if people ask for them, and wherever the extension ecosystem goes.

If HPR is useful to you, a Ko-fi helps keep it going. If you hit a bug, open an issue — I respond to every one.

HPR is free and open source. Built solo. C++23, Slint 1.16.1, SQLite3, Lua 5.4.
github.com/plexescor/HPR

The Best Activity Trackers for Linux Wayland in 2026

Plexescor (Abhijot Singh) — Thu, 18 Jun 2026 10:13:50 +0000

The Best Activity Trackers for Linux Wayland in 2026

If you're on Linux Wayland and want to know where your time actually goes, your options are surprisingly limited. Most activity trackers were built for X11, assume a web dashboard, or drag a Python runtime and 200MB of RAM into your session. Here's an honest breakdown of what's actually worth using in 2026.

1. HPR — Human Pattern Recorder

GitHub | Free | Open Source | C++23

Full disclosure: I built this. I'm a 16-year-old solo developer in India and HPR is my main project. I'm including it first because it's genuinely the best option for Wayland-native Linux tracking — not because I made it.

What it actually does

HPR polls your active window every 50ms, all day, and builds a complete log of where your time went. No extensions. No accounts. No server. Just a compiled C++23 binary that starts instantly and writes to local SQLite.

You get three things live:

What you're in right now
Total time per app today
Your complete switch history, timestamped

Historical queries work across any date range — pick a single day, last N days, or a custom range. Multiple daily .db files get merged on a background thread without ever pausing live tracking.

Why it's different on Wayland

Most trackers bolt on Wayland support as an afterthought. HPR was built with native Wayland backends from day one:

Platform	Backend
Hyprland	`hyprctl` IPC
GNOME (Wayland)	Custom GNOME Shell extension
KDE Plasma 6+	KWin D-Bus scripting
Cinnamon	`org.Cinnamon.Eval` D-Bus
niri	`niri msg` IPC
Windows 10/11	Win32 API

No hacks. No XWayland fallback. Each compositor gets its own proper backend.

Features that nothing else has

Browser tab tracking without extensions — HPR reads the window title directly. When Chrome or Firefox is focused, it parses the tab name automatically. No browser extension to install, no permissions to grant.

VS Code project tracking — HPR parses VS Code's window title to extract the active project name. You get per-project time breakdowns with zero setup.

App Limits and Goals — set a daily cap on any app. Hit the limit and HPR sends a notification. Optionally it force-quits the app. Goals work the other way — set a minimum daily target and track progress live.

Day Construction Timeline — a zoomable, scrollable visual timeline of your entire day. Preset zoom levels from 1h to 24h. Gap detection handles reboots and closed sessions cleanly.

Advanced Pattern Analysis — 9 cross-day metrics including escape pattern (how often you jump from work to browser), return rate, peak focus hour, deep work before noon percentage, and weekend vs weekday comparison.

Lua 5.4 Extension Engine — drop a .lua file into your extensions folder and HPR loads it automatically. Each extension runs in an isolated VM on its own thread. You can read the active window in real time, query the SQLite database, subscribe to internal events, build custom UI panels, and override 26+ core C++ functions from Lua. Stress tested to 1000 simultaneous extensions.

Performance

~8MB RSS on Windows
~22MB private footprint on Linux (htop shows ~47MB but ~25MB of that is shared Mesa/LLVM GPU pages — not HPR's actual cost)
1-3% CPU during normal use
~19KB per day of tracking data
Instant startup

Privacy

No telemetry by default. No accounts ever. The networking libraries are compiled in to power the Lua HTTP API and optional anonymous analytics — but HPR itself never phones home unless you explicitly enable it.

Install

# Arch Linux
yay -S hpr

# Windows
# Download the Inno Setup installer from GitHub releases

# Linux manual
chmod +x installHPRConfigAndUi.sh && ./installHPRConfigAndUi.sh && ./HPR

The honest part

HPR is v0.9 and I'm the only developer. It's not as mature as ActivityWatch. If you need a battle-tested tool with years of production use and a full web dashboard, read the next section. If you're on Wayland, care about memory footprint, and want Lua scripting, give HPR a try.

Ko-fi link is in the README if it's useful to you.

2. ActivityWatch

activitywatch.net | Free | Open Source | Python

ActivityWatch is the most mature open source activity tracker available. It has been in active development for years, has a proper web dashboard, a plugin ecosystem, browser extensions, and a large community. If you want something that just works and has been battle-tested by thousands of users, this is the honest recommendation.

What it does well

Full web dashboard with detailed visualizations
Browser extensions for Chrome and Firefox
Plugin ecosystem — community has built integrations for VS Code, AFK detection, and more
Cross-platform (Linux, Windows, macOS)
REST API for building your own integrations
Active community and regular releases

Wayland situation

ActivityWatch's Wayland support has historically been its weak point. The core watcher uses wnck which is X11-based. Community-maintained Wayland watchers exist but require separate installation and vary in reliability per compositor. On Hyprland and niri especially, you'll need to find and configure a third-party watcher.

Resource usage

ActivityWatch runs a local web server, a Python daemon, and several watcher processes. Expect 200MB+ RAM in real use. It also takes several seconds to start. For a background daemon that runs all day this matters on lower-spec hardware.

Bottom line

ActivityWatch is the right choice if you want maturity, community, and a full dashboard. It's what HPR is measured against. The gap is Wayland support and resource footprint.

3. Wakatime (self-hosted: Wakapi)

wakapi.dev | Free tier | Open Source self-hosted option

Wakatime is a different category — it tracks coding time specifically, not general window focus. If your main goal is understanding how much time you spend in your editor and across projects, it's worth knowing about.

What it does

Editor plugins (VS Code, Neovim, JetBrains, etc.) send heartbeats to a Wakatime-compatible server every time you type. You get per-project, per-language, and per-file breakdowns of coding time.

Wakapi is the self-hosted open source server that's compatible with the Wakatime API. Run it locally, point your editor plugins at it, and all your data stays on your machine.

What it doesn't do

Wakatime only knows about time in editors. It has no awareness of browser usage, application switching, or anything outside your coding environment. It's a coding time tracker, not a general activity tracker.

Wayland situation

Irrelevant — it runs entirely through editor plugins, no window system access needed.

Bottom line

If your specific question is "how much time did I actually spend coding vs everything else" and you don't care about the rest, Wakapi is elegant and lightweight. For general activity tracking it's out of scope.

Quick Comparison

	HPR	ActivityWatch	Wakapi
Native Wayland	✅ All major compositors	⚠️ Community watchers	✅ N/A (editor plugins)
RAM usage	~22MB private	200MB+	Minimal
Web dashboard	❌	✅	✅
Browser tab tracking	✅ Built-in	✅ Extension required	❌
VS Code projects	✅ Built-in	✅ Plugin required	✅ Built-in
App limits/goals	✅	❌	❌
Scripting/extensions	✅ Lua 5.4	❌	❌
Maturity	v0.9, solo dev	Mature, team	Mature
Startup time	Instant	Several seconds	Server
Coding-specific	❌	❌	✅

Which one should you use

You're on Hyprland, niri, or GNOME Wayland and want something lightweight → HPR. It has native backends for all of them, starts instantly, and uses almost no RAM.

You want something mature with a web dashboard and don't mind Python overhead → ActivityWatch. It's been around longer and has a larger ecosystem.

You specifically want to track coding time by project and language → Wakapi with the VS Code/Neovim plugin.

All three are free and open source. There's no wrong answer — it depends on what you're optimizing for.``

How I built a scriptable Lua extension engine inside my C++ activity tracker (and almost lost my mind to deadlocks)

Plexescor (Abhijot Singh) — Mon, 01 Jun 2026 11:46:27 +0000

Hey!

I've been building HPR, an open source activity tracker and window tracker written in C++23. It watches your active window, builds a history of where your time went, and runs locally with zero accounts and zero telemetry. Think of it as a lightweight ActivityWatch alternative with native Wayland support.

At some point I decided it wasn't enough to just track windows. I wanted people to be able to extend it. So I built a Lua extension engine into it. Here's how that went.

The basic idea

Every .lua file you drop into the extensions folder gets picked up automatically. HPR scans the directory recursively, loads each file into its own sol::state, registers the API, and spins up a dedicated thread for it. Each extension runs completely isolated from everything else. A slow or broken extension can't freeze the UI or corrupt the tracking loop.

The lifecycle is simple. You define three functions:

function init()
    return 500 -- tick interval in ms
end

function onTick(delta)
    -- called every 500ms
end

function onExit()
    -- cleanup
end

init returns how often you want onTick to fire. That's it. Everything else is opt-in through the API.

The API

This is where it gets actually useful. From Lua, an extension can:

Read the currently focused window with HPR.getCurrentWindow_E()
Query and write to the SQLite database directly with HPR.dbQuery_E() and HPR.dbExecute_E()
Subscribe to internal events like WINDOW_CHANGED, MIDNIGHT_ROLLOVER, HISTORY_LOADED_SINGULAR
Register completely custom window detection backends for compositors HPR doesn't natively support
Set UI properties and register callbacks on the Slint UI from Lua
Make HTTP requests, start an HTTP server, parse JSON, read and write CSV files
Stop and resume the window tracking loop entirely

That last one sounds weird but its how the AFK detection works in one of the extensions I built, more on that in a second.

The hardest parts

Honestly the code itself wasnt the worst part. The worst part was deadlocks.

The Lua state is not thread safe. The Slint UI is also not thread safe and must only be touched from its event loop thread. The shared app state has its own mutex. So you have extension threads, the Slint event loop thread, the window poller thread, and the database writer thread all needing to talk to each other without stepping on each other.

The solution was a recursive_mutex per extension that wraps every Lua call, and slint::invoke_from_event_loop for anything that touches the UI. Callbacks registered from Lua that get fired by Slint acquire the Lua mutex before calling back into Lua. It took a while to get right.

The other fun one was cyclic table detection. If a Lua extension pushes a self referential table into a UI property, without protection you get a stack overflow and a segfault. I added a visited set that tracks table pointers during the conversion and bails out with an error message if it sees a cycle instead of recursing forever.

A real example: impersonating ActivityWatch

One of the extensions I wrote is called AW Parasite. It starts an HTTP server on port 5600, which is the default ActivityWatch port. aw-watcher-web and aw-watcher-afk both think they're talking to a real ActivityWatch instance. They send heartbeats, the extension processes them, accumulates URL time and AFK status, writes everything into the HPR SQLite database, and updates the UI through HPR.setUiProperty_E.

When the user goes AFK, the extension calls HPR.stopTracking_E() to pause the main activity window tracker. When they come back it calls HPR.startTracking_E(). The whole thing is about 200 lines of Lua and it works on both Wayland and Windows because its just HTTP.

Hot reload

You can load, unload and reload individual extensions from the UI without restarting HPR. There's also a rescan button that picks up new .lua files you dropped in after launch. Unloading sets running = false on the extension's thread and gives it 450ms to exit cleanly. If it doesnt, the thread gets detached and a warning is logged. Native extensions (.dll / .so) are also supported for cases where Lua isnt enough, though those run outside the sandbox.

HPR is fully free and open source. If any of this sounds interesting the repo is at Github. Would appreciate a star if you find it useful.

How I built native Wayland window tracking across Hyprland, GNOME and KDE in C++23

Plexescor (Abhijot Singh) — Sat, 16 May 2026 11:24:22 +0000

If you've ever tried to get the currently focused window on Wayland, you know it's a mess. There's no unified API. Every compositor does it differently. X11 had _NET_ACTIVE_WINDOW and everyone just used that. Wayland deliberately doesn't have an equivalent for security reasons, which means every tracker, every productivity tool, every anything that needs to know what you're looking at has to implement a different solution per compositor.

I ran into this while building HPR, an activity tracker that watches your active window every 50ms and logs time per app. Here's how I solved it for the three most common Wayland compositors.

Hyprland

Easiest of the three. Hyprland exposes an IPC socket and a CLI tool called hyprctl. One command gives you the active window as JSON:

hyprctl activewindow -j | jq -r '.class'

That's it. No extension, no setup, no workarounds. Just works on first launch. The .class field gives you the application class which is consistent and clean. I call this every 50ms from a background thread and it holds up fine.

GNOME

GNOME on Wayland is the painful one. There's no official API for getting the active window from outside the compositor. The only working solution I found is a shell extension called window-calls-extended which exposes a DBus interface you can query:

gdbus call --session --dest org.gnome.Shell \
  --object-path /org/gnome/Shell/Extensions/WindowsExt \
  --method org.gnome.Shell.Extensions.WindowsExt.FocusClass

This returns the window class wrapped in some dirty output you have to parse. HPR checks on startup whether the extension is active. If it isn't, it tells the user exactly what to do instead of silently returning garbage. Because GNOME can't hot-reload shell extensions you log out and back in once after installing. Every launch after that is automatic.

One thing worth knowing: GNOME shell extensions are sandboxed differently across GNOME versions and some distributions patch the shell in ways that break extension APIs. If you're supporting GNOME you need to test across versions.

KDE Plasma

KDE was the one I expected to be easy and wasn't. KDE exposes KWin scripting via qdbus6 which lets you inject JavaScript into the compositor and read the output. The active window class comes from workspace.activeWindow.resourceClass.

The problem is KWin doesn't give you a clean return value. The script runs, prints output to the system journal with a js: prefix, and you have to scrape it back out:

echo 'print(workspace.activeWindow.resourceClass);' > /tmp/kwin_active.js
S=$(qdbus6 org.kde.KWin /Scripting org.kde.kwin.Scripting.loadScript /tmp/kwin_active.js kwin_tmp_$$)
T=$(date '+%Y-%m-%d %H:%M:%S')
qdbus6 org.kde.KWin /Scripting/Script$S org.kde.kwin.Script.run > /dev/null 2>&1
sleep 0.1
journalctl --since "$T" -o cat | grep '^js:' | tail -n 1 | sed 's/^js: //'

Yes this is a hack. It forks a shell, injects JS, scrapes the journal, and cleans up after itself every 50ms. Somehow it lands at around 1% CPU. I tested every other approach I could find. None of them worked reliably across KDE configurations. This one does.

One side effect: during the JS injection, KWin's own runtime briefly appears as the active window. If you don't filter it out, strings like js::kwin_tmp_1234 silently accumulate time in your logs. HPR filters anything containing js:: before it ever touches the data.

The normalization layer

Each backend returns a raw string. Raw strings from OS window APIs are inconsistent and noisy. HPR runs every return value through a shared normalization function before doing anything with it. This filters out compositor artifacts, plasma shell entries, null strings, and KWin JS runtime noise. New backends inherit this filtering automatically.

Platform detection

HPR reads $XDG_CURRENT_DESKTOP and matches substrings. Simple, works for 99% of setups. Non-standard session variables or nested compositors can confuse it but that's an edge case worth documenting rather than engineering around.

The project

HPR is open source, C++23, Slint UI, SQLite3 bundled. If you're on Wayland and want an activity tracker that actually works without a Python runtime or an embedded web server, give it a try.

GitHub: github.com/plexescor/HPR

If you've solved Wayland window detection in a cleaner way especially on KDE, I'd genuinely like to know.