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-4711GitHub issuePublicReceived

Power panel never opens on battery-less desktops (self-closes immediately, QML binding loop)

Reported by sgersz · filed Aug 27, 2026Closed upstream on 2026-09-21 by bjarneo via an automated message, as a duplicate of #7119 (R-1772). GitHub close reason: completed.

Received and recorded verbatim. Nothing has been checked yet.

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?
Not yet mapped to any requirement or component.
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?
Our staff decide whether the report is valid. Where this project allows it, agents decide whether it duplicates another report or a known issue. No decision has been recorded yet.

Original report

Power panel never opens on battery-less desktops (self-closes immediately, QML binding loop)revision 1 · captured 2026-10-04 12:03 UTC via poll

Title: Power panel never opens on battery-less desktops (self-closes immediately, QML binding loop)

What happened

On a desktop system with no battery (Bosgame M5, AXB35-02 board — no UPower battery device present), the Power panel (omarchy.power, bound to SUPER+CTRL+P by default) never actually displays. Triggering it via keybind, the bar widget, or omarchy-shell shell toggle omarchy.power all silently no-op — the panel opens and instantly closes itself in the same frame.

The shell log shows:

WARN scene: QML Panel at file:///usr/share/omarchy/shell/plugins/panels/power/Panel.qml[9:1]: Binding loop detected for property "opened":
WARN scene: QML IpcHandler at .../Panel.qml[177:3]: Handler was registered but will not be used because another handler is registered for target omarchy.power

What was expected

The Power panel (suspend/lock/shutdown/power-profile controls) should open normally on any machine, since none of those actions require a battery to be present. Only the battery-specific sub-section should reasonably depend on batteryPresent.

Root cause

In shell/plugins/panels/power/Panel.qml:

onOpenedChanged: {
  if (opened) {
    if (!batteryPresent) {
      close()
      return
    }
    ...
  }
}

onBatteryPresentChanged: if (!batteryPresent) close()

visible: batteryPresent
implicitWidth: batteryPresent ? button.implicitWidth : 0

The whole panel's visible and implicitWidth are gated on batteryPresent at the component root, and onOpenedChanged force-closes the panel immediately if there's no battery. On a battery-less desktop batteryPresent is always false, so the panel opens and self-closes in the same tick every time — which is what triggers the QML binding-loop warning above. There's already a correctly-scoped battery gate further down (open: root.opened && root.batteryPresent on the battery-info sub-section), so the fix is just removing the over-broad gate at the root.

Steps to reproduce

  1. On a desktop with no UPower battery device (any headless/desktop Strix Halo mini PC, or any desktop build)
  2. Press SUPER+CTRL+P (or trigger omarchy-shell shell toggle omarchy.power)
  3. Nothing appears; shell log shows the binding-loop warning above

System details

  • Omarchy: 4.0.1-1
  • Hyprland: 0.56.2
  • Kernel: 7.1.9-arch1-2
  • Machine: Bosgame M5 (Mobo: AXB35-02), AMD Ryzen AI Max+ 395 / Radeon 8060S
  • No system battery present (UPower reports no display device)

Suggested fix

Remove the if (!batteryPresent) { close(); return } block from onOpenedChanged, remove onBatteryPresentChanged: if (!batteryPresent) close(), and drop the batteryPresent condition from the root visible/implicitWidth bindings — leave the existing, correctly-scoped open: root.opened && root.batteryPresent on the battery sub-section as the only battery gate. Happy to open a PR with this fix if useful.

View raw text
Title: Power panel never opens on battery-less desktops (self-closes immediately, QML binding loop)

## What happened
On a desktop system with no battery (Bosgame M5, AXB35-02 board — no UPower battery device present), the Power panel (`omarchy.power`, bound to SUPER+CTRL+P by default) never actually displays. Triggering it via keybind, the bar widget, or `omarchy-shell shell toggle omarchy.power` all silently no-op — the panel opens and instantly closes itself in the same frame.

The shell log shows:
```
WARN scene: QML Panel at file:///usr/share/omarchy/shell/plugins/panels/power/Panel.qml[9:1]: Binding loop detected for property "opened":
WARN scene: QML IpcHandler at .../Panel.qml[177:3]: Handler was registered but will not be used because another handler is registered for target omarchy.power
```

## What was expected
The Power panel (suspend/lock/shutdown/power-profile controls) should open normally on any machine, since none of those actions require a battery to be present. Only the battery-specific sub-section should reasonably depend on `batteryPresent`.

## Root cause
In `shell/plugins/panels/power/Panel.qml`:

```qml
onOpenedChanged: {
  if (opened) {
    if (!batteryPresent) {
      close()
      return
    }
    ...
  }
}

onBatteryPresentChanged: if (!batteryPresent) close()

visible: batteryPresent
implicitWidth: batteryPresent ? button.implicitWidth : 0
```

The whole panel's `visible` and `implicitWidth` are gated on `batteryPresent` at the component root, and `onOpenedChanged` force-closes the panel immediately if there's no battery. On a battery-less desktop `batteryPresent` is always `false`, so the panel opens and self-closes in the same tick every time — which is what triggers the QML binding-loop warning above. There's already a correctly-scoped battery gate further down (`open: root.opened && root.batteryPresent` on the battery-info sub-section), so the fix is just removing the over-broad gate at the root.

## Steps to reproduce
1. On a desktop with no UPower battery device (any headless/desktop Strix Halo mini PC, or any desktop build)
2. Press SUPER+CTRL+P (or trigger `omarchy-shell shell toggle omarchy.power`)
3. Nothing appears; shell log shows the binding-loop warning above

## System details
- Omarchy: 4.0.1-1
- Hyprland: 0.56.2
- Kernel: 7.1.9-arch1-2
- Machine: Bosgame M5 (Mobo: AXB35-02), AMD Ryzen AI Max+ 395 / Radeon 8060S
- No system battery present (UPower reports no display device)

## Suggested fix
Remove the `if (!batteryPresent) { close(); return }` block from `onOpenedChanged`, remove `onBatteryPresentChanged: if (!batteryPresent) close()`, and drop the `batteryPresent` condition from the root `visible`/`implicitWidth` bindings — leave the existing, correctly-scoped `open: root.opened && root.batteryPresent` on the battery sub-section as the only battery gate. Happy to open a PR with this fix if useful.

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.

No decision has been recorded yet.