Proof Portal

Sign in
Project overview

Omarchy

ProbeLabs65 findings · 95 requirements

A 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.

Inbox
ReportR-4714GitHub issuePublicReceived

Bar widget plugin QML changes don't hot-reload (requires full shell restart)

Reported by ramackersjp · filed Aug 27, 2026Closed upstream on 2026-09-20 by bjarneo via an automated message, as a duplicate of #6981 (R-1835). GitHub close reason: completed.

Open at source
Received and recorded verbatim. Nothing has been checked yet.

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

Bar widget plugin QML changes don't hot-reload (requires full shell restart)revision 1 · captured 2026-10-04 12:03 UTC via poll

Summary

Editing a bar-widget plugin's .qml under ~/.config/omarchy/plugins/<id>/ is detected (the watcher fires and the shell re-registers the plugin), but the widget keeps rendering the OLD compiled QML until a full omarchy restart shell. The saved changes never take effect without restarting the whole shell.

Expected

Saving a file under ~/.config/omarchy/plugins/ reloads plugin code automatically (per the docs), so the bar widget reflects the change immediately.

Actual

Each edit requires omarchy restart shell to become active.

Root cause

shell.qml relies on Qt.clearComponentCache before rebuilding plugins:

// shell.qml:757
if (typeof Qt.clearComponentCache === "function") Qt.clearComponentCache()

In the Arch quickshell 0.3.1 package, Qt.clearComponentCache is not exposed to QML, so the guard is false and the component cache is never cleared. The plugin is re-registered, but the cached, compiled QML is re-used → old widget stays until a full restart naturally drops the cache.

Evidence

  • qt6 quickshell 0.3.1-1 (packager: [email protected])
  • strings /usr/bin/quickshell | grep clearComponentCache -> no match
  • /usr/lib/qt6/qml/Quickshell/quickshell-core.qmltypes contains no clearComponentCache (grep = 0 hits); the exported types (Quickshell, QuickshellSettings, ...) expose no cache-clear method
  • inotifywait watcher IS running and fires: shell log shows Local plugin changed, reloading: <id> on every save
  • After the reload only a full process restart applies QML content changes

Steps to reproduce

  1. Add any bar-widget plugin under ~/.config/omarchy/plugins/ (e.g. jp.taxiprijs/BarWidget.qml).
  2. Edit a label/color in the .qml and save.
  3. Observe the bar still shows the old content until you run omarchy restart shell.

Suggested fix

Expose/clear the QML component cache so plugin content is re-read from disk on reload — e.g. surface Qt.clearComponentCache (or recreate the QML engine per generation, as Quickshell's own native watchFiles/reload path does) and call it in finishPluginReload(). Alternatively, enable Quickshell's native watchFiles-based engine recreation for plugin directories.

System

  • Omarchy: 4.0.1-1
  • Quickshell: 0.3.1-1 (Arch Linux package)
View raw text
## Summary
Editing a bar-widget plugin's `.qml` under `~/.config/omarchy/plugins/<id>/` is detected (the watcher fires and the shell re-registers the plugin), but the widget keeps rendering the OLD compiled QML until a full `omarchy restart shell`. The saved changes never take effect without restarting the whole shell.

## Expected
Saving a file under `~/.config/omarchy/plugins/` reloads plugin code automatically (per the docs), so the bar widget reflects the change immediately.

## Actual
Each edit requires `omarchy restart shell` to become active.

## Root cause
`shell.qml` relies on `Qt.clearComponentCache` before rebuilding plugins:

```js
// shell.qml:757
if (typeof Qt.clearComponentCache === "function") Qt.clearComponentCache()
```

In the Arch `quickshell 0.3.1` package, `Qt.clearComponentCache` is **not exposed to QML**, so the guard is false and the component cache is never cleared. The plugin is re-registered, but the cached, compiled QML is re-used → old widget stays until a full restart naturally drops the cache.

## Evidence
- `qt6` `quickshell 0.3.1-1` (packager: [email protected])
- `strings /usr/bin/quickshell | grep clearComponentCache` -> no match
- `/usr/lib/qt6/qml/Quickshell/quickshell-core.qmltypes` contains **no** `clearComponentCache` (grep = 0 hits); the exported types (`Quickshell`, `QuickshellSettings`, ...) expose no cache-clear method
- `inotifywait` watcher IS running and fires: shell log shows `Local plugin changed, reloading: <id>` on every save
- After the reload only a full process restart applies QML content changes

## Steps to reproduce
1. Add any bar-widget plugin under `~/.config/omarchy/plugins/` (e.g. `jp.taxiprijs/BarWidget.qml`).
2. Edit a label/color in the `.qml` and save.
3. Observe the bar still shows the old content until you run `omarchy restart shell`.

## Suggested fix
Expose/clear the QML component cache so plugin content is re-read from disk on reload — e.g. surface `Qt.clearComponentCache` (or recreate the QML engine per generation, as Quickshell's own native `watchFiles`/reload path does) and call it in `finishPluginReload()`. Alternatively, enable Quickshell's native `watchFiles`-based engine recreation for plugin directories.

## System
- Omarchy: 4.0.1-1
- Quickshell: 0.3.1-1 (Arch Linux package)

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.