Proof Portal

Project overview

Omarchy

ProbeLabs65 findings · 95 requirements

A proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.

Inbox
ReportR-1251GitHub issuePublicDecided· Out of scope

omarchy.media bar widget renders blank: marquee leaves the label parked off-screen when the title fits

Reported by TomFoolerrie · filed Aug 29, 2026 · open at source

Decided: Out of scope — decided by agents · verified 5 days ago.

At a glance

1 · What is claimed?
Only the report text below — no validator has restated it as checkable claims yet.
2 · What does it affect?
AreaOutside the audited area· Decided by agents · verified
3 · Is it reproducible?
No validation has been run yet.
4 · What remains unclear?
  • Not validated yet: no claims, no reproducer.
5 · What happens next?
Decided by agents and verified by a second, independent agent — see the decision.

Original report

omarchy.media bar widget renders blank: marquee leaves the label parked off-screen when the title fitsrevision 1 · captured 2026-09-28 21:24 UTC via poll

What happens

The omarchy.media bar widget renders as a blank gap: the play/pause glyph draws, but the track label is invisible — even though the MPRIS service has valid metadata.

$ omarchy-shell media status
{"hasPlayer":true,"hasMedia":true,"playing":true,"identity":"Spotify",
 "title":"Klepto - Demo","artist":"Ultra Q","album":"My Guardian Angel (Deluxe)", ...}

The widget occupies its full width in the bar, so it reads as a broken/empty slot between the neighbouring icons.

Expected

The now-playing label renders next to the glyph.

Root cause

shell/plugins/services/media/BarWidget.qml puts the label in a 180px clip: true Item and drives it with a marquee:

Item {
  id: scrollClip
  width: Math.min(root.maxLabelWidth, labelText.implicitWidth)   // maxLabelWidth: 180
  clip: true

  Text {
    id: labelText
    text: root.title + (root.artist ? "  ·  " + root.artist : "")

    property bool needsScroll: implicitWidth > scrollClip.width

    NumberAnimation on x {
      running: labelText.needsScroll && !root.popupOpen && !root.bar.vertical
      loops: Animation.Infinite
      duration: Math.max(6000, labelText.implicitWidth * 25)
      from: scrollClip.width          // <-- fully off the RIGHT edge of the clip
      to: -labelText.implicitWidth
      easing.type: Easing.Linear
    }
  }
}

from: scrollClip.width starts the label fully outside the clip window. When the title is short enough to fit, needsScroll is false, so the animation never runs — but x is left at that off-screen start offset and nothing ever resets it to 0.

Net effect: titles that fit are the ones that disappear. Longer titles scroll and are visible; short ones are pushed out of the clip and render as empty space.

Reproduce

  1. omarchy bar put omarchy.media --section right
  2. Play anything with an MPRIS-exposing player (Spotify here) whose "title · artist" string is narrower than 180px.
  3. The widget shows only the glyph; the label area is blank.
  4. omarchy-shell media status confirms title/artist are present.

Evidence

Screenshotting the bar region directly (grim -g "2080,0 420x28") over successive frames:

  • Six frames, 1s apart: glyph present every frame, label area empty every frame.
  • After forcing a reload, the label appears frozen at the right edge of the clip window, showing ~3 characters (Meg of "Megatron"), identical across 8 frames a second apart — i.e. parked, not animating.

Before/after capture attached.

Suggested fix

Reset x when the label isn't scrolling, e.g. onNeedsScrollChanged: if (!needsScroll) x = 0.

Locally I replaced the marquee with a pinned, elided label, which also removes the periods where a scrolling title is off-screen entirely:

x: 0
width: scrollClip.width
elide: Text.ElideRight

The full string remains available in the hover tooltip and the right-click popup card, so nothing is lost.

System

  • Omarchy 4.0.1-1
  • Hyprland 0.56.2, kernel 7.1.9-arch1-2, Arch x86_64
  • GMKtec NucBox_K12, AMD Ryzen 7 H 255 w/ Radeon 780M
  • Two monitors, 2560x1080 + 2560x1440, both scale 1, bar position top
  • Player: Spotify 1:1.2.96.518-2 (XWayland)

Note

While confirming the fix I also hit #8555 — omarchy-shell shell rescanPlugins was not enough to pick up the change; a full omarchy restart shell was required.

View raw text
## What happens

The `omarchy.media` bar widget renders as a blank gap: the play/pause glyph draws, but the track label is invisible — even though the MPRIS service has valid metadata.

```
$ omarchy-shell media status
{"hasPlayer":true,"hasMedia":true,"playing":true,"identity":"Spotify",
 "title":"Klepto - Demo","artist":"Ultra Q","album":"My Guardian Angel (Deluxe)", ...}
```

The widget occupies its full width in the bar, so it reads as a broken/empty slot between the neighbouring icons.

## Expected

The now-playing label renders next to the glyph.

## Root cause

`shell/plugins/services/media/BarWidget.qml` puts the label in a 180px `clip: true` Item and drives it with a marquee:

```qml
Item {
  id: scrollClip
  width: Math.min(root.maxLabelWidth, labelText.implicitWidth)   // maxLabelWidth: 180
  clip: true

  Text {
    id: labelText
    text: root.title + (root.artist ? "  ·  " + root.artist : "")

    property bool needsScroll: implicitWidth > scrollClip.width

    NumberAnimation on x {
      running: labelText.needsScroll && !root.popupOpen && !root.bar.vertical
      loops: Animation.Infinite
      duration: Math.max(6000, labelText.implicitWidth * 25)
      from: scrollClip.width          // <-- fully off the RIGHT edge of the clip
      to: -labelText.implicitWidth
      easing.type: Easing.Linear
    }
  }
}
```

`from: scrollClip.width` starts the label fully outside the clip window. When the title is **short enough to fit**, `needsScroll` is false, so the animation never runs — but `x` is left at that off-screen start offset and nothing ever resets it to `0`.

Net effect: **titles that fit are the ones that disappear.** Longer titles scroll and are visible; short ones are pushed out of the clip and render as empty space.

## Reproduce

1. `omarchy bar put omarchy.media --section right`
2. Play anything with an MPRIS-exposing player (Spotify here) whose `"title · artist"` string is narrower than 180px.
3. The widget shows only the glyph; the label area is blank.
4. `omarchy-shell media status` confirms title/artist are present.

## Evidence

Screenshotting the bar region directly (`grim -g "2080,0 420x28"`) over successive frames:

- Six frames, 1s apart: glyph present every frame, label area empty every frame.
- After forcing a reload, the label appears **frozen** at the right edge of the clip window, showing ~3 characters (`Meg` of "Megatron"), identical across 8 frames a second apart — i.e. parked, not animating.

Before/after capture attached.

## Suggested fix

Reset `x` when the label isn't scrolling, e.g. `onNeedsScrollChanged: if (!needsScroll) x = 0`.

Locally I replaced the marquee with a pinned, elided label, which also removes the periods where a scrolling title is off-screen entirely:

```qml
x: 0
width: scrollClip.width
elide: Text.ElideRight
```

The full string remains available in the hover tooltip and the right-click popup card, so nothing is lost.

## System

- Omarchy `4.0.1-1`
- Hyprland `0.56.2`, kernel `7.1.9-arch1-2`, Arch x86_64
- GMKtec NucBox_K12, AMD Ryzen 7 H 255 w/ Radeon 780M
- Two monitors, 2560x1080 + 2560x1440, both scale 1, bar position `top`
- Player: Spotify `1:1.2.96.518-2` (XWayland)

## Note

While confirming the fix I also hit #8555 — `omarchy-shell shell rescanPlugins` was not enough to pick up the change; a full `omarchy restart shell` was required.

Validation

Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.

Linked

Not linked to any known issue, other report or change yet.

Decision

Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.

  • Out of scopeDecided by agents · verified · 2026-10-09 09:57 UTC