Skip to content

feat: bidirectional screen status with right-click menus#46

Merged
trmquang93 merged 2 commits intomainfrom
feat/screen-status-bidirectional
Apr 27, 2026
Merged

feat: bidirectional screen status with right-click menus#46
trmquang93 merged 2 commits intomainfrom
feat/screen-status-bidirectional

Conversation

@trmquang93
Copy link
Copy Markdown
Collaborator

Summary

Refs backlog 8.2 — Cannot revert screen status from existing back to new/modified.

After investigation, the perceived "one-way trip" turned out to be three small bugs/affordances rather than a missing feature:

  • Phase 1 (fix): updateScreenStatus and markAllExisting in useScreenManager.js were not calling pushHistory, so single-screen and bulk status edits were invisible to undo. Now both push history matching the updateScreenNotes / renameScreen pattern.
  • Phases 2–3 (feat): The canvas status chip is now always visible (previously hidden for status === "new" non-scope-root screens) and interactive: left-click cycles New → Modify → Existing → New, right-click opens a 3-option menu that jumps directly to any status. Plumbed onUpdateStatus through CanvasArea to ScreenNode.
  • Phase 4 (feat): The right Sidebar's "Build status" pill gains the same right-click menu and now honors isReadOnly (was a latent bug — the pill was clickable in viewer mode).
  • Phase 5 (docs): New ### Build status subsection in userGuide.md covering the three statuses, click-vs-right-click affordances, the bulk "All existing" header button, undo coverage, and the read-only behavior.

Both popovers render via createPortal so they escape the transformed canvas ancestor and use Z_INDEX.contextMenu from theme.js. Read-only viewers see a plain <span> chip with no interactions.

Test plan

  • Left-click canvas chip cycles new → modify → existing → new
  • Right-click canvas chip opens menu at cursor; clicking a status applies it and dismisses
  • Outside-click on the menu overlay dismisses
  • Pressing/dragging the chip does not start a screen drag or select
  • Status chip is visible for new-status screens
  • Right-click in the right Sidebar's "Build status" pill opens the same menu
  • Single-screen status change, then Cmd/Ctrl+Z reverts
  • "All existing" header button → Cmd/Ctrl+Z restores prior per-screen statuses
  • ScreensPanel left-list cycle and right-click context menu still work (regression check)
  • Open shared flow as collab viewer: chip + sidebar pill are non-interactive (no cursor pointer, no menu, no cycle on click)
  • Mark a screen existing, generate instructions: appears as context only

updateScreenStatus and markAllExisting were missing pushHistory calls,
so single-screen status edits and the bulk "All existing" action were
invisible to Cmd/Ctrl+Z. Mirrors the existing pattern used by
updateScreenNotes / renameScreen.

Refs backlog 8.2.
The canvas status chip is now always visible (previously hidden for
status="new") and is clickable: left-click cycles, right-click opens a
3-option menu to jump directly to New/Modify/Existing. The right
Sidebar's Build status pill gains the same right-click menu and now
honors isReadOnly. Both popovers render via React portals so they
escape the transformed canvas ancestor and use Z_INDEX.contextMenu.

Read-only viewers see a plain status chip with no interactions.

User guide updated with a Build status subsection covering the three
statuses, the click vs right-click affordances, and the undoable bulk
"All existing" action.

Refs backlog 8.2.
@trmquang93 trmquang93 force-pushed the feat/screen-status-bidirectional branch from 625ad83 to 439deb9 Compare April 27, 2026 16:17
@trmquang93 trmquang93 merged commit 4b4152e into main Apr 27, 2026
1 check passed
@trmquang93 trmquang93 deleted the feat/screen-status-bidirectional branch April 27, 2026 16:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant