Resolve pluginDir and launcher install from the plugin's own location

[Macho0x]

Omarchy 4.0.3 compatibility: pluginDir resolves to ""

Omarchy 4.0.3 stops exposing the host's private __sourceDir manifest field to third-party plugins (publicPluginManifest() deletes it in shell/shell.qml). Three files built paths from it:

• Wallpaper.qml (service entry) — read-config.sh and the config watcher never resolved
• Arrange.qml (overlay entry) — read-config.sh and the monitors reader never resolved
• LauncherEntry.qml — the launcher-entry install (and its reload-safe removal) skipped entirely, so the overlay was unreachable from the app launcher

All three files sit at the plugin root (the child gets pluginDir passed from the service now), so the directory is derived from Qt.resolvedUrl(".") percent-decoded, with a safe "" fallback for non-file URLs — the approach validated upstream in Omarchy-Spotify#75. The launcher entry's careful reload-vs-removal logic is untouched; only the directory source changes. Version 0.7.4.

Testing

• Reinstall/re-enable on Omarchy 4.0.3-1, omarchy restart shell
• ~/.local/share/applications/displaywright.desktop appears again (previously absent on a fresh install)
• Wallpaper config loads and the arrange overlay reads/monitors config files

[FizykPSX]

Confirming this on Omarchy 4.0.3-1, two displays (DP-1 and DP-2, both pinned).

The failure mode matches exactly. After the update to 4.0.3, both outputs silently fell back to the theme background — no error anywhere, and omarchy-shell displaywright status reported:

DP-1	theme	-	-
DP-2	theme	-	-

wallpapers.json was untouched on disk, and hyprctl layers still showed the displaywright surface above omarchy-background on both outputs, which is what made this look like a config problem rather than a manifest one. publicPluginManifest() deleting __sourceDir at shell/shell.qml:320 is the cause.

With this branch merged into my checkout:

• node --test tests/*.mjs — 89 pass, 0 fail
• Two omarchy restart shell runs, status reports pinned for both outputs each time
• omarchy-shell displaywright reload returns ok and repaints

One note for anyone else landing here: this applies cleanly on top of #2 (the startup config read). The two touch different parts of Wallpaper.qml and do not conflict — both are needed for pins to survive a restart on 4.0.3.

[ZackYang]

Hi @Macho0x ,

Apologies for the long silence on this. I was unwell for a while and had to step away from the project, so I did not get to look at your PR until now.

Thank you very much for the contribution. The Omarchy 4.0.3 change to publicPluginManifest() would have left every third-party install of Displaywright silently broken, so this fix is important, and deriving the directory from Qt.resolvedUrl(".") is a clean way around the missing __sourceDir. Thanks also to @FizykPSX for confirming it on 4.0.3 and checking that it applies cleanly on top of #2.

I will review this properly in the next few days and plan to ship it, together with #2, in the next release. I will follow up here once it is merged.

[ZackYang]

Landed — thank you. This repository is a generated mirror of plugin/ in BlackKingBarOrg/displaywright, so the change went in there rather than through a merge here: displaywright#2, commit 52fa875, with you as co-author, and the mirror has just been republished from it (0.7.4).

Reproduced the empty pluginDir on 4.0.4-1 before landing it, and checked offline that Qt.resolvedUrl(".") resolves the same directory through Qt.createComponent and a Loader, including a path with a space. Landed together with #2, since the change handler still fires during construction and the explicit command set covers that ordering too.

You're also named in the README's Thanks section.