Feat: Dynamic configurable statusbar

[mazdak]

Overview & Motivation

AI Usage Note: This feature was built utilizing opus-4.5 and gpt-5.2-codex

This feature was built addressing the issues discussed in #2421. This gives us the ability to define a configurable status bar (in a format suggested by mitchellh) that is displayed upon invoking a configurable key bind (default CMD/SUPER + .)

• Status bar widgets: time (strftime), cwd/pwd, size, modifiers, pending key, CPU, memory (cursor pos stubbed for now).
• Styling for widgets via status-bar-style and per‑widget style.
• Range‑based styling via status-bar-style-range + widget style-range (e.g. CPU/mem thresholds).

My personal interest in this feature stems from the way I use ghostty in fullscreen usually split in 2 or 4. It's very difficult to tell the splits apart sometimes, especially when running certain AI agents, and having a per surface display that can be toggled on or off is very helpful.

Config

• status-bar-widget: repeatable widget definitions.
  Syntax: kind[:param=value,...]

  • kind: time, cwd, pwd, size, modifiers, pending_key, cpu, memory, cursor_pos (stub)
  • params:
    • name (string): token used in status-bar
    • format (string): strftime format for time
    • style (string): name from status-bar-style
    • style-range / style_range (string): name from status-bar-style-range

• status-bar-style: repeatable style definitions.
  Syntax: name=<name>,fg=<color>,bold=<bool>,size=<pt>

  • fg supports hex or X11 names

• status-bar-style-range: repeatable numeric range mappings.
  Syntax: name=<name>,range=<min>..<max>=<style>,...

  • inclusive bounds, evaluated in order
  • open-ended allowed (..40, 80..)
  • exact match allowed (50=style)

• status-bar: layout string.
  Use whitespace-separated widget tokens; <-> splits left/right.

Minimal (CPU + mem + cwd):

  status-bar-widget = cpu
  status-bar-widget = memory
  status-bar-widget = cwd
  status-bar = cpu memory <-> cwd

Styled widgets:

  status-bar-style = name=muted,fg=#777
  status-bar-widget = time:format=%H:%M,style=muted
  status-bar = time <-> cwd

Range styling (CPU/mem thresholds):

  status-bar-style = name=ok,fg=#5cb85c
  status-bar-style = name=warn,fg=#f0ad4e
  status-bar-style = name=hot,fg=#d9534f

  status-bar-style-range = name=cpu,range=0..40=ok,range=40..80=warn,range=80..=hot
  status-bar-style-range = name=mem,range=0..60=ok,range=60..85=warn,range=85..=hot

  status-bar-widget = cpu:style-range=cpu
  status-bar-widget = memory:style-range=mem
  status-bar-widget = cwd
  status-bar = cpu memory <-> cwd

Notes

• style-range takes precedence over style when the widget has a numeric value (CPU/memory).
• cursor_pos is defined but still unimplemented.

Quick screen recording:
https://github.com/user-attachments/assets/e64dddaf-2990-4368-9599-ccdc48693efb

[pluiedev]

No thanks. Just the GTK impl itself is far too complicated and most of the OS detection stuff must be moved into src/os and the bar itself must be a separate widget. You also blatantly ignored our AI use policy, which dictates that a) PR descriptions, like all written responses, must be written by a human and b) you must be able to test on the platforms you vibecoded for, which I heavily doubt is the case for GTK.

It is risky to open a PR on an incompletely thought-out feature because then we will be more inclined to close the PR outright rather than negotiate back and forth as to how the feature looks like in the PR itself. If you like the end result feel free to maintain this in your own branch.