Switching without the window

Four ways in, all reaching the same engine. None of them can edit a group: editing happens in the window, and the rest exist to switch.

Keyboard shortcuts

Each group can carry one global shortcut, recorded in the group’s own editor. It works anywhere, including through a screen sharing session, which makes it the only way to switch setups from a client with no terminal and no browser.

If another app already owns the combination, the group still saves and Settings lists the conflict rather than silently doing nothing. That list is the first place to look when a shortcut stops working.

The URL scheme

Two commands, activate and deactivate. The scheme is deliberately tiny: those are the two that change state, and a read-only command has no way to return its answer through a URL open.

$ open 'moredisplays://activate?group=Office'

$ open 'moredisplays://deactivate'

The group goes in a group query parameter, not in the path. Spaces are percent-encoded as %20; a + is a literal plus, per RFC 3986. A one word group needs no encoding at all, but most names are not one word.

$ open 'moredisplays://activate?group=MacBook%20Air%2013-inch%20(M1)'

Anything the grammar does not accept is rejected with a specific reason rather than guessed at: an unknown command, a missing parameter, a parameter given twice, or a path where the grammar has no use for one.

This is what a Stream Deck key, a Shortcuts action, a Keyboard Maestro macro or a link in a note should use.

The command line

$ mdctl activate Office
Activated "Office".

Ten commands, over a unix socket in the support directory. It is the right tool for anything scripted, and the only one of the four that can read state back: status, list, displays and edid have no equivalent anywhere else outside the window.

The CLI reference has every command, and the recipes page has complete scripts for the jobs people actually automate.

$ mdctl status
version: 0.1.0
state: active
active group: Office
groups: Home, Office, MacBook Air 13-inch (M1)
icloud: syncing, last synced 09:14

Activate on launch

A group can be marked to activate when the app launches. The app applies it as part of its launch sequence, after cleaning up orphaned displays from a previous run and after checking the kill switch.

Pair it with Open at login in Settings and the machine arrives at a known setup by itself, once you are logged in.

What is not here

There is no rule engine. Nothing watches for a client connecting from a particular network, or for a particular remote client software, or for a wake, and activates a group in response.

Note the distinction from protection, which does watch: it defends the setup a group applied, and never chooses which group that should be.

If you want that behaviour, build it from the outside: the client is the thing that knows it is connecting, so have it run mdctl activate over SSH as part of its own launch. The recipes page has that script.

Next

• CLI reference for every command in detail.
• Remote clients for what each client does with the display you make.