Skip to content

Port the two open mirror PRs (Omarchy 4.0.3 pluginDir, startup config read) and redraw the launcher icon - #2

Merged
ZackYang merged 2 commits into
mainfrom
claude/review-merge-prs-9dc477
Sep 17, 2026
Merged

ZackYang merged 2 commits into
mainfrom
claude/review-merge-prs-9dc477

Conversation

@ZackYang

Copy link
Copy Markdown
Contributor

What this ports

The two open pull requests on the generated mirror, displaywright-shell-plugin#3 and #2, brought into plugin/ where they have to live. Both were reviewed against the shell that is installed here (Omarchy 4.0.4-1) rather than taken on the strength of their descriptions.

#3 — pluginDir resolves to "" on Omarchy ≥ 4.0.3 (Macho0x)

publicPluginManifest() at shell.qml:320 deletes the private __sourceDir before a third-party plugin sees its manifest. Every path built from it went empty: the service never read wallpapers.json, the overlay never read monitors.lua, and the launcher entry was never installed. Reproduced on this machine before changing anything: two displays pinned in the config, omarchy-shell displaywright status reporting theme for both.

The fix derives the directory from Qt.resolvedUrl(".") in the three root-level entry files, percent-decoded, and hands it from the service to LauncherEntry. Verified offline with a qmltestrunner probe that the resolved directory is correct through both Qt.createComponent (how the service is made) and a Loader (how the overlay is), including a path containing a space.

#2 — config not read at startup, and a broken reload IPC (FizykPSX)

onPluginDirChanged ran before configReader's command binding had re-evaluated, so the reader ran the ["true"] placeholder and read nothing. With #3 in, pluginDir is a constant — but a probe shows the change handler still fires during construction, before the child's binding has been evaluated, so setting the command at the point the read starts is still needed. The comment now describes that ordering instead of the one that stopped being true. The reload IPC also called configFile.reload() on a FileView that no longer exists; it calls reloadConfig() now.

Version

0.7.4 in manifest.json and displaywright/__init__.py, as the last bump did.

Launcher icon

Second commit redraws plugin/icon.png via make icon: a dusk wallpaper with two display frames in front of it, one landscape and one portrait. Checked downscaled to 24px, which is roughly what the app menu shows.

Checks run here

  • make lint — qmlcachegen + qmllint against the installed shell: ok
  • make validate-plugin — omarchy-plugin-validate: ok
  • make test — 335 Python tests OK (4 skipped), 52 QML tests passed

After merging

  1. make publish-plugin to regenerate the mirror.
  2. Close mirror Port the two open mirror PRs (Omarchy 4.0.3 pluginDir, startup config read) and redraw the launcher icon #2 and #3 with a note pointing here — the force-push means GitHub will not mark them merged on its own.

🤖 Generated with Claude Code

ZackYang and others added 2 commits September 17, 2026 12:52
Ported into plugin/ from displaywright-shell-plugin#3 and #2, since the
repository they were opened against is generated from this directory and
would lose them at the next publish.

Omarchy 4.0.3 stopped handing third-party plugins the host's private
__sourceDir (publicPluginManifest deletes it at shell.qml:320, still there
in 4.0.4). Every path this plugin built from it went empty: the service never
read wallpapers.json, the overlay never read monitors.lua, and the launcher
entry was never installed. Reproduced here on 4.0.4-1 before touching
anything -- two displays pinned in the config, `status` reporting theme for
both. The three entry files sit at the plugin root, so the directory now
comes from Qt.resolvedUrl(".") in each, percent-decoded; LauncherEntry takes
it from the service instead of the manifest. Checked offline that the
resolved directory matches through both Qt.createComponent and a Loader, and
with a space in the path.

The startup read is the other half. pluginDir used to arrive after
construction and onPluginDirChanged ran before configReader's command binding
had re-evaluated, so the reader ran its ["true"] placeholder and read nothing
-- pins came back only when the file was next written. pluginDir is a
constant now, but the handler still fires during construction, and a probe
shows the child's binding has not been evaluated at that moment either.
Setting the command at the point the read starts covers both orderings; the
comment says why, rather than the reason that stopped being true.

The reload IPC also called configFile.reload() on a FileView that no longer
exists, so `omarchy-shell displaywright reload` returned an error instead of
ok. It calls reloadConfig() now.

Version 0.7.4, in the package as well as the manifest, as the last bump did.

Co-Authored-By: MACHO MAN <machoxv@protonmail.com>
Co-Authored-By: Pawel Waszkiewicz <fizyk@me.com>
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The old one was three white rectangles on a flat blue plate, and in the app
menu at 18px it read as a generic settings tile. The new one is a dusk
wallpaper -- night sky down to a warm horizon, a sun, hills -- with two
display frames standing in front of it, one landscape and one portrait, each
framing its own piece of the picture. That is what the plugin does.

Still drawn in QML through `make icon`, now on a Canvas so the gradient, the
glow and the hill curve are one paint routine rather than a stack of
Rectangles. Checked downscaled to 24px: the two frames and the sun survive,
which is all a menu row has room to show.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
@ZackYang
ZackYang merged commit 255e429 into main Sep 17, 2026
5 of 6 checks passed
ZackYang added a commit that referenced this pull request Sep 18, 2026
displaywright#1 reached the same diagnosis as the mirror's #2 independently,
on 4.0.2 with four outputs, and carried the same reload IPC fix. The code
that landed came by the other route, but the finding was theirs as well.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant