fix(desktop): allow hiding the status bar

[Coooder-Crypto]

Summary

• add display.desktop_statusbar with on, off, and auto-hide modes
• add the preference to Desktop Settings → Appearance
• reveal the auto-hidden bar from the bottom edge with pointer or keyboard focus
• keep portaled status-bar menus visible while they are open
• keep the Desktop preference independent from the TUI /statusbar setting
• migrate the released whole-bar visibility preference into the active profile
• add English, Simplified Chinese, Traditional Chinese, and Japanese copy
• document the setting and add regression coverage

Why

The Desktop status bar includes a continuously updating session timer. This can be distracting or stressful for users who prefer a quieter workspace, while the TUI already provides control over its own status bar.

The setting defaults to off, matching the current opt-in status-bar behavior on main. Existing users who already have the released local visibility preference keep their choice through a one-time profile-config migration. Hiding the status bar does not hide the composer, send button, model picker, or other input controls.

Validation

• focused Desktop UI tests: 67 passed
• Python configuration test: 1 passed
• Desktop TypeScript typecheck
• targeted Desktop ESLint
• Desktop production build

Fixes #62981

[Coooder-Crypto]

Hi @CrucisLee, @jamesxia1988, and @marsmensch — thank you for the thoughtful issues and prior work around the Desktop status bar.

This is my first contribution to Hermes Agent, and I’m really happy to contribute to a project I’ve enjoyed exploring. I learned a lot while working through the Desktop configuration, UI, accessibility, and localization paths.

This PR addresses #62981 by adding three status bar modes:

• on — preserves the existing behavior
• off — hides the informational bar while keeping all composer controls available
• auto-hide — reveals the bar from the bottom edge using pointer hover or keyboard focus

I also reviewed the related readability work in #61535/#63028 and the tooltip work in #41967. I’ve kept this change focused on visibility controls so those visual and tooltip improvements remain compatible and can evolve independently.

Since this is my first contribution here, I’d especially appreciate any feedback on the implementation, accessibility behavior, naming, or project conventions. Thanks for taking the time to review it!

[CrucisLee]

Review as the original issue author (#62981)

Thanks for picking this up — happy to see it land. Walked through the full diff and a few notes from the issue author's perspective:

What works well

• off mode returning null rather than display: none-ing an existing element is the right call — the timer really isn't there, not "hidden but still in the layout." This is exactly what the issue asked for in the "持续视觉压力" framing.
• auto-hide uses CSS translate-y-full + group-hover/statusbar + group-focus-within/statusbar, no JS timer. Clean, GPU-friendly, no setInterval leak risk.
• Optimistic update with rollback in persistDesktopStatusbarMode is the right pattern for "settings that should feel instant." Good test coverage for the rollback path too.
• Default on preserves upgrade compatibility — sensible.
• Translation coverage across en / zh / zh-Hant / ja is appreciated.
• The comp/desktop label now exists in the repo (didn't when the issue was filed), and you used it correctly.

Two things to consider (non-blocking)

1. Merge conflict. The branch shows mergeable: CONFLICTING — likely just drift from main. A rebase should clear it.

2. Keyboard reachability of the reveal zone. The 2px-tall <div data-slot="statusbar-reveal-zone" tabIndex={0}> is keyboard-focusable, and the focus-within transition should fire on Tab — but I haven't run it locally to confirm the focus chain actually works in the real Electron shell. If it doesn't, the screen-reader / keyboard-only user experience would silently regress compared to the previous "always visible" behavior. Worth a manual pass:

   • Tab through the chat surface — does the reveal zone receive focus visibly?
   • Once focused, does the status bar slide up? (CSS group-focus-within/statusbar should handle this, but a smoke check is cheap.)

   If you'd rather not block on this, the fallback is a dedicated Cmd+. shortcut that toggles auto-hide → on → auto-hide, but I don't think it's required for this PR.

Not a concern

• No new dependencies
• TUI /statusbar independence preserved
• isSecondaryWindow() still skips the bar for pop-out windows
• No prompt-cache implications (display config, not conversation state)

Happy to approve once the merge conflict is resolved. Thanks again for the thorough fix.

[Coooder-Crypto]

Thanks so much for the thoughtful review, @CrucisLee !
I rebased the branch onto the latest main and resolved the conflict. I also completed a manual smoke test in the Electron shell with auto-hide enabled: starting from the composer, Tab reaches the bottom-edge reveal zone, and the status bar slides into view and remains visible while focused.
The focused UI tests, Python config test, TypeScript typecheck, targeted ESLint, and production build all pass. I kept the current keyboard behavior and did not add Cmd+. since the existing focus path works as intended.
Thanks again — I really appreciate you taking the time to review my first contribution!

[teknium1]

Thanks for the focused accessibility improvement. Current main still always mounts the Desktop status bar at apps/desktop/src/app/shell/app-shell.tsx:220, so the feature remains needed.

Problems

• In auto-hide, the footer is revealed only by group-hover/statusbar / group-focus-within/statusbar (apps/desktop/src/app/shell/statusbar-controls.tsx:79-80). Status-bar controls include dropdown menus (apps/desktop/src/app/shell/hooks/use-statusbar-items.tsx:248-304, :360-395), but DropdownMenuContent is rendered through a Radix portal outside that group (apps/desktop/src/components/ui/dropdown-menu.tsx:77-94). Moving focus or the pointer into an open menu retracts the footer while the menu is active.

Suggested changes

• Retain the auto-hidden footer while a status-bar dropdown is open, and add a regression test covering focus inside a portaled status-bar menu.

Automated hermes-sweeper review.

[teknium1]

The reveal group does not contain Radix menu content: DropdownMenuContent portals under document.body. Once a status-bar menu opens and focus/pointer moves into it, these group selectors stop matching and retract the footer. Please retain visibility while any status-bar dropdown is open, with a regression test for that portal-focus path.

[Coooder-Crypto]

Thanks for catching this, @teknium1 — I’ve fixed it in the latest update.
The auto-hidden status bar now remains visible while a dropdown is open by tracking the Radix trigger’s data-state="open", which stays inside the footer even though the menu content is portaled under document.body.
I also added a regression test that opens a status-bar menu, moves focus into the portaled menu item, and verifies that the status bar remains revealed.
I rebased the branch onto the latest main and resolved the shell refactor conflict as well. The focused UI tests, Python configuration test, typecheck, lint, and production build all pass locally.
Thanks again for the thoughtful review — I really appreciate the guidance on my first contribution here!

[CrucisLee]

Thanks for the thorough follow-up, @Coooder-Crypto — both the merge conflict and the keyboard-focus path I flagged in my earlier review are addressed here, and Teknium’s portal concern (Radix menu content rendering under document.body and pulling focus/hover out of the footer group) is now handled at apps/desktop/src/app/shell/statusbar-controls.tsx via has-data-[state=open]:translate-y-0 has-data-[state=open]:opacity-100, which keys off the local trigger’s data-state instead of the group selectors. Nice call on the matching statusbar-controls.test.tsx regression test for the portaled menu path.

LGTM from my side — happy to see this land. 🎉

[CrucisLee]

@teknium1, looks good from my side. It appears there aren’t any check runs on the branch yet—could you trigger the usual CI before merge when convenient?

[CrucisLee]

@Coooder-Crypto — heads up on a development since my last review: Hermes v0.20.0 (shipped Aug 3) landed "status bar hideable" on main — a per-item right-click toggle in the status bar that lets users hide the session timer (and other items) individually (#68140/#72960). That covers the core accessibility ask from #62981, which is why I was tracking this PR.

Your whole-bar approach is still the more complete UX — off removes the entire bar from the render tree, and auto-hide is genuinely novel versus what's on main now. But since the underlying issue is resolved, I don't want to keep you in an indefinite rebase loop against a feature that already shipped.

Two paths, your call:

1. Close this PR — the original problem is solved, and your work is well-documented reference for anyone who picks up whole-bar hiding later.
2. Narrow it to the auto-hide enhancement — refocus the PR on the one capability main doesn't have, and I'll push to get CI and review moving.

Either way, thanks again for the careful work — the portaled-menu fix and its regression test were excellent.