### System details

Ryzen 5600x with 3060 and 32 gb or ram

### What's wrong?

I encountered an intermittent issue in the Omarchy top bar where some interactive plugins became difficult or impossible to click at their visible position.

The icons themselves remained visually positioned correctly, but their clickable/input region could become vertically offset. In some cases, clicking slightly above the visible icon would trigger the action, while clicking directly on the icon would not.

The issue was temporarily resolved by restarting the Omarchy shell with:

```bash
omarchy-restart-shell

However, the problem could return later.

Affected components included:

System Tray
Dropbox
Tailscale
Agent
Speaker

Other top-bar plugins were generally unaffected.

Symptoms

The main symptom was a mismatch between the visual position of a top-bar item and its actual input/click region.

For example:

Visible icon:
        [ ICON ]

Actual clickable region:
      [ CLICK AREA ]

The visual layout itself appeared correct. The problem was specifically related to pointer/input hit testing.

Restarting the shell recreated the relevant layer surfaces and temporarily restored correct alignment.

Root Cause

The issue was traced to:

/usr/share/omarchy/shell/Ui/ScreenMoveRemap.qml

The ScreenMoveRemap.qml component was listening for monitor position changes:

function onXChanged() { settleTimer.restart() }
function onYChanged() { settleTimer.restart() }

However, monitor logical geometry can change without the monitor's x or y position changing.

Relevant geometry changes can include:

width
height
scale
transform

When such a geometry change occurred, the QML visual layout could update while the associated Wayland layer/input geometry could temporarily remain based on stale geometry.

This could result in:

Visual geometry
      ↓
updated

Input/layer geometry
      ↓
stale

      ↓

Visual position != Input position

This explains why:

the icon looked correctly positioned,
clicking the visible icon could fail,
clicking at an offset position could work,
restarting the shell temporarily fixed the issue.

The problem appears to be in the shared screen remapping/geometry synchronization logic rather than in the individual affected plugins.

Fix

The fix was kept deliberately minimal.

The existing Omarchy file was patched to also react to monitor geometry changes:

Connections {
    target: root.screen

    function onXChanged() { settleTimer.restart() }
    function onYChanged() { settleTimer.restart() }

    function onWidthChanged() { settleTimer.restart() }
    function onHeightChanged() { settleTimer.restart() }
    function onScaleChanged() { settleTimer.restart() }
    function onTransformChanged() { settleTimer.restart() }
}

The important change is that geometry changes now trigger the same remapping/settling mechanism as position changes.

No:

hardcoded pixel offsets
enlarged hitboxes
plugin-specific workarounds
separate bar implementation

were required.

Update-Safe Implementation

Because the affected file is package-managed by Omarchy, simply editing it would normally risk losing the modification during a package update.

Instead, a small Pacman post-transaction hook was implemented:

/etc/pacman.d/hooks/99-omarchy-screenmoveremap-fix.hook

The hook invokes:

/usr/local/bin/omarchy-patch-screenmoveremap

after an Omarchy package upgrade.

The patching script:

Verifies the expected structure of ScreenMoveRemap.qml.
Applies the four geometry handlers when they are missing.
Does nothing when the fix is already present.
Fails safely if the upstream file structure changes unexpectedly.
Preserves the original file permissions.
Keeps an original backup for rollback.

This makes the patch idempotent and prevents blindly modifying an unexpected future version of the file.

Cleanup of Previous Workaround

An earlier user-space QML override was also tested during investigation.

That approach required copying the qs.Ui module because QML module resolution does not provide the required partial-module fallback behavior.

That workaround has now been completely removed.

The current system does not use:

~/.config/omarchy/qml/qs/

and the previous QML2_IMPORT_PATH customization was removed from:

~/.config/hypr/monitors.lua

The system now uses the normal Omarchy QML module from:

/usr/share/omarchy/shell/Ui/

with only the minimal ScreenMoveRemap.qml modification.

Verification

The implementation was tested for:

QML syntax/loading
Omarchy shell startup
Shell restart
40+ plugins loading
Shell IPC responsiveness
affected plugin loading
removal of the previous QML override
removal of the QML import-path override
idempotent patching
applying the patch to a fresh/unmodified file
malformed/unexpected file handling
simulated package-update scenario

The patch successfully:

Original file
     ↓
Apply fix
     ↓
Fixed file

Run patch again
     ↓
Already patched → no duplicate changes

A fresh-file update simulation also successfully re-applied the fix.

Expected Behavior After the Fix

Monitor geometry changes should now trigger the same settling/remapping mechanism regardless of whether the change affects:

position
width
height
scale
transform

Therefore, the visual geometry and input region should remain synchronized after monitor geometry changes.

Possible Upstream Fix

This issue would ideally be fixed upstream in Omarchy's:

shell/Ui/ScreenMoveRemap.qml

If the upstream implementation is changed to properly handle these geometry changes, the local workaround can be removed and the official implementation used directly.

Conclusion

The key issue was not an incorrect visual layout or an individual plugin hitbox.

It was a synchronization gap between monitor geometry changes and the corresponding screen/layer input remapping.

Adding handlers for:

onWidthChanged
onHeightChanged
onScaleChanged
onTransformChanged

allows ScreenMoveRemap.qml to react to the full set of relevant monitor geometry changes while keeping the fix small and generic.

I am sharing this report in case the issue is reproducible for other Omarchy users and/or the fix is useful for an upstream implementation.