Automatic bar transparency on empty workspaces

[royalhanzo]

Motivation

The Quattro bar currently supports two persistent transparency states: true and false. A useful third behavior is to keep the wallpaper-facing empty workspace clean, while restoring the opaque bar as soon as a window is present.

I have been testing this locally with a small Hyprland event watcher:

• empty focused workspace -> transparent bar
• one or more windows -> opaque bar
• workspace, open/close, and move-window events re-evaluate the state

It feels natural in daily use, but the external watcher is only a workaround. It writes shell.json through omarchy bar transparent on every state transition, needs its own autostart lifecycle, and duplicates workspace state that Quickshell already exposes.

Proposal

Extend the existing setting with a backward-compatible automatic value:

{
  "bar": {
    "transparent": "auto"
  }
}

And expose it through the existing command and menu:

omarchy bar transparent auto

Suggested behavior:

• false: always opaque, unchanged
• true: always transparent, unchanged
• "auto": transparent when the focused workspace has no toplevels; opaque otherwise
• react to workspace changes and windows being opened, closed, or moved
• double-clicking the bar while in automatic mode exits automatic mode and writes an explicit boolean, preserving the gesture as a manual override

The existing workspaces widget already observes workspace.toplevels.values.length to determine whether a workspace is occupied, so the bar can reuse the same in-process Hyprland state without polling or a background script.

Compatibility

Existing boolean configurations keep exactly their current meaning. On an older Omarchy version, "auto" is safely treated as non-transparent by the current config.transparent === true check. No schema-version change or migration appears necessary.

For a first implementation I would keep transparency global and follow Hyprland.focusedWorkspace, matching the current global bar.transparent state. True per-output automatic transparency would require moving foreground sampling and animation state into each bar surface; that is related to the per-screen bar work discussed in #7669 and can be handled separately if maintainers prefer that semantic from the start.

Related: #9932 proposes making the double-click transparency gesture configurable. The two ideas are independent but should agree on manual-override behavior.

I am preparing a focused PR with the QML behavior, CLI support, tests, and manual/docs updates.