I wanted a system monitor in my bar that actually matched my theme instead of sitting there as a mismatched floating terminal window I had to manually position every single time I logged in. The honest first version of this project was embarrassing: wrap btop, throw it in a panel, call it done. It even shipped under that name internally. Then I actually sat with it for a week and got annoyed enough to rebuild the whole thing properly.
What exists now is System QuikView, a native Omarchy Shell plugin. No btop. No root service. No cloud account, no pip packages, nothing phoning home. It reads Linux telemetry directly off /proc and sysfs, renders it through Quickshell’s own QML, and pulls every single color it displays from whatever Omarchy theme happens to be active. Switch themes, the widget updates live, because it was never allowed to hardcode a color to begin with.
The migration path I owe past me
The installer still knows how to find and migrate that original btop-wrapper prototype: same placement, same preferences, straight upgrade path, no starting over. Small thing, but I’m glad I didn’t just delete the evidence and pretend the finished version sprang out fully formed. It didn’t. It started as duct tape around someone else’s tool and got replaced piece by piece until none of the original tape was left.
The design decision that actually took thought
Most of the surface area here is fairly mechanical: read a number, put it on a graph, color it by theme. The one part that made me stop and actually think came from GPU handling, and specifically from a question that sounds trivial until you sit with it: what does the widget show when a sensor genuinely has no reading?
The lazy answer is zero. Zero is wrong, and it’s wrong in a way that’s actively dangerous for exactly the same reason a blank medication list is dangerous. Zero degrees is not “no reading available,” it’s a specific, false, freezing-cold claim about a piece of hardware that might currently be on fire. A missing value and an actual value of zero are two completely different facts, and collapsing them into the same digit is a decision to lie every single time the sensor doesn’t answer.
So a missing sensor shows a plain dash. Not a number pretending to be data. An honest admission that nothing came back.
That same principle runs through the multi-GPU handling too. If you explicitly pick a specific GPU by name and it disconnects, the widget does not quietly fail over to whichever GPU happens to still be plugged in and keep drawing a graph like nothing happened. It shows that reading as unavailable and waits for you to notice, because silently substituting a different device’s numbers under the same label is its own kind of lie, just dressed up as helpfulness.
Auto mode gets to be smart, explicit mode does not
There’s a real tension between “just work” and “never guess wrong,” so I split it into two modes on purpose instead of picking one philosophy and forcing it everywhere.
Auto mode is allowed to be clever: prefer a dedicated GPU when one’s available and reporting, fall back to whatever else exists otherwise, and it can pick different actual devices for usage versus temperature versus VRAM if that’s genuinely what’s available. That’s a real convenience and I don’t think it’s dishonest, because nobody who picks “auto” is claiming to know or care which specific piece of silicon answers.
But the moment you pin a specific device by name, you’ve made a claim, and the widget’s job flips from being helpful to being accurate to that claim. It doesn’t get to quietly reinterpret “show me this GPU” as “show me a GPU” just because the first one went away. Same underlying data source, two completely different obligations depending on whether a human explicitly chose a specific thing or asked for the software’s best guess.
What actually shipped
Bar reading you can set to CPU, memory, GPU usage, temperature, VRAM, network speed, disk usage, or nothing but an icon. Click it, get a full dashboard: history graphs, per-process ranking by CPU then memory, temperature gauges that use the hardware’s own reported warning thresholds when it has them and fall back to a plain labeled scale when it doesn’t. Sections reorder and collapse, and that layout survives a restart instead of resetting itself every time like it’s personally offended you touched it.
Tests cover the boring-but-load-bearing stuff: no GPU present, one GPU, several GPUs, a GPU that vanishes mid-session, missing readings across the board. python3 -m unittest, a separate Node suite for the selection logic in Model.js, a QML linter, and a plugin validator Omarchy itself ships to catch structural mistakes before they become someone else’s bug report.
Installed like any other Omarchy plugin:
omarchy plugin add https://github.com/onelegdave/system-quikview.git --enable
First one of these I’ve actually finished and put out publicly rather than leaving half-built in a folder labeled “someday.” The btop wrapper would have shipped faster. It also would have kept lying to me about GPU temperature the first time a sensor didn’t answer, and I’d rather have spent the extra week than ship a monitor I can’t actually trust the numbers on.