Add resource detail pages to the Metrics dashboard

[jdgillsp]

Clicking CPU, GPU, Memory, Network, or Storage in the notch's Metrics tab now opens a detail page, with Back returning to the overview. CPU, RAM, and GPU pages rank accessible processes with usage amounts and bars; network lists interface state/addresses, and storage lists mounted-device capacity.

Behavior and measurement

• CPU percentages use the same total CPU-counter delta for processes and the whole-machine summary. The summary separates listed, other readable, and unattributed/system time.
• RAM shows resident bytes and percentage of physical RAM. Shared pages can overlap across process rows, so RSS is not presented as an additive system-used total.
• GPU uses accessible DRM engine counters and resident memory, with driver-exposed device sensors. Engine usage is labeled separately from whole-device busy; unavailable counters stay unreported. AMD busy sensors are also supported in the overview.
• Bars default to capacity; an optional compare mode scales process bars to the largest shown while retaining actual numeric labels.
• Detail snapshots run asynchronously every three seconds while the page is open. Generation guards reject stale results, refreshes coalesce, and overview polling pauses during drill-ins. Helpers bound process/descriptor scans, subprocess output, and subprocess duration.
• Network sampling resets on interface changes/disconnection and rejects malformed counters. Binary rate/storage units are labeled consistently.

Includes accessible card buttons without corner arrows or tooltips, documented plugin-owned IPC, a read-only notch visibility status command, and updated Python dependency guidance.

Validation

• ./tests/run-all.sh
• ./tests/host-contract-regression.sh (16 checks passed)
• 39 metrics checks: 20 Python helper tests, 12 lifecycle tests executing production QML handlers, and 7 network regression cases.
• Verified the lifecycle tests detect removal of generation, inactive-tab, and queue-cleanup safeguards.
• Installed plugin validation and clean shell restart; live CPU, RAM, and GPU drill-ins collected results without new QML errors. All five helper modes exercised against the real system.

Manual review

1. Open Metrics and click each resource card; use Back to return.
2. Compare capacity/compare bars and confirm numeric labels remain unchanged.
3. Switch CPU → Memory → CPU rapidly, then close/reopen; old results must not replace the current page.
4. Close the tab and confirm detail polling stops.

GPU availability varies by driver and /proc permissions; broader hardware testing is still needed. Short CPU samples can leave unattributed time, and GPU/shared-memory rows are not additive device totals. On the tested machine, CPU/GPU collection took about 0.45–0.49 seconds and other modes under 25 ms; these are elapsed collection times, not CPU/GPU overhead benchmarks.

Screenshots

Fresh live captures of the Metrics overview and all five detail pages from the locally installed optimized build. The performance changes are still local and have not yet been pushed to this PR. Each page was captured separately, so resource values differ between screenshots.

Metrics overview

CPU details

Memory details

GPU details

Network details

Storage details

[jdgillsp]

Benchmark follow-up and proposed scope

I tested the current PR against Activity/btop and then optimized the collector locally. Btop is substantially lighter on CPU in these tests, so the native pages should serve quick inspection alongside Omarchy's tools, with Activity handling sustained monitoring and process management.

Delivery status: PR head is still ea9928c. The optimizations below are installed and tested locally but not committed or pushed. The latest six screenshots show that local build, as disclosed in the description. No performance results or lessons documents have been added to the repository.

CPU measurements

Hardware: AMD Ryzen 5 5600H, 12 logical CPUs. Existing applications and wallpaper effects remained running. All CPU percentages below use one logical CPU as 100%, not total machine capacity.

At a matched three-second refresh interval, btop averaged 0.21% and Foot 0.08%: 0.29% combined, across two 12-second samples after warmup. It was launched through Omarchy using a temporary config copy; the normal btop settings were preserved.

For each native page, ten alternating before/after pairs measured CPU time with wait4 resource accounting, including Python startup and subprocess work:

Page	Published collector: CPU ms/refresh	Local optimized: CPU ms/refresh	Reduction	Optimized CPU at 3s
CPU	120.9	77.1	36%	2.57%
RAM	100.4	55.6	45%	1.85%
GPU	205.4	84.0	59%	2.80%
Network	85.6	45.8	47%	1.53%
Storage	102.9	33.9	67%	1.13%

The native figures exclude UI rendering. Btop offers a fuller monitor, and its reference samples preceded the later optimization run; this is not a comparison of equivalent functionality or a simultaneous controlled power test.

Behavior when closed

Fresh shell runs changed only MetricsContent.qml: feature → original component from 1d629e0 → restored feature. Each stage had three 10-second samples after 10-second warmup. Whole Quickshell plus reaped-child CPU averaged 8.61% → 8.67% → 8.68% of one logical CPU, with overlapping ranges.

No added idle CPU cost was evident at this resolution, and closed-state observations found zero detail helpers. Resource polling stops when the tab closes; an in-flight refresh can finish once, with its output ignored. UI objects/caches can remain resident. The pre-existing animated-avatar timer is a separate caveat; these tests used a static avatar.

Helpers used approximately 17 MiB peak RSS; btop + Foot averaged 26.1 MiB summed RSS. These scopes differ and shared pages can be counted twice, so this does not establish a total-memory winner. No watts, battery-life, or attributable GPU-energy measurements are available.

Local changes and validation

• Avoid unnecessary imports and argparse startup; read RAM and filesystem capacity directly instead of spawning ps/df.
• Discover GPU clients once per refresh, then validate/reuse their descriptors for the second counter sample. New clients appear on the following refresh.
• Bound mount input and terminate workers exceeding eight seconds, while waiting for actual exit before a queued restart.
• Keep the three-second refresh interval unchanged and add no persistent daemon.

The full repository suite and 47 metrics checks pass locally. All five pages loaded after a clean shell restart without new QML errors, and closed-state helper behavior was checked again. GitHub CI passes for the published revision; it has not tested the unpushed patch.

Recommendation

Keep compact top consumers and remaining capacity, and provide Open Activity / Open Disk Usage handoffs to Omarchy's existing tools. Consider removing the comparison-mode switch and lengthy network address listing. Those design changes are recommendations, not implemented behavior. Slower polling or manual snapshots could further reduce cost if continuous native updates are unnecessary.

The aim is to work with Omarchy rather than reproduce its full monitoring stack. The TUI guide already gives Activity a direct shortcut (Super+Ctrl+T). Native inspection can still fit: community examples include cpu-net and btop Activity. The desired scope should be settled before adding the local optimization patch to this PR.