A modern X11 server for macOS, built in 30 days.

Remote app launcher

One click from the Mac status menu to an X client running on a vintage Sun. Passwords in Keychain, optional verbose progress, two-stage menu grouped by host.

Remote app launcher
The Launchers config editor. One entry per X app: host, user, the command to launch, and a Keychain reference for the password. Each [section] becomes a menu item, grouped by host.
The macXserver status menu showing the Launchers submenu pulled down, with one X app per row grouped by host.
Click the macXserver status menu, pick a host, pick an X app. The submenu is built from the entries in your launcher config (above).
The Launcher Progress window showing a verbose telnet session log.
The Launcher Progress window with verbose mode on, showing the full telnet transcript: connection, login, the DISPLAY export, and the xterm launch command. Useful while you're getting a new launcher entry working; once it runs cleanly, set verbose = false and the window stays hidden.

What it does

A two-stage menu in the macXserver status bar, grouped by host. Pick a vintage workstation; pick an X app. macXserver telnets in, sets DISPLAY to your Mac’s IP, and launches the app. The window appears on your Mac.

No more remembering the right telnet host, the right DISPLAY syntax, the right shell to use, the right path to the binary. Passwords live in the Mac Keychain. An optional verbose progress window shows you exactly what’s being sent over the wire if you want to see it.

Why it matters

When the X server is on your Mac and the X clients you actually want to run live on a Sun in the basement, the daily friction is the telnet-into-the-Sun part. That’s three steps every time: ssh-or-telnet, set DISPLAY correctly, run the binary. Multiplied across eight workstations and dozens of apps, it adds up. The launcher removes that friction.

The vintage Suns also have constraints: SunOS 4.1.4 doesn’t know about xterm-256color, the default shell prompts assume TERM=vt100, and the path to the binary depends on which release you’ve got mounted. The launcher negotiates TERM=xterm on the telnet connection so the remote shell’s prompt setup runs cleanly, and the per-host launcher configuration lets you encode the right path per Sun.

Technical detail

Launcher entries live in ~/.macxserver-launchers as a structured config file. One entry per app, grouped by host:

[ultra5]
host = ultra5.local
user = todd
keychain = macxserver-launcher
xterm = /usr/openwin/bin/xterm -bg black -fg white
xcalc = /usr/openwin/bin/xcalc
quickplot = /usr/local/quickplot/bin/quickplot

[ss2]
host = ss2.local
...

The Keychain entry stores the password under service macxserver-launcher keyed by host:user. Plain-text passwords are supported but discouraged (you can type them once and they’re stashed to Keychain automatically).

The launcher uses an interactive expect-style script under the hood to drive the telnet session: wait for the login prompt, send the user, wait for the password prompt, send the password, wait for the shell prompt, send TERM=xterm, send export DISPLAY=..., then send the binary launch. The optional progress window streams every line of the transcript so you can debug a misbehaving remote shell.

  • The launcher shipped Day 23.
  • Two-stage menu grouping by host shipped Day 26.
  • TERM=xterm negotiation shipped Day 24.
  • Plaintext password field plus Keychain fallback shipped Day 25.