Repository navigation
Feature offs and Omanotch's display panel under Omarchy's lock: no plugin writes or rescans - #618
Merged
Merged
Conversation
install-plugin.sh removed and copied every widget folder at every apply, even when nothing in it changed, and queued it for a rescan and an enable. Each of those makes Omarchy's shell reload all its plugins. Now an unchanged widget in its place is left alone and queued only when it is new, changed or no longer in shell.json (placement.sh still puts back one the user took off the bar). The copy is validated before it replaces the folder, so a widget the shell would refuse never takes the place of one that works.
The shell of omarchy-mac 4.0.3 reloads every plugin, its own lock screen too,
whenever something under ~/.config/omarchy/plugins is written or it is asked
to rescan. Under the lock the new lock screen came back without its password
field ("lock-stranded: recovering", then "lock-pending: screen-stabilizing")
until omarchy-restart-shell or a VM restart. omacvm apply and update rewrote
the bar widgets and rescanned on every run (3.2.11 and 3.2.12).
Now nothing of OmacVM's writes there or rescans while the session is locked
or the shell does not answer (guest/session-lock.sh, the one check).
install-plugin.sh stages a changed widget in
~/.local/state/omacvm/plugins-staged/<id>, omacvm-plugins leaves it all
queued, and restart-shell.sh's job after the unlock puts the copies in place,
enables the queued widgets and then restarts the shell once. Nothing changed:
nothing waits and nothing restarts. The login unit does the same for a VM
shut down before the unlock; a restart note from before the login goes.
Upstream Omarchy fixed the reload itself (omacom/omarchy#9485); omarchy-mac
does not have it yet.
The second apply's job after the unlock collided with the first one's (systemd-run --unit=omacvm-restart-shell, the error dropped by || true), so the first, older job did the work. Now install.sh first stops such a job (restart-shell.sh --retire): at once while the session answers locked, when it only waits; never while it restarts the shell, which reads as no answer (stopped then, there would be no shell and no lock screen): it gets up to 90 s to finish. What it owed is in files, and the end of the apply starts one job again.
…user's widgets shell-colors.py patches Omarchy's files and the user's clones of its plugins (#376). The clones are under ~/.config/omarchy/plugins, and a write there under the lock strands Omarchy's lock screen. While the session is locked, install.sh now patches only Omarchy's own files (the shell does not watch them); when the clones need it too, the job after the unlock does them before its one shell restart.
The display agent rebuilds omacvm.monitor in place and asks the shell to rescan when an Omarchy update changed its display panel. Update VM restarts the agent, so on a locked VM that also stranded the lock screen. It now asks guest/session-lock.sh first and skips the rebuild while the session is locked (a starting shell gets 20 s to answer); the apply stages its own copy then. A test now fails for any new rescanPlugins caller that does not ask for the lock first.
…lock The bar lines said "queued, not enabled yet (log out and in)" for every queued widget. While a job waits for the unlock (omacvm-restart-shell), the widget comes right after the unlock, and the line says so.
AGENTS.md section 8 has the rule and why (omarchy-mac 4.0.3's plugin reload, upstream omacom/omarchy#9485, why not a shell restart instead), the install-plugin row and a failure-mode row; troubleshooting 46 says what 3.2.12 and older did and what to do.
gillesgoetsch
added a commit
that referenced
this pull request
Oct 29, 2026
CI's guest job compiles the guest agents before this test, and their __pycache__ files matched as callers.
display-panel.py builds omanotch.monitor in ~/.config/omarchy/plugins and asks the shell to rescan: at Omanotch's install, and at each notchcast start after an Omarchy update (UTM, Fusion, Parallels). Update VM restarts notchcast, so on a locked VM that could strand Omarchy's lock screen like the bar widgets did. Before anything it would write or ask the shell, it now reads Omarchy's lock status as copies.py does; locked, it does nothing and says so, and the next notchcast start does it. --remove waits the same way.
…in the plugins folder omacvm disable control-centre removed omacvm.control from ~/.config/omarchy/plugins, and omacvm disable omanotch ran Omanotch's uninstall (its clones there removed, a rescan) and display-panel.py --drop: under the lock each strands Omarchy's lock screen. The control centre now goes out of the bar at once (omarchy plugin disable changes shell.json only), and its folder stays while the session is locked; out of the bar it does nothing, and the next apply removes it (install.sh runs the control centre's off while the folder is there). A copy staged under the lock and a queued enable never come. Omanotch's root side goes at once as before (notchcast, units, hooks: nothing runs or talks to the Mac). Its own uninstall waits for the unlock: restart-shell.sh runs it in the session right after the unlock, when Omanotch is off in /etc/omacvm/env and its panel tool is still there; the next apply does it too.
gillesgoetsch
force-pushed
the
locked-update-off
branch
from
October 29, 2026 15:41
f8f4b19 to
036996c
Compare
…build tidy() could move the old clone back into ~/.config/omarchy/plugins, which the shell of omarchy-mac 4.0.3 sees and reloads its lock screen for. With a cut-off build's leftovers it now reads Omarchy's lock status first and leaves them for the next start while the session is locked.
…w install with the update
This was referenced Oct 29, 2026
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
On top of #617 (base
locked-update; merge #617 first, or both together). Same cause as #617: the shell of omarchy-mac 4.0.3 reloads every plugin, its lock screen too, on a write under~/.config/omarchy/pluginsor arescanPluginscall, and under the lock the new lock screen has no password field. #617 coversomacvm update/apply; this covers the rarer writers the architecture review split off: Omanotch's display panel and the feature offs.Change
src/omanotch/guest/monitor/display-panel.py: before anything it would write or ask the shell (a build after an Omarchy update, a panel that no longer fits, the first enable,--remove), it reads Omarchy's lock status ascopies.pydoes (requested, sessionLocked or secure; isLocked only without the status call; the last line, after Qt's locale warning). Locked: nothing, it says "the session is locked: at the next start".--refreshwith nothing changed still asks nothing. A cut-off build's leftovers (.omanotch.monitor.new/.old) are tidied only after that check too: tidying can move the old clone back into the plugins folder. Runs at Omanotch's install and at each notchcast start (UTM, Fusion, Parallels), which Update VM restarts. Omanotch keeps its own rule (its subtree ships on its own), no dependency on OmacVM's files.src/control/guest/install.sh(bar_item_off):omarchy plugin disable(shell.json only) at once; the folder stays while the session is locked (out of the bar it does nothing) and goes at the next apply:src/guest/install.shruns the control centre's off while the folder or a staged copy is there. A copy staged under the lock and a queued enable are dropped at once.src/guest/off.sh(omanotch_off): the root side goes at once as before (notchcast, its units, hooks: nothing runs or talks to the Mac). Under the lock Omanotch's own uninstall (its clones removed, rescans) anddisplay-panel.py --dropwait; its panel tool~/.local/bin/omanotch-display-panelstays as the mark.src/guest/restart-shell.shruns the uninstall in the session (withWAYLAND_DISPLAYandHYPRLAND_INSTANCE_SIGNATURE, asin_sessionsets them) right after the unlock, before the one restart, when/etc/omacvm/envsays Omanotch is off and the tool is still there (from state, no queued word; a notchcast removed for a rebuild while Omanotch is on is not taken for it). The next apply also runs it while the tool is there.omarchy plugin disableonly).src/guest/install.sh: sha256 ofomanotch/guest), so the update to 3.2.13 installs Omanotch's VM side again for everyone who has it on: notchcast built again and restarted,hyprctl reload; under the lock too (rows O2, O3 below).Tests (offline)
src/omanotch/guest/tests/test_display_panel.py: locked first install, refresh after an Omarchy update (nothing written or asked, rebuilt at the next unlocked start), unchanged refresh asks nothing, a panel that no longer fits,--remove, a cut-off build under the lock (the old clone stays hidden, one status call, tidied at the next unlocked start), the lock status read with Qt's warning first and without the status call. On v3.2.12's display-panel.py: 6 failures, 1 error (work/locked-update/display-panel-v3212.txt); on 036996c's: the two cut-off cases fail (work/locked-update/display-panel-tidy-036996c8.txt).src/tests/features-off.sh: Omanotch off under the lock (no uninstall in the session, no display-panel.py, the clone untouched, notchcast stopped and gone, the tool kept, the log line), then the next apply unlocked runs the uninstall. On v3.2.12's off.sh: 4 FAIL.src/tests/plugin-lock.sh: the control centre's off locked (disabled, folder untouched, staged copy and queue line gone), open, without a shell (shell.json by hand); install.sh's condition. The rescanPlugins guard now covers Omanotch's callers.src/tests/restart-shell.sh: Omanotch off under the lock waits for the unlock, then its uninstall in the session (Hyprland's variables) and the tool gone; Omanotch on (notchcast being rebuilt): nothing owed.VM rows (Mac mini M4, macOS 27, hidden 3 GB clone of a test VM, test identity,
--no-mac)Each row: Update VM by the 3.2.12 release app, then
omacvm apply --vm-type app --no-macfrom the tree named (git archive of the commit). Lock byomarchy-system-lock, unlock by the typed password (wtype). Read per row: Omarchy's lock status, the journal's "destroyed without unlocking" / "lock-stranded" / "Local plugin changed" lines since the apply, a guest sampler that logs every change of the shell's pid (0.3 s; from run 3 with its parent and command), Omarchy's shell journal, Omanotch's state (notchcast unit, patched bar clone$USER.bar, background clone, panel tool, the running shell'snotchbarIPC target, the NOTCH output). Omanotch on works on the mini's hidden VM: no Mac Omanotch serves it (the test app maps the guest's 47811 to 47911, where nothing listens on the mini:rows-o/ports-after.txt), and notchcast runs without a Mac to stream to.--feature control-centre=off/=on)--feature omanotch=offomarchy-restart-shell, unlocked, same samplerRun 2's O1 (no parent/command in the sampler yet) logged two pids in the same second after the unlock and the kit counted it FAIL; runs 3 and 4 log each pid's command and keep the shell's journal: one new shell; the only other pid in the journal after the unlock is Quickshell's PAM subprocess for the typed password (run 4,
o1-shell-journal.txt). The display panel clone does not exist on OmacVM.app VMs (the app's own panel leaves NOTCH out), so display-panel.py's locked path is offline only (no UTM, Fusion or Parallels VM row). Cores 0, qemu.log 0 errors, memory pressure never critical, 0 tccd "Notifying for access" lines; the clone deleted after each run. Kitwork/locked-update/kit/rows-o.sh(+run-o.sh,guest-lock/onotch.sh), rawwork/locked-update/rows-o/(summary.tsv, one file per row).