Custom "bar" plugin fails to load — cloning the built-in bar (omarchy plugin clone omarchy.bar) breaks the shell

[toppzi]

What happened

Cloning the built-in bar plugin via the documented workflow (omarchy plugin clone omarchy.bar) and switching shell.json's bar.id to the clone breaks the shell entirely — the bar disappears from every monitor until bar.id is reverted back to omarchy.bar and the shell is restarted.

The journal shows:

WARN scene: file:///home/user/.config/omarchy/plugins/<clone-id>/Bar.qml[15:3]: Required property omarchyPath was not initialized
WARN scene: file:///home/user/.config/omarchy/plugins/<clone-id>/Bar.qml[17:3]: Required property barWidgetRegistry was not initialized
WARN scene: file:///home/user/.config/omarchy/plugins/<clone-id>/Bar.qml[22:3]: Required property barConfig was not initialized
WARN scene: @shell.qml[256:-1]: ReferenceError: errorString is not defined

No config edits were made to Bar.qml before this happened — it reproduces on a byte-for-byte clone.

What was expected

A plain clone of the built-in bar plugin, activated the documented way, should render identically to the built-in bar.

Steps to reproduce

1. omarchy plugin clone omarchy.bar (this clones the plugin and switches ~/.config/omarchy/shell.json's bar.id to the new clone automatically).
2. omarchy restart shell (or wait for the hot-reload triggered by the clone).
3. The bar vanishes on every monitor. journalctl --user shows the required-property warnings and the ReferenceError above.

Root cause (found while reading shell.qml)

shell/plugins/bar/Bar.qml declares three required properties:

required property string omarchyPath
required property var barWidgetRegistry
required property var barConfig

The built-in bar is instantiated through defaultBarComponent in shell.qml, which binds these inline at creation time:

Component {
  id: defaultBarComponent
  Bar {
    omarchyPath: shell.omarchyPath
    barWidgetRegistry: shell.barWidgetRegistry
    barConfig: shell.barConfig
    ...
  }
}

But a custom/cloned bar goes through pluginBarLoader instead — a Loader { source: shell.activeBarSourceUrl } — which creates the object with no initial properties and only assigns them afterward via onLoaded: shell.configureBar(item, ...). Because the three properties are required, object creation fails synchronously before configureBar() ever runs, and pluginBarLoader.status becomes Loader.Error.

That failure then hits a second bug in the same file — the onStatusChanged error handler references a bare errorString identifier instead of the loader's own errorString():

onStatusChanged: {
  if (status === Loader.Error) {
    var detail = errorString && errorString() ? errorString() : ""  // ReferenceError here
    ...

so even the "fall back to the default bar" diagnostic path throws.

Net effect: the custom-bar plugin mechanism ("kinds": ["bar"] + shell.json's bar.id) appears to be non-functional for any plugin that doesn't happen to dodge these two bugs — including a stock, unmodified clone of the built-in bar made via the officially documented omarchy plugin clone command.

Suggested fix

• Supply the required properties at creation time for the custom-bar Loader too (e.g. Loader.setSource(url, {omarchyPath, barWidgetRegistry, barConfig}), or drop required from those three properties in Bar.qml and rely on configureBar() to populate them immediately after, as the default-bar path effectively already does for shell/manifest).
• Fix the errorString reference in pluginBarLoader.onStatusChanged to call the loader's own errorString().

System details

• Omarchy: 4.0.2-1
• Kernel: Linux 7.1.9-arch1-2 x86_64
• Hyprland: 0.56.2
• Quickshell: 0.3.1-1
• GPU: AMD Radeon RX 5600 XT (Navi 10)