Option for vertically-efficient layout when only using one tab

[sebastiansandqvist]

What problem are you trying to solve?

v0.2.0 introduced tabs. The main thing I have been enjoying about Hubble is its use as a minimal, focused text editor with as little chrome or wasted ui space as necessary. The new tab bar takes up vertical space that I don't ever intend to use. I recognize that people use editors in many different ways and that the tabs will be a useful feature for many people. I'm wondering if, for those of us who don't want Hubble to be Obsidian, there is any interest in creating an option to restore the tabless layout when only one tab is open.

What should Hubble do?

Restore the pre-0.2.0 layout for single-tab writing.

Current workaround

No response

Examples, references, or screenshots

No response

How important is this to you?

3 — Useful improvement

Blocked by

None - can start immediately

Context

No response

[github-actions]

Labeling this needs-discussion — the premise checks out and nothing else tracks it, but "restore the tabless layout" doesn't map onto one obvious change in the current shell, and the shape of the fix is a product call.

What the code says today:

• The vertical cost is real. Before 0.2.0 the desktop chrome was a single 36px row (Toolbar) holding the sidebar toggle, back/forward, the editable file title and the actions menu. #282 split that into two 36px rows: a new WindowTitleBar (apps/desktop/src/components/WindowTitleBar.tsx) carrying the tab strip, and FileInfoBar (apps/desktop/src/components/FileInfoBar.tsx) carrying nav, folder breadcrumb, title, terminal toggle, review comments and actions. Both are h-9, stacked in apps/desktop/src/App.tsx:704 and :776.
• Hiding only the tab strip recovers nothing. The window is frameless and that first row is the drag region: it reserves the macOS traffic-light inset and sets the Windows/Linux titleBarOverlay height, both pinned to toolbarHeight = 36 (apps/desktop/electron/zoom.ts:15, apps/desktop/electron/main.ts:109). Getting the 36px back means merging the two rows again, not hiding one.
• Merging is the thing Support multiple notes open at once (tabs or windows) #240 deliberately moved away from. Tabs were put in the top row in place of the file name, with click-to-rename moving onto the active tab, after an explicit round on exactly this tradeoff (fixed 36px, drag region, traffic-light inset). A single-tab merged row has to re-home rename, breadcrumb, back/forward, terminal toggle, review comments, actions menu, plus + / All Tabs, inside 36px minus insets.

No duplicate: #240 is the tabs issue (closed), #291 is terminal-per-tab. Nothing tracks chrome density.

Open questions:

1. What actually goes away at one tab — the two rows merge back into the pre-0.2.0 single row, or FileInfoBar hides outright (dropping breadcrumb, back/forward, actions)? Hiding just the tab strip is a no-op for vertical space.
2. Automatic on tab count, or an explicit preference? Automatic means the editor jumps 36px the moment a second tab opens or the last one closes.
3. If merged: where do rename, breadcrumb, back/forward, terminal toggle, review comment summary and the actions menu sit in one 36px row, and what happens to +, Cmd+T and Cmd+Shift+A while no strip is visible?
4. Is the underlying ask narrower or broader than one tab — i.e. "hide chrome while writing" regardless of tab count (a zen/focus mode), which may be the better-scoped feature and would also serve multi-tab users?
5. @bholmesdev — does a layout preference fit the product direction here at all, or would you rather tune the default density (e.g. a shorter combined row) than add a setting?

---

Triaged by a Warp Factory agent.

---

Triaged by a Warp Factory agent.