9.3 KiB
Multiple selection and group actions: implementation contract
User requirement: issue 29
asks for Shift+click selection of several functions, moving them together, and
related useful group actions. This contract derives from that request and the
existing graphical/textual equivalence requirement. It is a development decision,
not a claim that the feature is implemented or accepted. Inspected source is
b8685416f56e53e30bd11ecf93a54cea10ac8458; integration with later peer branches
requires inspection of their actual changes.
Selection and operation identity
Selection is transient and scoped to one document and rendered surface. It has an ordered set of exact visual targets and one primary target for the inspector. A semantic UUID alone cannot identify a placed node, a port on a particular placement, or a repeated occurrence in an expanded reusable Process. Navigation highlights are not edit targets. Changing surface clears the set; accepted model changes reconcile surviving exact targets without mapping a missing occurrence to another occurrence of its semantic definition.
Shift+click toggles the hit target. Plain click on an unselected target replaces the set. Pressing a selected member retains the set for a possible group drag; a stationary release that never crossed the drag threshold selects that member alone. A threshold-crossing drag keeps the group, including cancellation, refusal, snap-to-zero or returning to the original pointer position. Defer any primary inspector/layout change until the gesture outcome. The interaction must use captured pointer order and original gesture geometry even if the inspector changes layout. Modifiers must be available on the first canvas press after focus comes from another editor; passive modifier tracking must not grant keyboard command focus. Escape cancels a live gesture before clearing selection. Contextual Add/Remove from selection provides an explicit alternative to the modifier gesture. Opening a context menu captures its exact target without replacing the selection; Add/Remove operates on that captured target. Dismissing the menu preserves the set. A visible count and appropriate group actions distinguish group selection from the primary inspector target.
Property edits continue to address the primary object. No implicit bulk property editing is introduced. Group actions explicitly address the captured set and must reject stale document, revision, surface or target identity before any selection, source, history or allocation state changes.
Movement depends on the diagram's meaning
Saved Architecture and State views store placement geometry. Translate the union of selected placements and their visual descendants by one displacement; each placement moves once, including when both parent and child are selected. Derive all affected routes from the original diagram and the complete movement map. Both moved endpoint owners translate internal pins; an unmoved endpoint keeps world pins fixed. Existing State boundary rules still apply. Labels and manual attachment fractions remain relative. Other views, semantic ownership, contracts, IDs and unrelated records remain exact.
Movement admission evaluates the complete typed selection. Unsupported mixtures of placements, ports, edges, rows or read-only occurrences are refused with a reason; adapters must not silently omit members or promote ports to owner nodes.
Rejected approach: sequential MoveNode commands. Each command sees only its
own root/descendants, so routes between separate selected roots do not receive
the simultaneous translation required by docs/language.rst. A pure planner
can emit the existing atomic Batch(EditNode..., SetEdgeRoute...); a new wire
command or source schema is unnecessary. Preview and commit must consume the
same plan; tests independently construct expected geometry rather than merely
comparing those two uses of the implementation.
Process reorder and Scenario occurrence reorder change semantic sequence order. Saved Scenario presentations can additionally store lane/message coordinates; semantic group reordering preserves those authored records. A sequence group drag must reorder a stable block while retaining its internal order and applicable owner/column/operand boundaries. Existing topology and temporal/lifecycle validation remains authoritative. Qualified reused Process content must not silently edit the reusable definition. These adapters are required work for the issue, not waived because ordinary diagrams are easier.
In Allocation views, multiple selection must not silently change work-body drag from assignment to arrangement. Work-only groups use one frozen common performer destination and one all-or-nothing allocation plan. Normalize semantic work ancestry, deduplicate leaves and placements, and apply existing role/coherence rules to every constituent. Different valid initial performers on independent roots are not automatically an ambiguous destination. Any invalid constituent refuses the whole action. Mixed selections cannot partially assign only eligible members; explain the refusal and offer the existing Arrange-only operation. Explicit Arrange-only always preserves every allocation record. Destination feedback and hit geometry remain stable throughout the gesture.
The explicit Arrange amendment defines the bounded one-or-more work/performer footprint and diagnostic collision domain. Its pure planner evidence and the ordinary assignment foundation establish bounded source/planner behavior. The Allocation App/native checkpoint adds bounded Windows group assignment, explicit Arrange and ordinary performer acceptance; its limitations and source identity remain explicit. The Scenario reorder policy defines the strict sibling-block increment without implying adapter or removal acceptance.
Related group actions
Move/reorder and removal are the initial useful operation families. Saved-view Hide removes selected placements rather than the underlying engineering objects. Delete-from-model uses one aggregate impact review and transaction; preserve opposite-layer counterparts under the established deletion contract. Process and Scenario removal identifies local occurrences/messages/operands, not the reused definitions. A mixed set that cannot express one clear removal operation is refused with an explanation. Never act on only the primary object while the interface depicts a group. Alignment, distribution and duplication are separate capabilities to assess after this foundation; no speculative semantics are adopted.
The Scenario removal policy defines whole-set local admission, aggregate impact and one-step history. Its Windows App/native evidence records the tested source, mixed participant/message workflow, exact saved-source recovery and explicit coverage limits; default-branch integration remains separate.
The Process removal policy defines local occurrence/link admission, cascade normalization, implicit-order and caller consequences, and captured one-step removal. Its Windows App/native evidence and compact review follow-up identify the tested source and bounded acceptance. Default-branch integration remains open; the policy alone does not establish implementation or runtime acceptance.
Acceptance and dependencies
- Prove simultaneous geometry planning with unrelated roots/internal routes, nested and folded selections, one-ended routes, typed ports and State boundaries. Whole-model comparison, JSON/source round trips, atomic refusal, one Undo/Redo and zero-motion history behavior are required.
- Implement exact selection/primary state and focus-aware input. Exercise Shift held before canvas focus, toggle/removal, stationary click versus drag, captured event batches, hidden/stale targets and navigation invalidation.
- Connect ordinary/State previews and commits to the geometry planner, then implement group Allocation and Process/Scenario order adapters with their independent semantic evaluators. Preserve current route/attachment cancel, pan, read-only and pending-source/property behavior.
- Implement aggregate removal admission, feedback and history. Destructive semantics remain explicit; raw drafts must not be silently discarded.
- Build and exercise realistic native workflows, including multi-function selection/movement, nested selection, cancellation, source inspection, save/reopen and one-step history. Review interaction and saved-model evidence independently. Integrate with the release owner's actual combined source.
The Architecture critique and Behavior investigation contain source references and additional falsifiers. Live ownership, implementation sequencing and blockers belong to issue 29. Linux verification remains user-deferred.