Feat(SemanticWorkflow): Copy-Past

[hugou74130]

Overview

Allow users to copy and paste a sequence of frames within and across sheets.

Scope

This issue focuses on frames only (not sections), given the open discussion around potentially rethinking sections entirely.

Addressing the design considerations

What can be copied?

The "affected frames" (multi-select via Ctrl+click, mini-joystick highlighted in green) are the natural source for a copy. They already represent a meaningful user-defined selection.

A single active frame (green border) is also copyable as a degenerate case (1-frame selection).

Sections as a copy unit are excluded from this issue pending the broader sections redesign discussion.

How is the clipboard stored?

An in-memory clipboard (a simple array of deep-cloned SectionInputs). This naturally supports the BLJ use case — copy 2 frames (A pressed / A released), paste repeatedly.

Designed to be extensible to named/saveable clipboards later, but out of scope here.

UX

• Copy button in the FrameListGui toolbar → copies affected frames into the clipboard
• Paste button in the FrameListGui toolbar → inserts clipboard frames after active_frame
• Keyboard shortcuts Ctrl+C / Ctrl+V as a secondary option (if feasible given the current input system)

Paste behavior at section boundary

When pasting beyond the last frame of a section: append to the section. No frames are overwritten — paste is always an insert, never an override.

[FramePerfection]

This issue focuses on frames only (not sections), given the open discussion around potentially rethinking sections entirely.

For context, I'm considering making sections purely a management tool that has no semantics for the actual run, and instead add multiplicity and end conditions to what frames currently are. That is, each "frame" would semantically become what is now a section, except it's only doing one input (including button presses!).
"Sections" would then be things under which you can group a sequence of "frames" that you can collapse and extend, just like you can now. They wouldn't determine what happens in game anymore, though.
This consideration should not affect the scope of this issue however, despite maybe changing the "data" that a "frame" represents.

The "affected frames" (multi-select via Ctrl+click, mini-joystick highlighted in green) are the natural source for a copy.

The "affected frames" selection can be sparse, e.g. two consecutive inputs selected, then skipping two or three frames, then two more frames, then a frame from even a different section.
Should the sparsity be conserved in some way when pasting?
My first instinct is to just say "no" and collapse them into a list when copying and always just paste that list, particularly because defining meaningful semantics for the cross-section selection case would be incredibly hard.