Skip to content
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

Open
amsam0 opened this issue Jan 30, 2024 · 4 comments
Open

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

amsam0 opened this issue Jan 30, 2024 · 4 comments

Comments

@amsam0
Copy link

amsam0 commented Jan 30, 2024

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
Copy link
Member

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
Copy link
Author

amsam0 commented Oct 17, 2024

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
Copy link

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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants