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: left-click does nothing on AppIndicator icons (menu only opens on right-click)
Reported by DavidGudovic · filed Oct 5, 2026Closed upstream on 2026-10-06 by its own reporter DavidGudovic, as a duplicate of #10339 (R-930). GitHub close reason: duplicate.
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?
- Not yet mapped to any requirement or component.
- 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?
- Our staff decide whether the report is valid. Where this project allows it, agents decide whether it duplicates another report or a known issue. No decision has been recorded yet.
Original report
System details
AMD Ryzen 7 9800X3D, NVIDIA RTX 5070 Ti, Omarchy 4.0.4 (quickshell 0.3.1, libayatana-appindicator 0.6.0)
What's wrong?
Left-clicking the tray icon of an AppIndicator-based app does nothing. The app's menu only opens on right-click. On GNOME (AppIndicator extension) and KDE, a left-click on these icons opens the menu, so apps written for that behaviour look broken in the Omarchy bar.
Steps to recreate
- Run any app that uses
libayatana-appindicator/libappindicatorfor its tray icon (an indicator with a menu and nothing else). - Left-click its icon in the bar: nothing happens.
- Right-click it: the menu opens as expected.
Cause
shell/plugins/bar/widgets/Tray.qml routes a left-click like this:
} else if (trayItemRoot.modelData.onlyMenu) {
trayItemRoot.displayMenu(mouse)
} else {
trayItemRoot.modelData.activate()
}AppIndicator items fall into the activate() branch, but they cannot handle it:
- They don't export the
ItemIsMenuproperty at all, soonlyMenuis false:
$ busctl --user get-property :1.39 /org/ayatana/NotificationItem/io_github_otptray org.kde.StatusNotifierItem ItemIsMenu
Failed to get property ItemIsMenu on interface org.kde.StatusNotifierItemActivateis listed on the interface but has no handler:
$ busctl --user call :1.39 /org/ayatana/NotificationItem/io_github_otptray org.kde.StatusNotifierItem Activate ii 0 0
Call failed: No handler for Activate- The menu itself is exported correctly (
Menupoints at/org/ayatana/NotificationItem/<id>/Menuandcom.canonical.dbusmenu GetLayoutreturns the full layout), which is why right-click works.
So the left-click is sent, rejected by the app, and silently dropped.
Possible fixes
Quickshell's SystemTrayItem does not report a failed activate() to QML, so the bar can't simply fall back to the menu the way Plasma does. Options I can see:
- Treat AppIndicator items as menu-only. They can be recognised by their object path (
/org/ayatana/NotificationItem/...), which the bar would have to read fromRegisteredStatusNotifierItemson the watcher, since the tray item doesn't expose it. - Have Quickshell expose the activation failure (or fall back itself), then show the menu on failure.
- Open the menu on left-click for every item that has one. Simple, but it would change apps where left-click toggles a window.
I'm happy to send a PR for whichever approach you prefer.
View raw text
### System details
AMD Ryzen 7 9800X3D, NVIDIA RTX 5070 Ti, Omarchy 4.0.4 (quickshell 0.3.1, libayatana-appindicator 0.6.0)
### What's wrong?
Left-clicking the tray icon of an AppIndicator-based app does nothing. The app's menu only opens on right-click. On GNOME (AppIndicator extension) and KDE, a left-click on these icons opens the menu, so apps written for that behaviour look broken in the Omarchy bar.
**Steps to recreate**
1. Run any app that uses `libayatana-appindicator` / `libappindicator` for its tray icon (an indicator with a menu and nothing else).
2. Left-click its icon in the bar: nothing happens.
3. Right-click it: the menu opens as expected.
**Cause**
`shell/plugins/bar/widgets/Tray.qml` routes a left-click like this:
```qml
} else if (trayItemRoot.modelData.onlyMenu) {
trayItemRoot.displayMenu(mouse)
} else {
trayItemRoot.modelData.activate()
}
```
AppIndicator items fall into the `activate()` branch, but they cannot handle it:
- They don't export the `ItemIsMenu` property at all, so `onlyMenu` is false:
```
$ busctl --user get-property :1.39 /org/ayatana/NotificationItem/io_github_otptray org.kde.StatusNotifierItem ItemIsMenu
Failed to get property ItemIsMenu on interface org.kde.StatusNotifierItem
```
- `Activate` is listed on the interface but has no handler:
```
$ busctl --user call :1.39 /org/ayatana/NotificationItem/io_github_otptray org.kde.StatusNotifierItem Activate ii 0 0
Call failed: No handler for Activate
```
- The menu itself is exported correctly (`Menu` points at `/org/ayatana/NotificationItem/<id>/Menu` and `com.canonical.dbusmenu GetLayout` returns the full layout), which is why right-click works.
So the left-click is sent, rejected by the app, and silently dropped.
**Possible fixes**
Quickshell's `SystemTrayItem` does not report a failed `activate()` to QML, so the bar can't simply fall back to the menu the way Plasma does. Options I can see:
1. Treat AppIndicator items as menu-only. They can be recognised by their object path (`/org/ayatana/NotificationItem/...`), which the bar would have to read from `RegisteredStatusNotifierItems` on the watcher, since the tray item doesn't expose it.
2. Have Quickshell expose the activation failure (or fall back itself), then show the menu on failure.
3. Open the menu on left-click for every item that has one. Simple, but it would change apps where left-click toggles a window.
I'm happy to send a PR for whichever approach you prefer.
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.
No decision has been recorded yet.