Zebar: Cross-Platform Desktop Widgets Built on Native Webviews

What Zebar is for, and who ends up using it

Zebar builds desktop widgets, taskbars and popups that run on Windows, macOS and Linux from a single codebase. The project describes widgets as "powered by native webviews (_similar_ to Electron, but more lightweight)", which is the whole design bet: instead of asking you to learn a native UI toolkit per platform, it hands you an HTML surface and a webview to draw it in. The audience is people who already write front-end code and want their bar or status bar to look exactly the way they designed it, plus anyone who wants a widget that reads live system state (CPU, battery, network, media playback) rather than a static clock. If you have never written CSS, the appeal is much weaker, because the templates and marketplace packs are all HTML and JavaScript. The repository topics include bar, dock, statusbar, taskbar and ricing, which tells you the intended crowd: desktop customisers who treat the bar as a project in itself.

How a widget pack becomes a running bar

Zebar looks in the ~/.glzr/zebar directory for subdirectories containing a zpack.json file. Each zpack.json defines one widget pack, and one pack can hold several widgets, each declared separately in that file. The README gives the example of ~/.glzr/zebar/example-widget/zpack.json producing a pack with the id example-widget, and it states the lookup is one level deep only: ~/glzr/zebar/example-widget/widget-1/zpack.json is invalid. That is a real constraint on how you organise files, and it means nesting packs inside packs is not supported. Each widget is an HTML file plus its assets (CSS, JS, images). On the data side, the zebar NPM package exposes system information as reactive providers, described in the README as "a collection of functions and variables that can change over time". The provider list covers audio, battery, cpu, date, disk, glazewm, host, ip, keyboard, komorebi, media, memory, network, systray and weather. Your frontend subscribes to those values and re-renders when they change. The Rust side of the repository is a Cargo workspace with members packages/desktop and crates/*, and the Windows build pulls in a long list of windows crate features covering audio endpoints, WiFi, media control and shell properties, which is why the Windows provider surface is the widest.

Installing Zebar and running your first widget pack

The README points at the latest release for downloads: "Downloads for Windows, MacOS, and Linux are available in the latest release". There is no package-manager command documented for installing the application itself, so the release page is the entry point. For building locally, the README defers to CONTRIBUTING.md. Once the app is running, click the Zebar icon in the system tray to open the GUI. The marketplace inside the GUI is where you browse and install widget packs, and the My widgets tab has a Create new pack button that generates a scaffold from a name and a description. Adding a widget inside a pack offers several templates. The README notes that apart from the React buildless template, the other templates require Node.js and a package manager (npm or pnpm), and that you run the build command from the widget directory after source changes. The repository's own package.json pins packageManager to [email protected] and engines.node to >=14.0.0, so pnpm is the toolchain the project itself uses. A minimal pack, following the documented layout, looks like this:

Reading system state from a provider

Providers are the part that makes a Zebar widget more than a styled clock. The README documents each provider's config and outputs; the audio provider, for instance, has "No config options" and returns variables such as defaultPlaybackDevice, defaultRecordingDevice, playbackDevices, recordingDevices and allDevices, typed as AudioDevice or AudioDevice[]. The supported-OS column for every one of those audio outputs is the Windows icon only, so audio is not a cross-platform provider even though the application is. That asymmetry repeats across the list: glazewm and komorebi are window-manager integrations, and each targets a specific environment rather than all three platforms. The practical consequence is that a pack built around CPU, memory, date or weather travels well, while one built around audio devices does not. The README does not publish a single consolidated platform-support matrix for the whole provider list, so the supported-OS column next to each output is the thing to read before you commit to a design. If a provider you need is missing on your platform, the widget will not silently degrade in a documented way; the README simply does not describe fallback behaviour.

Editing marketplace packs without losing your changes

The marketplace is convenient and it is also the most likely place to lose work. The README is explicit: to edit a marketplace widget without your changes being overridden, copy the folder from the marketplace directory to your own Zebar directory. On Windows the marketplace directory is %AppData%/zebar/downloads/, and the personal directory is ~/.glzr/zebar/. Editing in place is the trap, because an update to the installed pack replaces what you changed. The README also warns against re-publishing other people's widgets without permission, which matters because packs are plain directories and nothing in the format prevents you from copying someone else's work into a new pack id. This copy-then-edit workflow is a deliberate trade-off: it keeps the marketplace simple, but it means your customised copy no longer tracks upstream fixes, and you will not be told when the original pack changes.

Where Zebar is the wrong tool

Zebar is not a drop-in taskbar. There is no documented configuration file that produces a working bar without you writing HTML and JavaScript, and the README's own path to a first widget runs through the GUI scaffold and, for most templates, a Node build step. If you want a bar you install and configure through a text file, this is the wrong shape of project. Two concrete failure modes are documented. On Windows, the README's FAQ addresses Zebar failing to start and says that in some cases updating to the latest Microsoft Webview2 version is needed, with a link to the Evergreen Standalone Installer to be run as administrator. That is a dependency on a Microsoft runtime you do not control. The second is the one-level-deep pack lookup: if you organise packs in nested folders, Zebar will not find them, and the README's own example marks that layout invalid. There is also a licensing boundary worth knowing before you fork: the project is GPL-3.0. If you plan to ship a modified Zebar inside a closed product, that licence choice is the first thing to examine, and this article cannot tell you what it permits in your situation.

Zebar against a native status bar such as Waybar

The closest comparison in this space is a native status bar like Waybar on Linux, and the difference is the rendering model rather than the feature list. Waybar draws with GTK and is configured declaratively, so a working bar is a config file plus a stylesheet, and there is no build step. Zebar draws with a webview and is configured by writing a widget as an HTML document that consumes reactive providers from the zebar NPM package. That buys you the full CSS and JavaScript ecosystem, including frameworks, and it costs you a runtime dependency on the webview and, for most templates, a Node toolchain. The platform story differs too: Waybar is a Linux tool, while Zebar ships downloads for Windows, macOS and Linux, which is the reason to accept the webview weight if you move between operating systems. Neither approach is strictly better. If your bar is a set of text modules and icons, Waybar's declarative model is less machinery. If your bar is a piece of interface design with animation and custom layout, Zebar's webview is the more direct route.

Editorial conclusion

Adopt Zebar if you already write HTML and JavaScript and want a taskbar or status bar that renders with a webview instead of a native toolkit. Skip it if you need a packaged, zero-configuration bar, since every widget pack is a directory you author and maintain yourself. Before committing, verify that the providers you depend on list your operating system, because the audio provider is Windows-only, and check the zpack.json schema for whether the options you need are exposed.

Frequently asked questions

Official sources

1. glzr-io/zebar on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases