Does not wait for server to start and fails

[MistrKernnunos]

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

[johan-bjareholt]

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

[ErikBjare]

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]

@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]

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.