Plugins on onelegdave.dev

The Droid You Are Looking For

OneLegDave — Fri, 11 Sep 2026 14:00:00 -0700

Second plugin. This one puts your Android phone on your desktop: mirrored screen, mouse and keyboard control, no root, no Samsung account, no paid tier, no separate app installed on the phone begging for permissions it doesn’t need.

Under the hood it’s scrcpy doing the actual mirroring, because scrcpy is excellent and rewriting it would be idiotic. KDE Connect is optional on top for battery status and Ring. What I built is the part that makes those two things pleasant to live with instead of a pile of terminal commands you look up every single time.

Currently sitting in the Omarchy marketplace queue waiting on security review, which feels appropriate given how much of this post is about security decisions.

The thing that took the most thought

Getting a phone mirrored is not hard. Getting a phone mirrored is scrcpy and about four minutes of reading. The hard part is everything around it, and specifically one question that came up over and over in different costumes: when is this software allowed to guess?

Take phone identity. Multiple connections can point at the same physical phone. USB and Wi-Fi at the same time, IPv4 and IPv6, an address that changed when your router handed out a new lease. You want those grouped into one card, obviously, because they’re one phone.

But grouping is a claim. If I merge two connections into one card, I’m asserting they’re the same device, and if I’m wrong your input goes somewhere you didn’t intend. So merging only happens on hardware identity that Android actually reports. Matching model names never merges anything. Matching nicknames never merges anything. Two Pixels with the same nickname are two phones until the hardware says otherwise, because “they’re both called Pixel” is a coincidence, not evidence.

If Android refuses the identity query and discovery can’t work it out, the connection stays separate as an unresolved entry rather than getting quietly filed under whichever phone looks closest. An unmerged duplicate is a minor annoyance. A wrong merge sends your keystrokes to the wrong device.

Reconnecting without being creepy about it

Remembered phones reconnect automatically when discovery advertises the same identity, even if the address and port both changed. That’s genuinely convenient and it’s the behavior you want.

What it does not do is automatically pair with phones it’s never seen. It does not start a mirror session on its own. Retries are capped at once per address every 30 seconds, and you can turn the whole thing off. After a successful pairing there’s a ten minute window where discovery can finish the connection, and then it stops.

The difference matters. Reconnecting to a phone you already explicitly authorized is completing something you started. Pairing with an unknown phone because it happened to show up on the network is a decision nobody asked it to make.

Same principle as the GPU selection in my last plugin: auto mode gets to be clever, explicit choices get respected exactly as made.

Wake is not unlock

There’s a Wake/unlock button for when the phone’s asleep. It sends Android’s wake command and asks Android to show its normal unlock prompt. Then it stops and you unlock the phone yourself.

It does not submit credentials. It does not bypass a secure lock. It cannot, and it shouldn’t be able to, and I’m not interested in building the version that tries. Lock screens and capture-protected apps keep enforcing their restrictions through the mirror exactly as they should, and if that’s inconvenient in some specific app, good. That’s the lock working.

What it does not do, deliberately

No telemetry. No advertising. No cloud relay. No automatic update check. No crash upload. Nothing phones home, ever.

Runtime phone endpoints are restricted to private local-network addresses. There’s no support for pointing it at a public Internet endpoint or overriding the remote ADB server, because a phone-mirroring tool that can be aimed at an arbitrary remote host is a substantially different and worse thing than one that can only talk to your own LAN.

Automatic clipboard sharing is off. You paste with an explicit keystroke or it doesn’t happen. Pairing codes go through standard input, get cleared from the panel, and never touch disk or appear in a process command line where anything reading the process list could scoop them up.

Nothing gets installed just because you opened the panel. There are Install buttons for missing tools, and they do exactly nothing until clicked.

And it’s honest about what authorization actually means: ADB pairing gives this computer debugging access to your phone, disabling the plugin does not revoke that, and if you stop trusting a machine you need to forget it in Android’s own settings. That’s in the README rather than buried, because someone who installs this should understand what they just handed out.

The bit I’m quietly pleased with

The four-step connect guide. Desktop, Phone, Pair, Ready. Every one of those steps can fail in its own specific way and each failure gets its own specific message instead of a generic “could not connect” that leaves you guessing which of five things went wrong.

Wireless pairing on Android has a genuine trap in it: the pairing port and the connection port are different numbers, and nothing about the Android UI makes that obvious. People get it wrong constantly and then have no idea why nothing works. So the plugin calls it out directly, in bold, right where you’d hit it.

That’s not clever engineering. It’s just having actually used the thing and noticed where I personally got stuck.

omarchy plugin add https://github.com/onelegdave/omadroid --enable

Waiting on security review for the marketplace. In the meantime it installs fine straight from the repo, and every command it can run and every network endpoint it can reach is inventoried in SECURITY.md if you’d rather check before trusting it. Which, for something that gets debugging access to your phone, you probably should.

Zero Is a Lie

OneLegDave — Sun, 06 Sep 2026 11:00:00 -0700

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.