AirPods working properly on Linux: battery for each bud and the case, the listening modes, ear detection. None of it existed outside Apple's world, because the system's own Bluetooth stack cannot even read those numbers. GM sat down and did it. The first commit landed the evening before last, and by yesterday it was published in the directory: 24 commits, under a day, for free.

Two years ago that would have been a joke. Today it is just another plugin in the directory, among four hundred and fifteen others.

For anyone not following along: Omarchy is DHH's opinionated Linux distribution, and I have been using it since day one. Last Friday the new version shipped with a plugin system: pieces of interface that anyone can write and anyone can install into the system bar with one command.

The community directory took seventeen days to reach a hundred plugins. After Friday, more than three hundred arrived in five days: 35 that day, 82 on Saturday, 99 on Sunday, 80 today. That is 416 community plugins published so far.

One of them is mine.

mclovin open in the bar, with the rules that already exist

What the plugin does

The problem it solves is a silly one that follows around anyone who works on a computer: you click a link in Slack and it opens in the wrong browser, or the wrong profile. The work link lands in your personal Chrome, the personal link lands in the company profile.

McLovin puts a picker in the middle of the screen when you click a link, one row per browser profile. You choose where it opens. Tick always and that choice becomes a rule, so the next link from that site goes straight to the right place. The rest is in the README.

The picker, one row per profile. Tick always and the line grows into the rule it will write

The rule form

All of it runs inside omarchy-shell, in QML: no daemon, no binary, no extra process.

There is a loop here that I like. McLovin's first version, years ago, was a bar plugin I built only for myself. Then I wanted it to be bigger than that, pulled it out of the shell and rewrote it in Rust as a standalone program with a CLI, a TUI and a GUI, meant to run anywhere. Now it is a plugin again, without carrying a single line of that Rust.

The circle closed at a different point from where it started: the first time the plugin was only mine, and now anyone installs it with one command. The Rust program is still around, it is what I use on machines without Omarchy, and the plugin can import its rules if you already have them.

I was already writing plugins. Just for myself

This did not start now. The VPN plugin, the one that switches country with the little flag next to it, was born on the old Omarchy. When I started testing Quattro I rebuilt it for the new shell, wrote another one to change the polish mode of my dictation, and a third that is a full-screen dashboard on the second monitor.

The VPN plugin open: a filter on top, countries with flags below

The voxtype one, where I build the pipeline that cleans up dictated text

All three live in ~/.config/omarchy/plugins/ and never left. Not out of secrecy. There was simply no door. They fixed something that annoyed me and stopped there, and I assumed it would always be like that.

Then HANCORE put the directory together, Quattro shipped on Friday, and the distance between "I fixed my own annoyance" and "I fixed the annoyance of everyone on the same setup" became one command:

omarchy plugin add https://github.com/guilhermeyo/omarchy-mclovin.git --enable

The difference is not technical. My VPN plugin did not get better because a directory exists. What changed is where the code can go.

A friend, four plugins, one night

A friend of mine installed Omarchy yesterday. He finished the setup around half past eight in the evening. By seven the next morning he had four plugins he thought his machine was missing, one of them completely done and already submitted to the directory for approval.

That impresses me more than my own plugin does. The loop between "this bothers me, it could be better" and "done, and it is out there for anyone who wants it" fits inside one night.

What the Mac charges for the same thing

I have a MacBook and I need it for Xcode and for publishing to iOS. I have been back on it more often these past months, and the difference in friction is large: everything asks for an authorization, everything wants a permission toggled in some panel. After a while on Omarchy, where you simply do the thing, that gets annoying.

Since I do not want to live inside it, I built a macOS bar that behaves like the Omarchy one, in Swift and AppKit. Around 7,500 lines, with a clock, calendar, battery, workspaces and window tabs I wrote myself. It is still only mine, and not for lack of open source on the Mac: Finicky, which I used to route links there, is open source and macOS only.

The difference is the size of what you have to ship. On the Mac, sharing means becoming an app: packaging, signing, notarising, writing install instructions, keeping a site alive. On Omarchy it is a repository with a manifest, dropping into a bar everyone already runs. One asks for a whole project around it, the other asks for a git push.

And Windows, which I do not even try

I have not used Windows in over fifteen years, other than opening it to play CS on Faceit. When I looked into publishing McLovin there, it was a developer certificate, signing, and the same paperwork as shipping to a store. For a program that routes links. I lost interest before starting, and with people leaving Windows 11, that difference in friction becomes a front door.

There is the other side, and it weighs the same. When Microsoft announced Recall, the impression it left was that the system would be watching everything you do on your own machine. On the Mac I already felt a quieter version of that: a lot running in the background that I do not know the purpose of, or the destination of. The average user does not see it and probably never will. I know it is there, and it bothers me.

On Omarchy everything that ships is open source. The difference is that you can audit what leaves your machine, and the answer to "what is this process" exists somewhere you are allowed to read. I wrote about this before, when I found the daemon Chrome quietly installs on macOS.

They are two sides of the same door: when a system is legible you can change it and you can see what it does. When it is opaque, all you can do is accept it.

Anyone can build a better one than mine

And somebody will. With AI today, someone can look at my plugin, decide it is bad, and write a better one by the weekend.

That does not bother me. It is the actual point. What matters is not my plugin winning. It is the annoyance getting fixed, preferably by whoever lives with it every day.

Who is holding the directory up

omarchyplugins.com is an independent project by HANCORE. He is the one spending his own time organising it, reading the code, and approving what goes in.

The verified badge does not appear on its own: somebody read the code first

Having someone review a stranger's plugin is what separates a directory from a folder of links. Mine went through that before it showed up for you, and that is somebody's work.

Wrapping up

The plugin is in the directory, the code is open under MIT, and installing it is one command.

But this was never really about my plugin. I have not used Windows in fifteen years and I have been on Omarchy for over one, and I have never seen the loop between being annoyed and having fixed it get this short. Apple headphones finally working outside Apple, written in under a day. A friend with four plugins between dinner and coffee. Three hundred plugins in five days, written by people who only wanted their own machine to be slightly better.

Things are changing, and the good part is that you can join today. If some small annoyance has been following you around for months, it now fits in one evening, and the result does not have to stay on your machine.

---

Sources:

• mclovin in the plugin directory
• omarchy-mclovin on GitHub
• McLovin (Rust)
• omarchy-pods, GM's AirPods plugin
• Omarchy