How the Atmos Menu Bar Workflow Works

Atmos is not designed like a typical desktop app that lives in the Dock and asks you to think in terms of big persistent windows.

It is a menu-bar-first app.

That design choice affects almost everything about how it feels to use. The menu bar icon is the primary entry point, the main window is designed to appear and disappear quickly, and the context menu becomes a real control surface rather than an afterthought.

This guide explains how that workflow works and what hidden behaviors matter once you start using Atmos every day.

Atmos runs as a menu-bar-only app

One of the first structural differences is that Atmos hides itself from the Dock and App Switcher.

Instead of behaving like a traditional always-visible app icon, it uses the macOS menu bar as its main home.

That means the status item at the top of the screen is not just a shortcut. It is the main front door to the app.

Why the menu bar matters so much in Atmos

Because Atmos is designed around quick environmental changes, it makes sense for the app to stay close to the system layer rather than feel like a separate workspace you launch into.

The menu bar workflow supports actions like:

• opening the Atmos window
• hiding the Atmos window
• toggling app-wide disable mode
• changing playback behavior
• jumping straight to Library or Settings
• accessing support or license actions

That is a lot of responsibility for one small icon, and Atmos treats it accordingly.

Left-click and right-click do different things

Atmos uses both left-click and right-click on the menu bar icon, and the difference is meaningful.

In general:

• left-click is about showing or hiding the Atmos window
• right-click is about opening a context menu

This makes the status item feel more like a true control hub than a one-action launcher.

Left-click toggles the main window

When you left-click the menu bar icon, Atmos checks whether its main window is currently showing.

If the window is already visible, Atmos hides it.

If the window is not visible, Atmos shows it.

That seems simple, but it is one of the core rhythms of the app. The Atmos window is meant to be something you bring in and out quickly rather than leave sprawling across your workspace.

Hidden behavior: Atmos tracks visibility with notifications

Atmos does not depend only on querying the live NSWindow state in the middle of animations.

Instead, it tracks show and hide behavior through notifications so the status item can keep a reliable understanding of whether the window is considered open.

That makes the left-click toggle feel more dependable, especially when the window is animating or changing state quickly.

The window position is remembered when hiding

When the Atmos window is open and you click the menu bar icon to hide it, the app captures the current window frame before dismissing it.

That means Atmos is not just closing a generic panel. It is remembering where the user last had it.

This contributes a lot to the “quick control panel” feel of the app.

Hidden behavior: showing from the menu bar can re-center the window

When the menu bar icon is used to show the window directly, Atmos can center the window on screen rather than always restoring the exact prior frame blindly.

That gives the app a clean “summon the control panel” feeling when opened from the icon, while still keeping frame memory available for other show flows.

First launch opens the window automatically

Atmos also has a first-launch behavior that matters for onboarding.

On the very first launch, the app automatically opens its window instead of waiting for the user to discover the menu bar icon by chance.

That makes a lot of sense because a menu-bar-only app can otherwise feel invisible if the user does not realize where it lives immediately.

Hidden behavior: first launch exists mainly to surface the tutorial

The automatic first-launch open is not random.

Atmos specifically uses that first reveal so the user sees the initial tutorial and understands the app’s basic model right away.

In other words, the first-launch show is part of onboarding, not just window management.

Right-click opens the context menu

If you right-click the menu bar icon instead of left-clicking it, Atmos opens a context menu.

This menu is one of the most important hidden control surfaces in the product because it gives users access to several system-level actions without needing to navigate through the main window first.

This is especially useful for power users who want to make quick adjustments from anywhere.

The context menu changes based on license state

Atmos does not always show the same right-click menu.

Instead, it builds different menus depending on the current license state.

That means the status item is aware of whether the user is:

• fully active
• not activated
• subscription ended
• revoked
• device-limited
• network-blocked
• locked

This makes the menu feel contextual instead of static.

What the normal app menu includes

In usable states, the app menu can expose controls like:

• Disable Atmos or Enable Atmos
• Reload App
• loop toggles
• Smart Loop toggle
• playback speed options
• Library
• Settings
• Quit Atmos

That makes the context menu feel like a lightweight command center rather than just a list of navigation links.

Hidden behavior: the disable label changes dynamically

The first line of the normal app menu is especially informative.

If Atmos is active, the menu says Disable Atmos.

If Atmos is already paused, the same position changes to Enable Atmos.

That keeps the menu action explicit about what will happen next, which matters a lot for a frequently used system-wide toggle.

The menu can jump you directly into app sections

The Library and Settings menu entries do more than just open a generic window.

Atmos uses those actions to show the window and route the user into the relevant section immediately.

That is a subtle but important productivity detail. You are not forced to open the app and then navigate manually every time.

Hidden behavior: the menu can control playback settings without opening the full UI

The menu bar context menu is not just for navigation.

It can also act directly on playback configuration:

• looping
• Smart Loop
• speed

This is useful because some changes are lightweight enough that they do not need a full UI visit.

It also reinforces the idea that the menu bar is a first-class control surface in Atmos.

License-related menus are different on purpose

If the app is not activated or the subscription has ended, the context menu changes to a license-oriented menu instead of pretending the full control surface is still available.

In those cases, the menu can offer things like:

• paste license key
• subscribe or renew
• contact support
• quit

That makes the menu relevant to the user’s actual situation instead of exposing controls for a state the app is not currently allowed to run in.

Hard-blocked states simplify the menu even further

In more severe blocked states such as revocation, device limit, network-required, or locked state, Atmos simplifies the menu even more and focuses mainly on support-oriented actions.

This is a good design choice because those states are not really “usage” states. They are resolution states.

So the menu shifts from control to recovery.

Right-click inside the Atmos window can also open the same menu

The menu bar icon is not the only way to access this menu logic.

When the app is in certain blocked license states, right-clicking inside the Atmos window can route into the same context-menu system as well.

This helps users reach relevant actions even when the app is not in a normal operating mode.

Hidden behavior: some menu actions also refresh the running environment

The Reload App action is a good example here.

It does not just redraw the window. It can:

• reapply or restore the wallpaper
• reload the cursor engine
• rebuild the widget overlay
• bring the Atmos window back up

That makes it a real operational action, not just a cosmetic refresh.

Atmos does not quit when the window closes

Another important part of the menu-bar model is that closing or hiding the window does not mean the app is gone.

Atmos keeps running even after the last visible window is closed. That is exactly what you would expect from a system-style menu bar app, but it is still worth stating because it differs from ordinary app behavior.

The app remains alive in the menu bar until you explicitly quit it.

Why the workflow feels different from a normal app

Atmos feels lighter than a typical app partly because the menu bar workflow removes a lot of window-management overhead.

Instead of thinking:

• launch app
• switch to app
• find the right panel
• close the app again

the workflow becomes closer to:

• click icon
• make the change
• hide the window

That is a big part of the product’s overall feel.

What users should take away

The practical rules are straightforward:

• Atmos lives primarily in the menu bar
• left-click shows or hides the window
• right-click opens a contextual control menu
• the context menu changes depending on license state
• first launch opens the window automatically so onboarding is visible
• the app keeps running even when its main window is hidden

Once you understand that model, a lot of the app starts to feel more natural.

Atmos is not trying to be a traditional desktop window app with a menu bar add-on. It is the other way around: a menu bar app with a focused window that appears when you need it.