feat(control-center): show Bluetooth battery in quick tile

[0xdeafbeef]

Description

Shows the connected Bluetooth device battery level in the Control Center tile when available.

Type of change

• New feature

Related issues

None.

Screenshots / video

Checklist

• My code follows the conventions in CONTRIBUTING.md
• I have tested my changes locally
• QML changes: ran make lint-qml with no new warnings

[0xdeafbeef]

I can make it toggleable from the settings if you want. But it utilizes free space, so I see 0 problems, only value :)

[bbedward]

/claude review

[claude]

Missing the battery > 0 guard the rest of the codebase uses (BluetoothService.qml:75, BluetoothDetail.qml:365). BlueZ reports batteryAvailable true with battery == 0 for devices that don't actually publish a level, so this shows Device • 0% and returns early, skipping the UPower fallback below that may have the real value.

Suggested change

	if (primaryDevice.batteryAvailable)
	return `${name} • ${Math.round(primaryDevice.battery * 100)}%`;
	if (primaryDevice.batteryAvailable && primaryDevice.battery > 0)
	return `${name} • ${Math.round(primaryDevice.battery * 100)}%`;

[claude]

Claude review

Looks good — one minor consistency issue, no blockers.

• Missing battery > 0 guard on the BlueZ battery path, quickshell/Modules/ControlCenter/Components/DragDropGrid.qml:564

Checked: binding reactivity of secondaryText, BatteryService.bluetoothDevices shape/name matching (mirrors the existing BluetoothDetail.qml pattern), imports, I18n rules, no catalog files touched. Model: claude-opus-5.

[0xdeafbeef]

/claude review

[0xdeafbeef]

@bbedward I've added a comment with links to the Quickshell and BlueZ docs. I actually saw 0% reported while testing with connected headphones, so I kept it as a valid value instead of treating it as unavailable. I also updated the existing bluetooth details check to follow the same behavior

[bbedward]

/claude review

[claude]

Claude review

No issues found.

The battery > 0 question from the previous run was addressed by the author with docs links and applied consistently to BluetoothDetail.qml too — batteryAvailable reflects whether BlueZ exposes org.bluez.Battery1, so a real 0% is now shown instead of being swallowed by the UPower fallback. Nothing new to raise.

Checked: binding reactivity of secondaryText and the btBattery property, BatteryService.bluetoothDevices element shape (name is always a string, so the toLowerCase() matching cannot throw), the Math.round(battery * 100) scaling against Quickshell's 0–1 range, qs.Services import availability in DragDropGrid.qml, no new user-facing literals needing I18n.tr(), no translation catalogs touched, and that the remaining battery > 0 in BluetoothService.allDevicesWithBattery has no consumers so the divergence is inert. Model: claude-opus-5.