chore: add systemd service file

[tobixen]

Add systemd user service file with proper dependencies on aw-server.
Includes port readiness check to ensure server is listening before
starting the watcher.

Note: This is an alternative to running aw-qt (recommended approach).

Disclaimer: QA and testing done utilizing real stupidity. Except for that, everything is stiched together using artificial intelligence.

🤖 Generated with Claude Code

Co-Authored-By: Claude Sonnet 4.5 noreply@anthropic.com

---

Important

Adds systemd service for aw-watcher-window-wayland and updates Makefile for conditional installation and build modes.

• Systemd Service:
  • Adds aw-watcher-window-wayland.service to run the watcher without aw-qt.
  • Ensures aw-server is ready on port 5600 before starting the watcher.
  • Configures service to restart on failure with a 10-second delay.
• Makefile:
  • Adds conditional PREFIX based on SUDO_USER for user or system-wide installation.
  • Adds install target to copy binary and service file to appropriate locations.
  • Supports both release and debug build modes via CARGO_FLAGS and TARGET_DIR.
• Misc:
  • Makefile includes clean target to run cargo clean.

^{This description was created by for 5488793. You can customize this summary. It will automatically update as commits are pushed.}

[ellipsis-dev]

Caution

Changes requested ❌

Reviewed everything up to 5488793 in 2 minutes and 22 seconds. Click for details.

• Reviewed 103 lines of code in 2 files
• Skipped 0 files when reviewing.
• Skipped posting 3 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. Makefile:1

• Draft comment:
  PHONY list changed: 'package' target removed. Confirm if this removal is intentional.
• Reason this comment was not posted:
  Confidence changes required: 50% <= threshold 50% None

2. Makefile:30

• Draft comment:
  Review installation paths and systemctl invocation for the service file. Ensure user vs system service behavior is as intended.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% This comment is asking the PR author to ensure that the behavior is intended, which violates the rules. It does not provide a specific suggestion or point out a specific issue with the code.

3. aw-watcher-window-wayland.service:37

• Draft comment:
  Use an absolute path in ExecStart to ensure the binary is located correctly.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 30% vs. threshold = 50% This comment is suggesting a best practice (using absolute paths in systemd service files), which is generally good advice. However, I need to consider: 1) Is this clearly wrong as-is? No, systemd will find binaries in PATH. 2) Is this actionable? Somewhat, but it's unclear what the absolute path should be since it depends on installation location (could be ~/.local/bin/ or /usr/local/bin/). 3) The installation instructions mention "make install" to ~/.local/, but the exact path isn't specified. 4) This feels more like a "best practice" suggestion rather than a clear bug. The rules say comments should be about clear code changes required, not optional improvements unless they're very actionable. The comment could be valid - systemd documentation does recommend absolute paths for security and clarity. Using PATH lookup can be less predictable. However, many systemd services use binary names without absolute paths successfully, especially for user services where the binary is in the user's PATH. While absolute paths are a best practice, this isn't a clear bug - the service will work as written if the binary is in PATH (which it should be after installation). The comment doesn't specify what the absolute path should be, making it less actionable. This feels more like optional advice rather than a required change. This comment is suggesting a best practice improvement rather than fixing a clear bug. Since the service will work as-is (systemd searches PATH), and the comment doesn't provide a specific absolute path to use, it's not sufficiently actionable. According to the rules, I should only keep comments that clearly require a code change.

Workflow ID: wflow_Llfuxp6ZAIynCSde

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}

[tobixen]

I did a poor testing job earlier today. This seems a bit more complicated than what I had wished for. The WAYLAND_DISPLAY environment variable may differ (wayland-0 vs wayland-1). Claude suggests to export the variable from the session to systemd. I think it should be possible to do some auto-detection here as a fallback. Or perhaps it's just easier to use aw-qt :-)

I'll probably follow up this one in some few days.

[tobixen]

I forgot to follow up on this one.

I'm running both the server and many watchers through systemd (under the --user domain) today and I'm happy with that. It just works. Logs in the journal.

In aw-watcher-afk-prompt Claude set up a Makefile target setup-wayland that will edit ~/.config/sway/config" or ~/.config/hypr/hyprland.conf or tell the user to manually fix their configuration. I don't feel super-happy about this solution, but it works for me.

An alternative could be to have some logic guessing on the correct WAYLAND_DISPLAY environmental variable if it's not set. How hard can it be ... it's typically set to wayland-0 or wayland-1.

I will push the setup-wayland-solution to this pull request as for now, but I'm happy to work on alternative solutions if I could have some maintainer-thoughts on this :-)