[idea] Make tab bar configurable

[adriangsguruwalk]

idea / problem

I like Tmux, a lot, specially because its extensibility. The UI for me is a good place for user customization. For example, I have configured herdr to use a customizable bar ( inspiration taken from sketchybar and polybar. The idea is that herdr provides building blocks for the user to configure via bash scripts ( through the herdr CLI ) their bar, in my case, I have fully replaced sketchybar.

requested change

The tab bar I imagine could be a three blocks row where user can Define two of the blocks ( one I think should always be the current tabs ). Herdr should provide layout utilities like bar position, and the ability to push elements into this blocks as well as the arrange of the blocks. For example, in this screenshot I have layout the bar at the bottom with the tabs in the center, some status about memory/cpu and open PRs on the right and the calendar and batery on the right.

why you want this

I spend 90% of my time on the terminal, And having a single surface of integration is paramount for me. Until recently, I used a heavy customized tmux setup, but herdr offers more power with the sidebar and notifications that I like as my building blocks, so, I want to have the same or more UI customization that the one I had in tmux without relying on external tools. Also, beign able to use one less tool ( sketchybar in my case ) is a plus, it keeps my config simpler.

[adriangsguruwalk]

Rather than just describe it, I built a working prototype so the idea is concrete.

I built it quickly as a personal MVP, so I optimized for getting it working over code quality and polish. It works end to end and I've been using it daily.

Branch on my fork (you can build and run it):
https://github.com/adriangs1996/herdr/tree/feat/tab-bar-sketchybar

What it does:

• [ui.tab_bar]: position, tabs alignment, per-tab active/inactive colors
• a bar.* socket API + herdr bar CLI to push custom status items
  (text / icon / colors / region / order) into the tab row, driven by an
  external script like a sketchybarrc

How I set it up:

# ~/.config/herdr/config.toml

[ui.tab_bar]
position = "bottom-center"          # top / bottom / *-left|center|right
command  = "~/.config/herdr/bar.sh" # sketchybarrc-style script herdr runs
# active_fg / active_bg / inactive_fg / inactive_bg override the theme's tab colors

# ~/.config/herdr/bar.sh — herdr runs it and re-runs on refresh. It pushes
# items into the tab row with herdr bar, like sketchybar plugins.

while :; do
  # left region
  herdr bar set cpu  --region left  --order 10 --icon "" --icon-fg "#fab387" --text "$(cpu_pct)"
  herdr bar set prs  --region left  --order 20 --icon "" --icon-fg "#a6e3a1" --text "$(open_prs) PRs"
  # right region
  herdr bar set clock --region right --order 10 --icon "󰃰" --text "$(date '+%a %d %b %H:%M')"
  herdr bar set batt  --region right --order 20 --icon "" --text "$(batt_pct)%"
  sleep 5
done

The tabs sit in the middle; items flow into the left / right regions by order. Live values (cpu, open PRs, clock, battery) refresh from the script.

If this is a direction you'd want in herdr, I'm happy to turn it into a proper, production-quality PR that follows how you want the tab bar to look and behave. Completely fine if it's not a fit — just wanted to show it working.

[nettlesh]

This is the main feature I'd want to see added. Using herdr won't actually feel mine until we're able to fully customize the tab bar like tmux. I think personally I'd rather have the configuration for it live directly in the herdr config, but I do like your suggested implementation and having it live entirely within the config as options might be more difficult to add.

There should be three regions: left, right, and center that purely control alignment. Anything should be able to go in any region. For example, you should be able to put every component entirely in the right aligned region, and things will just be added to the tab bar in the order they are given. I think this is similar to what you've provided here in your fork.

@adriangsguruwalk If you can, I'd suggest renaming the discussion title for clarity. Just "Make tab bar configurable" would probably be good enough. Thanks for suggesting this, I'm totally aligned.

[adriangsguruwalk]

Will do as soon as possible. Thank you for the reply

[aspiers]

One specific axis of this that I would find useful: what the tab label is made of, and how narrow a tab is allowed to get.

Today the label is composed in the renderer with a fixed four columns of padding, and every tab is floored at eight columns. Neither is reachable from config, so the only way to fit more tabs on a row is to rename them. On a laptop screen the padding is a large share of each tab before any text is drawn — 4 of 11 columns for a tab named backend, and 7 of 8 for an unnamed tab showing just its number.

Concretely, two settings that would sit naturally inside a [ui.tab_bar] surface:

• a format string for the label, along the lines of tmux's window-status-format, with {name}, {index} and {zoom} placeholders — where spaces in the format are the padding, so "{name}{zoom}" gives flush labels and " {index}:{name} " gives tmux-style numbering
• a minimum tab width, so short labels can actually be short

The {index} part matters for keyboard use as well as density: with the number visible in the label, prefix+1..9 switching becomes something you read rather than count.

existing implementation

I have both of these implemented and working, rebased on current master, with tests. The branch is on my fork if you want to build and try it:

master...aspiers:herdr:feat/configurable-tab-format

The defaults render identically to today — I checked that byte for byte across a range of label widths and tab-row widths, including the centred labels and symmetric highlight padding from #2570 — so it is opt-in and changes nothing for anyone who does not set it. I would be glad to submit it as a PR if maintainers want the change and are happy for me to; I am not currently an approved contributor, so I am asking here rather than just opening one.

I wrote this up separately in #3299 before spotting this thread — apologies for the duplication. Happy for it to be folded in here if that is the more useful place for it.