Fix the macOS Dock icon toggle, menubar icon, and menu labels

[edward-rosado]

macOS fixes found while using DeskThing daily: a Dock-icon toggle that didn't work, two mislabelled menu items, a menubar icon that only rendered correctly on a dark menubar, and an app icon that renders as a blank square for anyone with monochrome app icons enabled.

Every claim below was checked by driving the real menu with System Events and screenshotting the result, not by reading the code.

The Dock icon toggle

Three separate faults in one menu item.

It said the wrong thing. "Toggle Dock Icon" names the control rather than the action. Now "Hide Dock Icon" or "Show Dock Icon" depending on state.

It raced. The implementation was:

app.dock.isVisible() ? app.dock.hide() : app.dock.show()

app.dock.show() returns a Promise and wasn't awaited, while hide() and isVisible() are synchronous. isVisible() read during a transition reports the state being left, so a second click picked the wrong branch — hide, show, hide in quick succession left the icon visible.

Visibility is now tracked as intent rather than interrogated from the system. Clicks update the desired state synchronously (so the label is right the instant it's clicked) and a single settle loop drives the real dock toward it, absorbing anything that arrives mid-flight. A burst of clicks produces one final state instead of a race.

And the real killer: buildMainWindow() called app.dock.show() unconditionally — "ensure the taskbar icon is showing on mac" — and it runs from the tray click, the activate handler, the single-instance handler and both menus. So hiding worked and was silently undone moments later. That's why it looked broken rather than merely racy. It now shows the icon only if the user hasn't asked for it hidden.

I confirmed app.dock.hide() itself is blameless by isolating it in a throwaway Electron app: with a window open, with a Dock menu set, with a Tray — the tile disappears immediately, first call, every time. The API was never the problem, so something had to be turning it back on.

Menu labels

• "Open Desktop" → "Open DeskThing". It reads as a system feature, and sat directly above "Open DeskThing Client" where the pairing made it more confusing rather than less.
• "Hide Tray Icon" → "Hide Dock Icon" in the Dock menu. It called app.dock.hide(); it was hiding the Dock icon, not the tray icon. It now goes through the same shared state, so both menus tell the same story.

The menubar icon

Two bugs.

It was not a template image. The macOS asset was a colour glyph drawn literally, so it only ever looked right against one menubar appearance. It's now black-plus-alpha and flagged with setTemplateImage(true), which lets the system recolour it for light and dark.

The mark dissolved at 16px. The brand gear is a thin outline; at that size the strokes fall below a pixel and smear into grey, conspicuously mushy next to the solid glyphs every other menubar item uses. The menubar now uses a filled silhouette of the same gear, plus the stacked wordmark at 18pt with a proper @2x representation (exactly double the 1x dimensions, as macOS requires — without it a retina menubar upscales the soft 1x copy).

The first-close notification also reached for the macOS tray asset. Notifications don't apply the template treatment, so that rendered as a black-on-black smudge; it now uses the colour asset on every platform.

The app icon, and monochrome mode

This is the part worth arguing about, so here is the reasoning rather than just the artwork.

With macOS monochrome/tinted app icons enabled, the system keeps only the artwork's shape and supplies its own plate. The existing icon is a small mark on an opaque dark plate, so the plate becomes the shape and the icon renders as a completely blank rounded square — indistinguishable from any other app. I verified this by pushing the current icon through the same transform, and by screenshotting a real Dock.

That also means a gear can't be the answer: System Settings is a gear, and once colour is discarded there's nothing left to tell them apart.

So the icon is now the wordmark — the one part of the brand that is unmistakably this product — as "desk" over "thing", filling the frame, on transparency. It's the project's own vector logo rendered at 20×, not redrawn; the wordmark is roughly 6:1 and hopeless in a square, so it's split between the k and the t, with the split point taken from the logo's own geometry (the k ends at x=84.27, the t begins at x=85.34).

It's green rather than the logo's white because with no plate behind it the Dock panel is light in Light Mode, and white on white is nothing at all — rendering the installed icon over a light background showed only the green dot over the i.

If you'd rather keep the current mark, the bug is still real and the last four commits are separable — the behavioural fixes stand on their own. I'd rather you had the diagnosis than my design.

Tests

10 tests for the visibility state machine, driven through a fake dock that reproduces the real API's asymmetry: async show(), synchronous hide() and isVisible(). That asymmetry is the bug — a fake without it passes against the broken version.

Typecheck clean.

Not addressed

If "Show recent applications in Dock" is on, the app also appears in the Recents section, and nothing an app does can remove it from there — hiding the Dock icon removes the running-app tile while the Recents tile stays, which looks like the toggle doing nothing. Out of scope here, but worth knowing before anyone reports it as still broken.

🤖 Generated with Claude Code