search

ActivityWatch / aw-qt

Tray icon that manages ActivityWatch processes, built with Qt.
Mozilla Public License 2.0
27 stars 33 forks source link

aw-qt is not very good at managing modules #103

Open amsam0 opened 10 months ago

amsam0 commented 10 months ago

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 commented 1 month ago

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 commented 1 month ago

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).