~/cases/owlryLive
Owlry
Einen daemonbasierten Wayland-Launcher aktuell halten, während sich Anwendungsverzeichnisse und Provider-Zustand ändern.
→Problem
Ein warmer Daemon vermeidet den Neuaufbau von Providern bei jedem Start, aber gecachter Anwendungs- und Systemzustand kann veralten.
→Aktualität
XDG-Anwendungsverzeichnisse werden mit entprellten Aktualisierungen beobachtet; providerspezifische Pfade bieten explizite Aktualisierungssemantik.
→Architektur
Ein kleiner GTK4/Layer-Shell-Client spricht mit einem Daemon, der Provider-Zustand und IPC besitzt.
- Du rufst den Launcher; der UI-Client spricht mit einem warmen Daemon.
- Der Daemon betreibt Provider für Apps, PATH-Befehle, Rechner, Konverter, Clipboard und Websuche.
- Treffer werden über Fuzzy-Match und Frecency gerankt.
- IPC und ein dmenu-kompatibler CLI-Modus steuern denselben Daemon aus Skripten.
→Abwägungen
Der Daemon verbessert die Bereitschaft, führt aber Runtime-Zustand, Reload-Pfade und Fehlerbehandlung ein.
→Entscheidungen & Trade-offs
| Entscheidung | Warum | Trade-off |
|---|---|---|
| Anwendungsverzeichnisse beobachten | Installierte Anwendungen können ohne Neustart des Daemons erscheinen. | Dateisystem-Events brauchen Entprellung und begrenztes Aktualisierungsverhalten. |
| Aktualisierung je Provider explizit halten | Unterschiedliche Provider haben unterschiedliche Kosten und Aktualitätssemantiken. | Der Provider-Manager hat mehr operative Oberfläche. |
→Ergebnis
- Das Repository dokumentiert entprelltes XDG-Watching, Provider-Aktualisierungsbefehle und den Betrieb als systemd-User-Service.
→Nachweise
- Distribution
- 1 Binary
- AUR-Pakete
- 15 → 1
- GTK4-Themes
- 10
UI, Daemon und Provider
In der 2.x-Neuentwicklung zusammengeführt
Integrierte Themes mit Lua-Konfiguration
→Was ich heute anders machen würde
Die wichtige Erkenntnis: Ein Cache wird Teil der Benutzeroberfläche, sobald veralteter Zustand verändert, was gestartet werden kann.