How Atmos Handles Screen, Space, and Desktop Changes

Atmos spends a lot of time living around the edges of macOS. It sits in the menu bar, draws on top of the cursor, places widgets at desktop level, and can replace your wallpaper with still or moving media. That means it also has to react when the desktop environment changes underneath it.

This guide explains what Atmos does when you switch Spaces, wake your display, activate another app, or change your monitor setup.

Why desktop changes matter

Most apps can ignore these events because they only need to redraw their own window. Atmos is different. Several of its features depend on system-level placement:

• the main Atmos window floats and can join all Spaces
• the cursor skin overlay spans the full screen layout
• widgets sit at desktop level
• wallpapers are drawn in a separate borderless window

If the desktop changes and those layers do not update correctly, users would see broken positioning, a visible system cursor, missing widgets, or wallpaper content on the wrong screen.

The main Atmos window follows Space changes

The main Atmos panel listens for activeSpaceDidChange so it can re-promote its window level when the current Space changes.

That matters because Atmos is designed to stay available even when you move between desktops. If the window is visible during a Space switch, Atmos orders it to the front again so it does not quietly fall behind the new desktop state.

This is part of why the app can feel stable even though it is not a traditional docked windowed app. The panel is treated more like a lightweight floating utility surface than a normal document window.

Cursor skins re-hide the system cursor after Space switches

Cursor replacement is one of the easiest features to break during a desktop transition. macOS can reveal the real system cursor when:

• you switch Spaces
• another app becomes active
• the app resigns active state
• your displays wake up

Atmos explicitly watches those cases. When they happen, it performs a tiny synthetic mouse nudge so its cursor-hiding path runs again even if the user has not physically moved the mouse yet.

That is an important hidden behavior. Without it, the custom cursor could look fine during normal movement but briefly fail after desktop transitions until the next real pointer event.

Cursor overlays rebuild when monitor layouts change

The custom cursor overlay is not limited to a single monitor-sized window. Atmos builds a borderless overlay that spans the union of all connected screens so the custom cursor can move across the full layout.

When screen parameters change, Atmos restarts that overlay system. This covers cases like:

• connecting a new display
• disconnecting a display
• changing resolution or scale
• rearranging monitor positions

Instead of trying to patch the old overlay in place, Atmos tears it down and rebuilds it against the new screen geometry. That is the safer approach for a full-screen cursor canvas.

Widgets rebuild their desktop overlay too

Widgets use a different overlay from cursor skins, but the idea is similar. Atmos creates a borderless window just above the desktop window level, makes it transparent, and sets it to ignore mouse events so it never blocks the desktop itself.

When widgets need to refresh, Atmos rebuilds that overlay window. It also recalculates screen origin and screen size so widget placement continues to map correctly to the current desktop frame.

This is one reason widget positioning feels persistent rather than fragile. Atmos stores widget positions in normalized values, then translates those values back into real screen coordinates using the current screen frame.

Wallpapers are rebuilt from the current screen

Atmos wallpapers are also drawn in their own borderless desktop-level window. When a wallpaper is applied, Atmos creates a fresh window for the current screen, sets its position, and then attaches either an image view or a looping video layer.

That means wallpaper rendering is tied to the active desktop frame at the moment the wallpaper is built. When the app performs a broader reload, it re-applies the active wallpaper profile so the wallpaper layer is rebuilt cleanly instead of relying on stale window state.

Atmos has a general reload path for desktop systems

There is also a broader app reload path that re-applies several systems together:

• wallpaper
• cursor skin engine
• widget overlay
• main Atmos window

This matters because some desktop changes are easier to recover from by reloading the full visual stack rather than trying to repair each layer in isolation.

For users, this mostly shows up as resilience. Atmos can lose and rebuild parts of its desktop presence without needing a full app restart.

Hidden behaviors worth knowing

Here are a few useful details that are easy to miss:

• the main window starts hidden and is only revealed when summoned from the menu bar
• if the window is visible during a Space change, Atmos promotes it again so it stays usable
• cursor re-hide logic is triggered even without real mouse movement
• widget overlays are visual-only and never intercept desktop clicks
• desktop layers are usually rebuilt instead of being incrementally stretched into a new screen layout

These are not flashy features, but they are a big part of what makes Atmos feel polished during everyday use.

What this means in practice

If you use Atmos on a laptop that docks into external monitors, switch between multiple Spaces, or wake your machine often, you are already relying on these behaviors. They help Atmos keep its cursor, widgets, wallpapers, and floating window synchronized with macOS as the environment changes.

That is one of the app's more technical strengths. A lot of Atmos works because it quietly repairs its own desktop layers when the system changes around it.