All guides

Guides · Positioning

Why gbar, and not another tab

What a menu bar companion does that pinned tabs, e-mail filters and PR-only viewers don't.

3 min read

GitHub state changes many times an hour, and every common way of watching it either interrupts you or costs a context switch. The menu bar is the one surface that is always visible and never in the way. That's the whole bet behind gbar.

What people use instead

ApproachGood atFalls short
Pinned browser tabFull GitHub UIYou check it, it doesn't tell you; every look is a context switch
E-mail notificationsDurable recordMinutes late, no CI state, drowns in list noise
PR menu bar appsSame always-visible surfacePR-only viewers: no issues, inbox, quick actions or saved searches
gbarOne glance: PRs, per-check CI, issues, inbox, actionsNot a full client; deep work still happens on github.com

gbar is openly inspired by PullBar; the difference is scope. PullBar is a PR viewer, while gbar is a general GitHub bar: mentioned PRs, issues, per-check CI, quick actions (approve, merge, mark read), desktop notifications, a starred-repo signal, a watchlist that feeds Actions and Releases tabs, arbitrary saved queries, and multiple accounts including GitHub Enterprise.

Principles

  • Glanceable. What needs you (PRs awaiting review, failing CI, new review requests) reads straight from the menu bar badge, no window required. The menu shows state; one click lands you on the exact page.
  • Yours to run. OAuth device flow or a personal access token, tokens in the Keychain, no backend between you and the GitHub API. Set it up in a couple of minutes.
  • Source-available. The entire app is on GitHub under PolyForm Shield: read what touches your token, modify it, redistribute it. The one thing the license forbids is reselling it as a competing product.

The best status surface is the one you never have to open.


Convinced? Getting started takes about a minute.