Third-party menu plugins (e.g. omarchy.menu clones) get an empty Apps list: manifests passed through the panel Instantiator lose array types

[ekollof]

System details

AMD Ryzen AI 9 HX 370 (Radeon 890M), Omarchy dev (430e6791, tracking upstream/quattro), Quickshell 0.3.1-1, Hyprland (Wayland). omarchy-debug output can be attached on request.

What's wrong?

Any third-party menu plugin — including the supported clone of the built-in omarchy.menu — gets an empty Apps list ("Nothing here yet"). The app-list data itself is present and healthy; the plugin just never receives the application-library facade it is supposed to get.

Steps to reproduce

1. Clone the built-in menu plugin so a third-party copy takes over the apps menu, e.g. copy shell/plugins/menu/ to ~/.config/omarchy/plugins/ekollof.menu/ and set "omarchy": { "clonedFrom": "omarchy.menu" } in its manifest.json (this is the layout omarchy plugin clone produces).
2. Make sure the clone is the enabled menu in ~/.config/omarchy/shell.json (the registry's resolveEnabledId maps omarchy.menu to the active clone via clonedFrom).
3. omarchy restart shell, then press Super+Alt+Space and open "Apps...".

Expected: the full application list. Actual: "Nothing here yet", every time, across restarts.

Root cause

The panel loader instantiates panel/menu plugins through a Quickshell Instantiator whose model is a JS array of entry objects that each carry the plugin manifest. On assignment the loader does:

// shell.qml, panel loader onLoaded
if ("shell" in item) item.shell = shell.pluginShellFor(panelEntry.manifest)

panelEntry.manifest here is modelData — it has crossed Qt's C++ model boundary, so the manifest object arrives as a QVariantMap (observable: Object.keys() order becomes alphabetical) and the nested kinds array is no longer a JS Array:

// capability check, shell.qml
function manifestHasKind(manifest, kind) {
  return !!manifest && Array.isArray(manifest.kinds)
    && manifest.kinds.indexOf(kind) !== -1
}

Array.isArray(QVariantList) is false, so manifestHasKind(manifest, "menu") is false for every panel-delivered manifest, and createScopedPluginShell builds the scoped plugin shell API with appLibrary: null:

appLibrary: shell.manifestHasKind(manifest, "menu")
  ? shell.pluginAppLibraryFor(cacheKey, key) : null,

The menu plugin's mergeAppRows() then sees root.shell.appLibrary == null and early-returns — the empty state.

First-party plugins are unaffected only by accident: pluginShellFor returns the shared host shell when manifest.__isFirstParty is truthy, and booleans survive the QVariant round-trip. Any third-party manifest with kind "menu" (clones, community menu plugins) silently loses the facade. pluginShellCapabilityProfile has the same exposure: it computes the cached API's profile via manifestHasKind, so the capability cache itself is poisoned by the QVariant-ified manifest — an earlier, correct API gets revoked and replaced by a no-menu-capability one about a second after startup, when the panel model delivers.

Instrumented evidence from a repro (same plugin, two delivery paths):

KIND-DEBUG manifest=ekollof.menu isArray=true  idx=0 result=true   // from registry (configureBar path)
KIND-DEBUG manifest=ekollof.menu isArray=false     result=false    // from panel Instantiator modelData
SHELL-DEBUG created api key=ekollof.menu appLibrary=present        // early, correct
SHELL-DEBUG created api key=ekollof.menu appLibrary=NULL           // after panel model delivers

Proposed fix

Capability decisions should run on the registry's raw manifest for the id, not on a copy that may have crossed a model boundary. PluginRegistry.installedPlugins always holds the original JS objects (kinds is a real array there):

--- a/shell/shell.qml
+++ b/shell/shell.qml
@@ -725,7 +725,13 @@ ShellRoot {
     if (!manifest || manifest.__isFirstParty) return shell
     var key = String(manifest.id || "")
     if (!key) return null
-    return shell.createScopedPluginShell(manifest, key, true, shell.pluginHasBarCapabilities(manifest))
+    // A manifest handed through a QObject model (e.g. the panel
+    // Instantiator's modelData) arrives as a QVariantMap: nested arrays are
+    // no longer JS Arrays, so kind checks would under-declare capabilities.
+    // The registry always holds the raw manifest for this id; prefer it.
+    var raw = shell.pluginRegistry ? shell.pluginRegistry.installedPlugins[key] : null
+    var resolved = raw && raw.id === key ? raw : manifest
+    return shell.createScopedPluginShell(resolved, key, true, shell.pluginHasBarCapabilities(resolved))
   }

Verified on the affected machine: with this change the cloned menu's Apps submenu is fully populated after omarchy restart shell, and the debug logging above shows a single API creation with the facade intact.

Alternatives worth considering (maintainer's call)

• Make manifestHasKind (and pluginShellCapabilityProfile) duck-typed instead of relying on Array.isArray, e.g. treat any object with length and index access as a list. Fragile, and leaves pluginHasBarCapabilities/isAuthenticationService with the same trap.
• Stop routing manifests through the panel model: carry only the plugin id (plus scalar fields) in the entry objects and have the delegate fetch pluginRegistry.installedPlugins[id] directly. Cleanest, but a larger refactor of computePanelEntries and the delegate bindings.

The proposed one-place fix also keeps item.manifest assignments safe as-is, since those already go through publicPluginManifest's JSON round-trip, which restores real arrays.

[matdehaast]

Confirmed the same symptom on another machine on 2026-09-09:

• omarchy-dev 4.0.0.r2090.g5b91db5-1
• Quickshell 0.3.1-1
• Hyprland 0.56.2-2
• Intel Core i7-12700 / UHD Graphics 770

An existing local clone of omarchy.menu, with kinds: ["menu", "bar-widget"] and omarchy.clonedFrom: "omarchy.menu", showed “Nothing here yet” in Apps and no matches when searching for an installed Slack webapp. Its .desktop entry was present and valid. Restarting the shell did not restore the list.

Temporary instrumentation immediately before the early return in the clone's mergeAppRows() confirmed:

WARN qml: APP_DIAG library=null

The clone's appLibrary binding was the stock root.shell ? root.shell.appLibrary : null. We did not independently instrument the QVariant/Array.isArray boundary described above, but the observed failure is consistent with this report.

A local workaround in the cloned Menu.qml restored the app list, and the user confirmed search works again:

import "file:/usr/share/omarchy/shell/services" as OmarchyServices

// Inside the menu Item:
OmarchyServices.AppLibrary { id: fallbackAppLibrary }
readonly property var appLibrary: root.shell && root.shell.appLibrary
  ? root.shell.appLibrary : fallbackAppLibrary

This is a workaround that instantiates a separate library, not a proposed upstream fix. No packaged Omarchy files were modified. The first affected update was not established on this machine.

[evindor]

Confirmed, hitting the same issue with my plugin Keystroke

[NonMirror]

Consolidation note

This appears to be the first/canonical report of the cluster. The defect is reproduced and fixed on current quattro (692c02c): running #10671's test/shell.d/panel-menu-capability-test.sh on unpatched HEAD fails with example.menu: wrong app-library grant, and passes once its three production hunks are applied.

Duplicate reports: #10871 #10876 #10908 #10909 #10954 #10990 #11006 #11013 #11028 #11068 #11073 #11190
Competing PRs: #10671 #10785 #10903 #11075 #11079 #11193 #11199 #11241 #11285

Suggested consolidation: review #10671 (oldest, real Instantiator fixture + iconIndexChanged), or #11075 for the centralized variant and #11079 if the facade-revocation/lifecycle part is preferred. The kinds predicate is best kept strict (Array.isArray): "menus".indexOf("menu") === 0, so an indexOf-only check would read a malformed string kinds as a menu declaration that grants the app-library capability.

[ekollof]

Reporter of this issue here (issue body + diagnosis). Independent verification data point for the consolidation:

Repro environment: omarchy-dev 4.0.0.r2071.ga703092-1 (dev-linked tree at 430e6791, tracking upstream/quattro), Quickshell 0.3.1-1, real hardware (AMD Strix Point / Radeon 890M, 3-monitor Hyprland session). Affected plugin: a local clone of omarchy.menu (~/.config/omarchy/plugins/ekollof.menu/, manifest kinds: ["menu","bar-widget"], clonedFrom: omarchy.menu) — the supported clone workflow, so this is not limited to external launchers like Omalaunch.

Instrumented confirmation of the mechanism (same findings as the PR analysis, gathered before seeing any PR): the registry holds the manifest with Array.isArray(kinds) === true, while the same manifest delivered via the panel Instantiator's modelData arrives as a QVariantMap — keys sorted alphabetically, kinds still serializing as ["menu","bar-widget"] but Array.isArray(kinds) === false. Consequence observed in logs: an early, correctly-granted PluginShellApi (appLibrary=present) is revoked and replaced by a no-menu-capability API (appLibrary=NULL) about a second after startup, when the panel model delivers — the pluginShellCapabilityProfile cache poisoning path this issue's body describes. The menu then sees shell.appLibrary == null and renders "Nothing here yet".

Local fix, verified on the affected host: same family as #10671 — re-resolve the raw registry manifest before capability checks. Mine does it inside pluginShellFor (shell.qml), #10671 does it at the panel delegate (readonly property var manifest: shell.pluginRegistry.installedPlugins[pluginId]). Both keep the Array.isArray predicate strict, which I agree is the right call: the failing manifests still support indexOf, so an indexOf-only check would silently grant from malformed data. After the fix, the clone's Apps submenu is fully populated and a single API creation with the facade intact is logged.

One additional data point for reviewers weighing #10671's second hunk: I did not need iconIndexChanged forwarding for the stock menu clone to work (icon refresh completes fine there), so that part appears to matter for launchers that drive the icon pipeline themselves (as the PR states for Omalaunch), not for the empty-list defect itself.

Happy to close my duplicate PR (#10785) in favor of whichever implementation wins the consolidation — the delegate-level fix in #10671 covers all panel consumers at once, which is arguably the better location; my pluginShellFor-level fix is a slightly wider net (also covers non-panel delivery paths, e.g. configureBar/service loads that pass QVariant-ified manifests, though I never observed one in practice). Either location fixes the reported defect; I've verified mine end-to-end and am glad to re-run the verification against #10671's tree if useful.