-
-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
aw-qt is not very good at managing modules #103
Comments
This is very good feedback that I've missed.
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).
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.
No idea what could have caused this, my only guess is a misclick or misconfiguration.
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. |
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). |
I'm here for this. The frustrating thing is
I'd love to play with this, sadly my machine (work) requires signed binaries to run, so until there's a signed |
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 ... 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. |
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.
The text was updated successfully, but these errors were encountered: