Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.
Tray icons from GTK apps using libayatana-appindicator never register (StatusNotifierWatcher property read fails)
Reported by yansena · filed Sep 19, 2026 · open at source
At a glance
- 1 · What is claimed?
- Only the report text below — no validator has restated it as checkable claims yet.
- 2 · What does it affect?
- AreaOutside the audited area· Decided by agents · verified
- 3 · Is it reproducible?
- No validation has been run yet.
- 4 · What remains unclear?
- Not validated yet: no claims, no reproducer.
- 5 · What happens next?
- Decided by agents and verified by a second, independent agent — see the decision.
Original report
Apps that create a tray icon via libayatana-appindicator (e.g. Tauri apps on Linux, many Electron apps) never appear in the omarchy-shell bar's tray widget, and no error is printed by the app itself.
Root cause
omarchy-shell's StatusNotifierWatcherAdaptor doesn't correctly answer a standard org.freedesktop.DBus.Properties.Get for RegisteredStatusNotifierItems:
WARN qt.dbus.integration: Could not find slot StatusNotifierWatcherAdaptor::RegisteredStatusNotifierItemslibayatana-appindicator performs this kind of property check as part of its watcher-detection handshake before calling RegisterStatusNotifierItem. When the check errors, it silently gives up — confirmed via dbus-monitor filtered on interface='org.kde.StatusNotifierWatcher': zero registration traffic is ever sent by the app.
Repro
- Run any Tauri v2 app with a tray icon (
tauri-plugin-positioner+TrayIconBuilder) under omarchy-shell. - The tray icon never appears in the bar's tray widget.
- No error in the app's own logs — only the unrelated
libayatana-appindicator-WARNING: libayatana-appindicator is deprecatednotice.
Environment
- omarchy 4.0.4-1
- Hyprland / Wayland (
XDG_SESSION_TYPE=wayland,XDG_CURRENT_DESKTOP=Hyprland) libayatana-appindicator0.6.0-2omarchy-shellrunning via quickshell,org.kde.StatusNotifierWatcherowned by PID ofomarchy-shell- Confirmed the watcher does work for at least one app (Spotify, registered via the ayatana bridge as
org.ayatana.NotificationItem/spotify_client), so this appears specific to how the property-read path is exposed for clients that probe it the standard way.
View raw text
Apps that create a tray icon via `libayatana-appindicator` (e.g. Tauri apps on Linux, many Electron apps) never appear in the omarchy-shell bar's tray widget, and no error is printed by the app itself. ## Root cause `omarchy-shell`'s `StatusNotifierWatcherAdaptor` doesn't correctly answer a standard `org.freedesktop.DBus.Properties.Get` for `RegisteredStatusNotifierItems`: ``` WARN qt.dbus.integration: Could not find slot StatusNotifierWatcherAdaptor::RegisteredStatusNotifierItems ``` `libayatana-appindicator` performs this kind of property check as part of its watcher-detection handshake before calling `RegisterStatusNotifierItem`. When the check errors, it silently gives up — confirmed via `dbus-monitor` filtered on `interface='org.kde.StatusNotifierWatcher'`: zero registration traffic is ever sent by the app. ## Repro 1. Run any Tauri v2 app with a tray icon (`tauri-plugin-positioner` + `TrayIconBuilder`) under omarchy-shell. 2. The tray icon never appears in the bar's tray widget. 3. No error in the app's own logs — only the unrelated `libayatana-appindicator-WARNING: libayatana-appindicator is deprecated` notice. ## Environment - omarchy 4.0.4-1 - Hyprland / Wayland (`XDG_SESSION_TYPE=wayland`, `XDG_CURRENT_DESKTOP=Hyprland`) - `libayatana-appindicator` 0.6.0-2 - `omarchy-shell` running via quickshell, `org.kde.StatusNotifierWatcher` owned by PID of `omarchy-shell` - Confirmed the watcher *does* work for at least one app (Spotify, registered via the ayatana bridge as `org.ayatana.NotificationItem/spotify_client`), so this appears specific to how the property-read path is exposed for clients that probe it the standard way.
Validation
Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.
Linked
Not linked to any known issue, other report or change yet.
Decision
Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.
- Out of scopeDecided by agents · verified · 2026-10-09 16:04 UTC