aw-qt is not very good at managing modules

[amsam0]

In my short ActivityWatch experience, I've had some issues with aw-qt. First of all, should a module crash, aw-qt does not restart it. In particular, aw-watcher-window crashes a lot on macOS for me due to a certain application that is seemingly missing the localizedName attribute (which macos.swift unwraps, crashing the application. I will look into contributing a fix). I've resorted to having a shell script manage aw-watcher-window. Second, aw-qt randomly stopped aw-server-rust and started aw-server. This caused my data to go into the wrong database for around a day until I found out.

I suggest that aw-qt restarts a module if it crashes. I am unsure what caused the server switch, but perhaps the selected server should be a separate, more persistent configuration option.

[ErikBjare]

This is very good feedback that I've missed.

In particular, aw-watcher-window crashes a lot on macOS for me due to a certain application that is seemingly missing the localizedName attribute (which macos.swift unwraps, crashing the application. I will look into contributing a fix). I've resorted to having a shell script manage aw-watcher-window.

I've noticed I still get very rare crashes on macOS that I never pinned down the cause of. Maybe this is it.

Did you look into contributing? Would really like that if you can spare the time (if you are still using AW, all this time later).

I suggest that aw-qt restarts a module if it crashes.

Yes, on non-macOS systems you get a hard-to-ignore popup that offers a button to restart it, but afaik the macOS window manager makes it so that its easy to miss.

I've been avoiding silently auto-restarting modules if they crash, since it makes me likely to ignore bugs like that, but it's clearly not acceptable that the watcher silently dies and you "lose" the data until you notice.

Second, aw-qt randomly stopped aw-server-rust and started aw-server.

No idea what could have caused this, my only guess is a misclick or misconfiguration.

perhaps the selected server should be a separate, more persistent configuration option.

You're right about that.

We are working on https://github.com/ActivityWatch/aw-tauri, which is pretty much a replacement for aw-qt, but development is slow. This has distracted me from giving aw-qt the attention it clearly needs.

[amsam0]

I am still using ActivityWatch :). I will look into contributing a fix for the window watcher in the near future (I realize that I said I would in my original post, but I never did). The crash always happens due to a custom gtk application I wrote.

In terms of aw-qt, I have switched to managing ActivityWatch processes with launchd daemons and it's working perfectly for my needs. It auto restarts when a crash happens, and while that may not be desirable for finding bugs and such, it's the behavior that I prefer, since I don't want to have to worry about silently losing data. I also have much more faith that the watchers and server I want to run are actually running (especially since I have a shell script that runs hourly that checks if they are actually running).

[deftdawg]

I've been avoiding silently auto-restarting modules if they crash, since it makes me likely to ignore bugs like that, but it's clearly not acceptable that the watcher silently dies and you "lose" the data until you notice.

I'm here for this. ActivityWatch.app/Contents/MacOS/aw-watcher-window dies on my Mac, then I go to check on how my time was spent for the last few days and I have basically nothing except VS code and Firefox and not-afk, which is pretty annoying. I'm not sure if it's related to gtk or running out of memory or what...

The frustrating thing is aw-qt clearly knew aw-watcher-window died, because the checkmark next to aw-watcher-window was unchecked... Is there anyway to fix this so that either aw-qt dies too so I have a chance of spotting the missing try icon ( I don't have much use for aw-qt without aw-watcher-window running), or turning the tray icon red or just having some config value to auto-restart it?

We are working on https://github.com/ActivityWatch/aw-tauri, which is pretty much a replacement for aw-qt, but development is slow. This has distracted me from giving aw-qt the attention it clearly needs.

I'd love to play with this, sadly my machine (work) requires signed binaries to run, so until there's a signed .app for darwin-aarch64... I'm kind of stuck. :\

[deftdawg]

I made an attempt to build on my home Linux PC, the build tooling set-up (uses devbox+nix) for that is in this draft PR ...

ActivityWatch/aw-tauri#41

With a bit of tweaking it might also work on MacOS, I started building on my work machine before heading home and trying some more with my Linux box.

[TimeToBuildBob]

PR #121 addresses the core issues here:

• Module crash detection timer was only running once (scheduling bug) — now runs continuously every 5s
• Crashed modules are auto-restarted up to 3 times with system tray notifications
• The toggle menu item now properly handles crashed modules in a single click (was requiring two clicks)

[TimeToBuildBob]

Three more improvements to module management landed this week:

• #123 — detect an existing server on startup to avoid "Address already in use" port conflicts. When aw-qt sees something already listening on port 5600, it skips launching its own server (merged).
• #124 — suppress spurious "module not found" warnings for files that should be ignored (.gitignore / __pycache__ etc.). The module discovery log was noisy in a way that buried real issues (merged).
• #125 — add common macOS paths (/opt/homebrew/bin, ~/.local/bin) to system module search when launched from Finder. Finder strips PATH to the minimal macOS set, so Homebrew-installed modules were invisible to aw-qt unless launched from a terminal (PR open).

These don't address the broader auto-restart or server selection persistence issues (aw-tauri being the long-term answer for those), but they should make day-to-day module discovery more reliable.

[amsam0]

Unfortunate to see such a useful piece of software being filled with AI slop. I will not be updating past version 0.13.2.