~/cases/owlryLive
Owlry
Keeping a daemon-backed Wayland launcher fresh as application directories and provider state change.
→Problem
A warm daemon avoids rebuilding providers on every launch, but cached application and system state can become stale.
→Freshness
XDG application directories are watched with debounced refreshes; provider-specific paths expose explicit refresh semantics.
→Architecture
A small GTK4/Layer Shell client talks to a daemon that owns provider state and IPC.
→Trade-offs
The daemon improves readiness but introduces runtime state, reload paths and failure handling.
You
Launcher UI GTK4 · Layer Shell
Daemon warm, always ready
IPC
Providers
CLI dmenu pipe mode
Apps · Calculator · Web · …
- You summon the launcher; the UI client talks to a warm daemon.
- The daemon runs providers for apps, PATH commands, calculator, converter, clipboard, and web search.
- Results are ranked by fuzzy match and frecency.
- IPC and a dmenu-compatible CLI mode drive the same daemon from scripts.
→Decisions & trade-offs
| Decision | Why | Trade-off |
|---|---|---|
| Watch application directories | Installed applications can appear without restarting the daemon. | Filesystem events need debounce and bounded refresh behavior. |
| Keep refresh explicit per provider | Different providers have different freshness costs and semantics. | The provider manager exposes more operational surface. |
→Result
- The repository documents debounced XDG watching, provider refresh commands and systemd user-service operation.
→Evidence
- Distribution
- 1 binary
- AUR packages
- 15 → 1
- GTK4 themes
- 10
UI, daemon, and providers
Consolidated by the 2.x rewrite
Built-in themes with Lua-first config
→What I'd change today
The useful lesson is that a cache is part of the user interface once stale state changes what can be launched.