search

ActivityWatch / aw-watcher-window-wayland

Window and AFK watcher for some Wayland compositors
Mozilla Public License 2.0
57 stars 14 forks source link

Does not wait for server to start and fails #10

Open MistrKernnunos opened 2 years ago

MistrKernnunos commented 2 years ago

When starting from aw-qt the wayland-window-watcher calls the aw-server before it starts.

johan-bjareholt commented 2 years ago

Not sure if this should be reported for aw-qt or for aw-watcher-window-wayland.

ErikBjare commented 2 years ago

aw-qt takes some precautions to start the server before watchers (and sleeps ~1s in between to give the server time to start).

IMO, an unavailable server should not lead to a crash/error, it should just try again later (or even better, queue up the events).

johan-bjareholt commented 2 years ago

@ErikBjare 1s sounds racy, why not poll if the aw-server port is up or something?

I agree that it's good if watchers wait and queue up events, but at the same time the watcher should eventually tell the user that it's not connected, and the usual way to do that is to shutdown/crash.

meliache commented 1 year ago

I think I saw the same when I tried running the watcher with

aw-qt --autostart-modules aw-server,aw-watcher-window-wayland

Then I get the error dialogue

Module aw-watcher-window-wayland quit unexpectedly Details: No log file found

It gives me the option to restart and when I do everything works. Is there a workaround to this until this is fixed? Can I start the server and wayland watcher manually and then connect aw-qt to them afterwards? Ideally in a scriptable way that doesn't requite user input, so that I can put it into my sway config.

UPDATE:

I fixed that by hardcoding a 3s sleep in the main.rs of this wayland watcher. Have almost no rust experience so asked chatgpt how to do that (thread::sleep(Duration::from_secs(3))). But with some knowledge of rust and the codebase it should be trivial to add retries of with a timeout to the relevant parts of the code. Though I agree that if would be better to check first that this is not an issue with the activity-watcher codebase and that the API is correctly used, before doing such workaround.