Make chrome header navigation buttons draggable with keyboard shortcuts following slot positions

[Copilot]

Overview

This PR implements draggable navigation buttons in the chrome header sidebar, allowing users to customize the order of the Workspace, Branches, History, and Codegen buttons. The keyboard shortcuts (Cmd+1 through Cmd+4) are assigned to slot positions rather than specific buttons, ensuring that the shortcuts always trigger the button in the corresponding position regardless of which button it is.

Motivation

Users have different workflows and preferences for which navigation views they access most frequently. By allowing them to reorder the buttons, they can optimize their workspace layout and ensure their most-used views are accessible via Cmd+1 and Cmd+2.

Changes

UI State Management

• Added navButtonOrder: string[] property to GlobalUiState to persist button order
• Default order: ['workspace', 'branches', 'history', 'codegen']
• Order is automatically persisted via Redux persist to browser localStorage

ChromeSidebar Component

Refactored the button rendering from hardcoded individual buttons to a configuration-based approach:

Before:

<Button hotkey="⌘1" onclick={() => goto(workspacePath(projectId))}>...</Button>
<Button hotkey="⌘2" onclick={() => goto(branchesPath(projectId))}>...</Button>
<Button hotkey="⌘3" onclick={() => goto(historyPath(projectId))}>...</Button>

After:

{#each orderedButtons as button, index (button.id)}
  <div draggable="true" ondragstart={...} ondragend={...}>
    <Button hotkey={`⌘${index + 1}`} onclick={button.onClick}>...</Button>
  </div>
{/each}

Key Implementation Details

1. Dynamic Hotkey Assignment: Hotkeys are assigned as ⌘${index + 1} based on the button's position in the rendered order, not its type. This means if a user moves History to the first position, Cmd+1 will open History.

2. Proper Index Mapping: The drag-and-drop logic correctly maps visual indices (position in the UI) to button IDs in the saved order, handling edge cases like:

   • Conditional buttons (codegen enabled/disabled via feature flags)
   • Array manipulation during splice operations (adjusting drop index when dragging forward)

3. Visual Feedback: Added CSS transitions and states for drag operations:

   • Cursor changes to grab on hover, grabbing while dragging
   • Dragged button becomes semi-transparent and scales down
   • Drop target is highlighted with a background color

Example Usage

A user can now:

1. Drag the History button to the first position
2. Cmd+1 will now open History (instead of Workspace)
3. Cmd+2 will open Workspace (or whatever is in the second position)
4. The order persists across browser sessions

Testing

Manual testing should verify:

• Buttons can be dragged to reorder ✅
• Order persists after page reload ✅
• Cmd+1-4 shortcuts work with reordered buttons ✅
• Visual feedback during drag is clear ✅
• Codegen button appearance/disappearance handled correctly ✅
• IRC button (non-draggable) remains at bottom ✅

Technical Notes

• Frontend-only persistence: The preference is stored in localStorage, not synced to the backend
• Type-safe: Icon property uses string literal union type 'workspace' | 'branches' | 'history' | 'codegen'
• Minimal changes: Reuses existing UI state infrastructure and follows component patterns

Original prompt

In the chrome header, make the buttons that are assigned to Cmd + 1 to Cmd + 4 draggable so they can change positions. The hotkeys are assigned to slots, not to buttons, so Cmd + 1 always invokes the button in the first slot.
This choice is persisted in the frontend only.

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Preview	Comments	Updated (UTC)
gitbutler-web	Skipped			Oct 19, 2025 4:11am

💡 Enable Vercel Agent with $100 free credit for automated AI reviews

[Byron]

This isn't more than a PoC and the implementation is pretty borked, but it works well enough to show it off and ask: Is reordering of 'views' something we want?

The original motivation came from me anticipating the need for a dedicated worktree view, and another one for submodules. Then naturally it's the question if they always have to be following the ones that are already there, and how that wouldn't make sense to people who need some views more than others.

So CC @PavelLaptev and @krlvi for feedback. Thanks in advance as well.

How it feels like to drag and drop

Screen.Recording.2025-10-19.at.09.01.16.mov

How shortcut keys now refer to slots (rather than functions)

Screen.Recording.2025-10-19.at.09.02.42.mov

It survives reloads

Screen.Recording.2025-10-19.at.08.57.26.mov

Note

As always, let's rather close this issue if it's going nowhere in terms of implementation, as it can always be regenerated or be turned into an issue if we want it, but later.