[thomasbierly]

The window manager reads its config straight from the global map:

settingsInit.byWidget["@seelen/window-manager"]

so any override stored in monitorsV3[id].byWidget for that widget is silently ignored. Setting workspaceMargin per monitor has no effect; only the global value applies, which forces the same reservation onto every monitor.

Settings.getCurrentWidgetConfig() already merges defaults, global, instance and monitor layers, and flyouts and task-switcher both use it. The same file already honours per-monitor enabled for the toolbar and weg when computing the tiling rect, so per-monitor awareness looks intended here rather than deliberately omitted.

Switch to that accessor for both the initial read and the onChange handler.

Motivating case: a third-party widget docked to one monitor's edge as an AppBar. The tiler doesn't use the Windows work area, so a per-monitor workspaceMargin is the way to keep tiled windows clear of it -- but it has to be applied globally today, costing that width on every screen.

[greptile-apps]

Confidence Score: 5/5

The PR appears safe to merge; the accessor resolves the stable monitor-scoped widget context and correctly incorporates per-monitor overrides.

Summary

This PR updates the window manager to resolve settings through the existing widget-aware configuration accessor.

• Applies per-monitor widget overrides during initial state creation.
• Reapplies the same global, instance, and monitor merge when settings change.
• Keeps each monitor-scoped window-manager webview tied to its stable monitor identity.

_{Reviews (1) · Last reviewed commit: "fix(window-manager): honour per-monitor ..."}