mirror of
https://github.com/stablyai/orca.git
synced 2026-11-06 03:57:35 +00:00
Jinwoo Hong
a349bfa6cc
* Agree with main on a workspace's first group and the tab order, and stop writing a preview flag main never stores (dark, layout-owner build only) Switch-on builds only; switch-off behaviour is unchanged. Group ids: a window save made before main's frame with a workspace's first tab carries none of that workspace's tab-bar records, so the Loader rebuilt the tab in the group it names for the workspace while main had minted a random one: every workspace's first save replaced main's group. Main now names a workspace's first group as the window's root group and the Loader do (`workspaceRootGroupId`), or takes the sender's when the window drew the tab in a group main lacks (the window keeps its emptied group); the window's `ensureGroup` names it the same way. The detector reads a lone group with no stored tree as that group's leaf, as main's own save writes it. Empty groups: the window never saves a group it holds empty, so a save cannot bring back one main closed (locked by a test). Tab order: a reorder the window makes itself (an anchored CLI or agent create, a reopened tab's old slot) is recorded in main as `moveTab` steps at the store boundary; callers that already asked main pass `layoutOwnerHandled`. The reopened-editor record this replaces is deleted. A paired client's move (`ui:moveSessionTab`) goes to main first through the tab-bar drop path. Preview: activating a tab removed its preview flag by writing `isPreview: false` on every tab; main stores no flag, so every activation changed the tab in main's model. The window now drops the flag instead. * Record a reopened tab's place in main every time, leave a move into a tab's own group alone, and keep a preserved preview untouched (dark, layout-owner build only) Review fixes, switch-on only: - A reopened tab's place is recorded as one moveTab whenever its old position is known, as the deleted editor-only record did, now for every kind; the reorder it may make is not recorded twice. - A move into the tab's own group (a paired client can send one) goes to today's no-op instead of a moveTab that reordered the tab. - Activation that preserves a preview returns the tab unchanged. Tests: switch-off first group stays minted; tabOrderMoves refuses a duplicate order. * Send a paired client's tab reorder to main as its whole order (dark, layout-owner build only) A client reorder names the group's full order, but it went to main as one moveTab of the named tab, so [a,b,c] -> [b,a,c] naming c moved nothing anywhere. It now takes the store's reorder path, whose record turns the whole order into main's moves (tabOrderMoves), the one rule for every window-side reorder. Moves and splits still go main-first.