Frappe Draw: in-frame editing (double-click a frame to edit it)#16
Conversation
…enter a frame) Mind-map/flowchart frames were read-only on the unified canvas. Now double-clicking a frame ENTERS it: the whole editor temporarily becomes that sub-model's single-type editor (full node editing, keyboard, contextual toolbar) via a mode-strategy override — reusing the proven single-type editors, no fragile in-place coordinate plumbing. A "Back to canvas" bar returns to the composed unified view. - useEditorUi: focusedFrame state + setFocusedFrame(kind). - EditorShell: modeStrategy = getModeStrategy(focusedFrame || diagramType); a "Back to canvas · editing <type>" bar shown while focused. - DiagramCanvas: isUnified excludes focus mode (so the single-type render+ interaction take over); frame hit-rects gain @DBLClick to enter; a watcher fit-to-views on enter/exit so the frame content is centred (it renders at its own coords, not the frame origin). Verified: build + 101 JS tests + live app — double-clicking a mind-map frame enters a centred single-type mind-map editor (block substrate hidden, mind-map toolbar); "Back to canvas" restores the unified view with block + frame both shown; no errors. Editing within a frame uses the identical, already-verified single-type interaction. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Confidence Score: 4/5Logic is sound and the state machine is simple; the only rough edge is cosmetic label text. The mode-strategy override and isUnified gating are wired consistently across all three files. The nextTick(fitToView) watcher is correct. Only issue found is the raw internal key shown in the Back to canvas pill. EditorShell.vue — label text in the focus-mode bar. Reviews (1): Last reviewed commit: "Frappe Draw: in-frame editing on the uni..." | Re-trigger Greptile |
| > | ||
| <LucideIcon name="arrow-left" class="h-4 w-4" /> | ||
| Back to canvas | ||
| <span class="text-ink-gray-5">· editing {{ editorUi.state.focusedFrame }}</span> |
There was a problem hiding this comment.
The raw
focusedFrame key ('mindmap' / 'flowchart') is rendered directly as user-facing copy. Users will see "· editing mindmap" instead of "· editing Mind Map".
| <span class="text-ink-gray-5">· editing {{ editorUi.state.focusedFrame }}</span> | |
| <span class="text-ink-gray-5">· editing {{ editorUi.state.focusedFrame === 'mindmap' ? 'Mind Map' : 'Flowchart' }}</span> |
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
What & why
Mind-map/flowchart frames were read-only on the unified canvas. Now double-clicking a frame enters it: the editor temporarily becomes that sub-model's single-type editor (full node editing, keyboard, contextual toolbar) via a mode-strategy override — reusing the proven single-type editors, no fragile in-place coordinate plumbing. A "Back to canvas" bar returns to the composed unified view.
Changes
useEditorUi:focusedFramestate +setFocusedFrame(kind).EditorShell:modeStrategy = getModeStrategy(focusedFrame || diagramType); a "Back to canvas · editing " bar while focused.DiagramCanvas:isUnifiedexcludes focus mode (single-type render/interaction take over); frame hit-rects gain@dblclickto enter; a watcher fit-to-views on enter/exit (the frame renders at its own coords, so it needs centering).Testing
Build ✅ · 101 JS tests ✅ · live app ✅ — double-clicking a mind-map frame enters a centred single-type mind-map editor (block hidden, mind-map toolbar); "Back to canvas" restores the unified view with block + frame both shown; no errors (screenshots). Editing within a frame uses the identical, already-verified single-type interaction.
🤖 Generated with Claude Code