zenity for Go: native dialogs on Windows and macOS without cgo

A Go package for asking the user something

zenity is a cross-platform Go package providing Zenity-like dialogs, described as simple dialogs that interact graphically with the user, and it is a port of the zenity command to Windows and macOS built on top of that library. The set of dialogs is the practical scope of the project: message, with error, info, question and warning variants, text entry, simple list, password, file selection, color selection, calendar, progress and notification. For a command line tool that needs a password, a file path or a yes or no answer, this is the missing piece in Go, where the standard library has no native dialog support at all. The package targets pkg.go.dev/github.com/ncruces/zenity for documentation and examples, and the README states that the repository includes both the library and the command. The design goals listed under the Why section are the ones that matter for adoption: no cgo, mostly for cross-compilation, no main loop or any other threading and initialisation requirement, and cancelation through context.

One implementation per platform behind a single API

The repository layout shows how the portability is achieved. Every dialog exists in three files at the root of the tree, one per platform: color.go with color_darwin.go, color_unix.go and color_windows.go, and the same pattern for date, entry, file, msg, notify, progress and pwd. The shared file holds the API and the common logic, and the platform files hold the native calls. The consequence is that a behavioural difference between operating systems is a difference between two implementations of the same function, not between two libraries. It also means the surface area for bugs grows with the number of platforms, which is why the README is candid that behaviour on Windows, macOS and other Unixes might differ slightly, that some of the difference is intended because it reflects platform differences, and that other bits are unfortunate limitations. The listing also shows the test layout, with a test file beside each dialog and testdata and scripts directories, and the go.mod file pulls in a small set of helpers: jsmin, go-strftime for date formatting, x/image and x/sys, plus goversioninfo and makefat as build tooling.

On Windows it needs nothing installed and no manifest

The Windows support is the part that separates this from the GNOME original, and the README lists the advantages explicitly. There are no additional dependencies: the Explorer shell is not required, and it works in Server Core, which matters for Windows containers and for headless Windows hosts where a desktop shell does not exist. Unicode support is there, so non-Latin text in a dialog renders correctly. High DPI works without a manifest, and so do Visual Styles, meaning the modern themed controls appear without an application manifest declaring the supported OS version. There is also WSL, Cygwin and MSYS2 support, documented separately in the project wiki. The cost of this is a native Windows implementation that has to be maintained alongside the Unix one, and the README credits dlgs by gen2brain as instrumental to the Windows port. The toolchain requirements are visible in go.mod, which declares go 1.25.0 with a toolchain of go1.25.12, so building for Windows means having a recent Go release.

macOS goes through osascript, other Unices wrap the original tools

The Unix side works differently on each flavour of Unix. On macOS the only dependency is osascript, the command line tool that drives AppleScript, which means a dialog is produced by asking the system scripting engine to show native panels. On other Unixes the package wraps one of three existing programs: zenity itself, matedialog, or qarma. Those wrappers are what make the library usable on a Linux distribution where the GNOME zenity binary is not installed but a compatible alternative is. The trade-off is that the behaviour and the available options depend on whichever backend is present, so a program that uses a feature only one of the three supports will behave differently across distributions. That is a different kind of inconsistency from the Windows and macOS implementations, where the same code path is compiled for you. The command port inherits the same rules, since the README says it does its best to be compatible with the GNOME version and points at that project's documentation and man page.

Installing the package, and installing the command four different ways

The Go package is a normal module fetch:

go get github.com/ncruces/zenity@latest

The command line tool has four documented routes. On macOS and WSL with Homebrew:

brew install ncruces/tap/zenity

On Windows with Scoop:

scoop install https://ncruces.github.io/scoop/zenity.json

On macOS or Windows when Go is already installed:

go install github.com/ncruces/zenity/cmd/zenity@latest

The fourth option is simply downloading the latest release. The command exists so that wrappers written in other languages can gain the same dialogs, and the README names two such wrappers, dialog-gui for Node.js and zenity.cr for Crystal. On Unix those wrappers can use the original tool, while on Windows and macOS they can use the command from this repository for portability. That is the practical path for a team whose main application is not written in Go but whose users are on Windows and would otherwise get a broken prompt.

A two year gap in the release history

The release list shows v0.10.15 published on 2026-08-05, with v0.10.14 from 2024-09-04 and v0.10.13 from 2024-07-04 before it. The last push to the repository was on 2026-08-05, the same day as the current release, so the project is not dormant, but the version sequence moved slowly between those two tags and the project uses a patch number rather than a semantic minor bump for what appears to be a substantial amount of work. The documentation is split across the package docs on pkg.go.dev, the per-dialog wiki pages linked from the README for message, text entry, list, password, file selection, color selection, calendar, progress and notification, and a separate wiki page for the Windows, Cygwin and MSYS2 support. The README itself does not enumerate the platform limitations it mentions, does not document which zenity backend is detected first when several are installed, and does not describe a compatibility table between the GNOME command and the port, so the wiki and the man page are where those answers live.

Editorial conclusion

zenity fits a Go tool that needs to ask the user something on a desktop, especially a CLI you ship as a single cross-compiled binary, and it fits Windows in a way the GNOME zenity command never did. It does not fit a server-side program, a headless environment, or a project that needs pixel-identical dialogs across platforms, since the README says behaviour may differ slightly between Windows, macOS and other Unixes and that some of those differences are unfortunate limitations. Verify first that the specific dialogs you need exist, that the context cancellation behaviour works with your call sites, and that your target Windows build accepts the result, because the documentation does not enumerate the limitations. The licence field on the repository says MIT, release v0.10.15 was published on 2026-08-05, and the last push was on 2026-08-05.

Frequently asked questions

Official sources

1. License: MIT
2. ncruces/zenity on GitHub
3. Project website
4. README
5. Releases