Bare: A new vertical bar for Wayland

The world has seen too few Wayland status bars, so here is mine!

A couple of months ago I switched my browser to vertical tabs and really liked it. In the end, web pages today rarely span the whole width, so you basically lose nothing by taking a bit of this otherwise wasted horizontal space.

At the same time, Swaybar, the status bar that I have used for more than 7 years, cannot be rotated by design. Moreover, there are some minor annoyances that will probably never be fixed due to the project feature policy. Since I avoid fancy CSS-styled bars (because I cannot stop re-configuring them they are more CPU-intensive), I have historically avoided switching to Waybar.

So, a few weeks ago I decided to make a perfect bar (for me, at least). Fast forward to now, here is Bare. Building it was an interesting experience! I have been using it as my daily driver for more than a month now.

Layout

As I mentioned above, Swaybar has been good enough for me for years. I just wanted a bit more configurable bar that can stick to the left edge of the monitor.

The obvious benefit of this layout is that you utilize your screen space more efficiently, given that most of the content of the modern web is narrower than the screen width.

However, there is one more interesting property. Such a bar can use proportional fonts without noticeable shifts during block updates! Monospace fonts are fine for code or terminals, but proportional fonts look more natural and usually render better on lower DPI screens.

As a bonus, since a typical bar should be wide enough to render at least 2 characters, its width should also be sufficient to render tray icons (if ever supported) that do not look too small.

Blocks

Another important decision is whether the bar should implement its own blocks, or just render the i3status output. i3status is great, but I would argue that for a vertical bar it makes little sense. First, a bar of a reasonable width would only fit about 3 characters, so there is just not much space to render most of i3status placeholders. Second, the block format implies that the bar will render it in one line. That is usually not true in the vertical case, when the label and the values occupy separate lines.

Built-in blocks also have a few useful properties:

• Obviously, no JSON parsing needed.
• Single event loop for everything: fd events, Wayland events, timers.
• Simple partial rendering: the bar has the full context of what and where needs to be updated and can limit the re-rendering to the part of the buffer that’s changed.
• Blocks have separate sources of events. For example, time refreshes once a minute, exactly when the minute changes. Volume refreshes only when PipeWire sends a change event.

Overall, this should make the system resource usage even lower than what Swaybar with i3status can achieve.

Box Model

I find Swaybar a bit too inflexible when it comes to configuration. There should be some balance between re-inventing CSS and hardcoded defaults.

Borders and margins have CSS-style [top, right, bottom, left] configuration options. This is enough to reproduce both i3bar- (separated) and Swaybar-style (non-separated) workspace buttons, addressing my nitpicky sway#8656.

Note that padding is not configurable. This is not needed, since text is always centered.

Development

Bare is written in Rust. This is the type of a project that can benefit from the safety guarantees and performance that only Rust provides today.

One challenge that comes with it is keeping dependency list short. Some Rust libraries are great from this perspective. For example tz-rs has zero dependencies, but it’s more of an exception. As of version 0.2, Bare depends on 16 crates, but the full tree of dependencies consists of 158 packages.

Thoughts on AI

I made use of coding agents, namely Antigravity and Claude Code. This is not slop though, I still spent quite some time reviewing each change, rejected those that are hopeless, and edited manually those that are almost right. In some cases, no edits were necessary.

I don’t think my findings here are any new in 2026: agents do make coding faster. Especially in Rust, whose compiler is notoriously strict. Free quotas for Antigravity are fairly limited though, and Claude Code costs money. It’s up to you if the productivity gain is worth it, at least for hobby projects today.

My opinion is that LLMs are a great help when it comes to exploring a new idea, creating prototypes, or making repetitive changes, like writing new tests that are similar to existing tests. Delegating architecture decisions to an LLM is a bad idea.

Future

By now, Bare reached the point when the key features are already implemented and it completely replaced Swaybar for me.

There are a few potential improvements that may or may not be implemented:

• Icon and tray support. This is definitely doable, but it brings a ton of new dependencies to handle SVG, even when using resvg.
• GPU acceleration. This brings a lot of complexity, especially if using Vulkan. Maybe one day a new Rust library can make GPU-rendering easier. This bar updates rarely and updating a block is cheap, so there won’t be any noticeable difference anyway.

The whole point of this bar is to be lightweight and minimal, it should be bare in the end!