[heffneil]

Summary

In the controller visualizer, moving the middle model of a chain to the front knocked the model after it out of its place on the port.

Repro: a pixel port chained EFL-Bat -> GE_Spinner_32_2 -> Spider. Drag GE_Spinner_32_2 onto the left side of EFL-Bat. Expected GE_Spinner_32_2 -> EFL-Bat -> Spider. Instead the Spider dropped out of its position, and the work log reported "Model chain is broken so just stuffing the remaining 1 models in in their original order."

Cause: in DropFromController's dropped-on-a-model branch, the "model did not actually move" test was

(nextfrom == droppedOn && hit == LEFT) || (">" + droppedOn->GetName() == m->GetModelChain())

The second half is true whenever m already follows droppedOn, whatever side it was dropped on. For a right-hand drop that is indeed no move. For a left-hand drop it is a swap, but the test skipped re-linking m's follower, so Spider kept >GE_Spinner_32_2 while EFL-Bat was also set to >GE_Spinner_32_2. With two models chained to the same model the port's chain broke.

Fix: the "already follows droppedOn" case only counts as "not moved" for a right-hand drop.

iPad parity

State A. The iPad's assignModelToController (XLSequenceDocument.mm) never re-linked the model that followed the moved model in its old chain at all. Moving a model within a port could leave a stale or circular chain. It now re-chains that follower to what the moved model followed, and handles the moved model's own follower being the insertion point. The note is on row 31 in plans/platform-parity/07-controllers-setup-upload.md.

Testing

• macOS desktop Debug build and xLights-iPadLib build succeed.
• Manually tested the repro above on a real layout: the following model now stays on the port in the right order.

🤖 Generated with Claude Code