DEV Community: crazyathlete220-stack

I outlined every window in its own color so I can tell my apps apart

crazyathlete220-stack — Thu, 04 Jun 2026 14:57:05 +0000

When I have a lot of apps open, I lose track of which window is which.

These days everything has the same dark UI — the terminal, the editor, the chat
app all look alike at a glance. I kept opening Mission Control just to find the
window I wanted, and it quietly added up.

So I gave each app its own color. Pick a color per app, outline that app's
windows in it, and you can recognize them at a glance — blue is this, red is
that.

https://github.com/crazyathlete220-stack/window-border

What it does

It's a small menu-bar app. Under the hood it just asks CGWindowList for the
on-screen windows — their position and which app owns them — and draws a colored
stroke along each window's frame. Because it only reads geometry (not pixels), it
needs no screen-recording permission. The outlines are transparent and
click-through, so they never get in your way.

Colors are auto-assigned per app, but you can pin them in
~/.config/window-border/colors.json if you want "Safari is always blue."

The fiddly parts

It looks trivial, but it took a few tries to behave.

First, the outline sat slightly off from the window. macOS was "helpfully"
shifting my borderless overlay to keep it on screen; turning that off fixed it.

Then, dragging a window fast made the outline disappear behind it. The outline is
a separate window, so when the dragged window jumps to the front it covers the
outline. The fix is to lift the outline back on top whenever something moves.

Finally, the active window's outline kept hiding — every click or keystroke
raises that window above its outline. So the frontmost window's outline gets
re-lifted every frame.

Doing all of that every frame would be heavy, so it only re-stacks when something
moves (plus the frontmost window). When the screen is still, it does nothing.

The limit

The outline chases the window, so a very fast flick leaves a one-frame trail.
That can't go to zero — you can't physically attach an overlay to another app's
window.

No private APIs, MIT licensed. Color-coding turned out to be more comfortable
than I expected. If you also keep asking "wait, which window was that," here you
go.

https://github.com/crazyathlete220-stack/window-border

ytmeta: bulk-edit YouTube metadata from the CLI, without the fear

crazyathlete220-stack — Thu, 04 Jun 2026 09:47:49 +0000

If you run a YouTube channel with more than a handful of videos, some chores are
quietly miserable. Appending the same footer to every description. Renaming
titles to a new convention. Dropping a pinned-style comment on your top videos.
YouTube Studio makes you do all of this one video at a time.

So you write a script. And now you have a worse problem: a bulk videos.update
loop will happily overwrite dozens of descriptions if you get one line wrong, and
there's no undo. I wanted the bulk part without that sinking feeling.

That's the whole idea behind ytmeta:
every write is a dry-run until you explicitly say otherwise.

npm install -g ytmeta

# preview exactly what would change (reads the API, changes nothing)
ytmeta titles titles.json

# apply it once you're happy
ytmeta titles titles.json --execute

A few decisions follow from that:

every write command previews first; nothing changes without --execute
uploads default to private, so nothing goes public by accident
deletes need a typed confirmation phrase, even with --execute
your client_secret.json and token.json stay local and are never committed

A real example I use a lot — add a footer to a bunch of videos:

[
  { "id": "VIDEO_ID_1", "append": "\n—\nSubscribe: https://youtube.com/@you" },
  { "id": "VIDEO_ID_2", "append": "\n—\nSubscribe: https://youtube.com/@you" }
]

ytmeta descriptions data.json --execute

Each entry can append, prepend, or fully replace the description.

The rest of the commands: login (OAuth loopback), titles, comments,
watermark, upload, and delete.

It's a thin wrapper over the YouTube Data API — Node 18+, tested with the
built-in node:test, CI on Node 18/20/22, MIT. If it's useful to you I'd love to
hear what to add next.

https://github.com/crazyathlete220-stack/ytmeta

I turned a 2011 iMac into a second display by faking a monitor in macOS

crazyathlete220-stack — Thu, 04 Jun 2026 08:41:27 +0000

I have a 2011 iMac I can't bring myself to throw away. I just like the way it looks. But a machine sitting in a closet is a waste, so I figured I'd at least make it a second screen for my main Mac.

Turns out that's harder than it sounds.

The 2011 iMac has no video input, so it can't be an HDMI monitor. Apple's Target Display Mode looks like the answer, but the model/OS requirements rule out my current Mac. VNC / Screen Sharing does work, but the lag makes it useless as an actual display — a monitor that stutters every time you move the mouse is not a monitor I want.

So the normal routes were all dead ends.

Faking a display instead

I gave up on connecting anything physically and went the other way: create a display inside macOS that doesn't exist.

macOS has a private API, CGVirtualDisplay, that lets you spin up a screen the OS treats as a real external monitor:

@interface CGVirtualDisplay : NSObject
- (id)initWithDescriptor:(id)descriptor;
- (BOOL)applySettings:(id)settings;
@end

Once that virtual display exists, the only job left is getting its contents onto the old iMac. The setup I landed on:

Main Mac
  oldmac-display   -> creates the virtual display (CGVirtualDisplay)
  Sunshine         -> streams that display with low latency
        |
        v
2011 iMac (macOS 10.13)
  Moonlight        -> receives it fullscreen

A display called Old Mac Display shows up in System Settings, and I arrange windows on it like any external monitor. It's just being mirrored to the iMac.

Things that bit me

The display can get stranded. Place the virtual display wrong and windows fly off to a screen you can't see. So by default it quits after 45 seconds; once you trust it, run with --keep-alive. pkill -f oldmac-display kills it.

VNC really is too slow. Switching to Sunshine + Moonlight (the game-streaming stack) is what made it actually usable.

Old macOS can't run new Moonlight. On the iMac's 10.13 the latest Moonlight won't launch; you need an older build. It's in the README so nobody else loses an hour to it.

Caveat

CGVirtualDisplay is a private API, so a future macOS could break it. I'm treating this as a "fun while it lasts" project. The virtual-display part is also handy beyond old Macs — headless setups, custom-resolution scratch screens, etc.

It works well enough, and honestly I'm just happy the iMac I like is useful again. MIT licensed if you've got an old Mac gathering dust too.

https://github.com/crazyathlete220-stack/oldmac-display