How M3E Canvas Makes Space Behave
In M3E Canvas, spatial automation begins at the pointer but ends in the design document. This chapter focuses on the rules that decide when a dragged part should join a nearby structure, when it should remain free, and how a later Tidy command can regularize a screen without erasing deliberate composition. Understanding that distinction lets the reader judge the editor by its control boundaries: the magnet should reduce friction, while grouping, layers, locks, and manual overrides should keep the author's intent in charge.
The magnet and the guide stay close to the author's hand
A free-form canvas has an awkward tension. If every part remains completely independent, arranging a row of buttons or a column of list items becomes tedious. If the editor snaps too aggressively, a part that happens to pass near another one becomes attached to the wrong structure. M3E Canvas addresses the tension with a soft magnet rather than an unconditional snap.
The first condition is compatibility. A dragged part does not search every object on the canvas. It looks for an existing run whose component family and axis make sense together. Buttons and icon buttons belong to a horizontal button family; list items belong to a vertical list family. A nearby card, text label, or navigation bar is not a candidate merely because its rectangle is close. This family check is the first protection against a spatial coincidence being mistaken for a structural relationship.
The second condition is proximity in the right directions. The editor searches insertion slots along the run and compares the dragged part's position with the slot on the main axis and across the row or column. A part must be close enough in both senses to enter the magnetic field. Being beside a row but far above it is not enough; being aligned with a row but separated by a large gap is not enough either. The result is a useful middle ground: the author can bring compatible parts together naturally, but the editor does not treat general canvas adjacency as a command to merge.
Attraction is gradual. Once a candidate slot is found, the dragged part is drawn between the cursor's position and the slot, with the pull increasing as the cursor approaches the target. This makes the destination visible before the document changes. The author can feel that the two buttons are about to become a run, yet can still move away. On release, a part that is still being attracted settles into the run after a short landing phase; a part that never commits remains a separate group at its chosen position.
That landing phase matters more than it may seem. A hard snap changes the document at the first moment a threshold is crossed, which can make a drag feel as though it has been taken over. M3E Canvas lets the motion communicate the pending structural change and commits the insertion after the settling interval. A run that accepts the part also adjusts its anchor when the new part is inserted at the front, so the existing members do not make an unexplained sideways jump. The visual transition and the document update are designed to agree.
There are explicit failure and escape paths. A locked run is considered finished and does not move to make room. A free group is not treated as an available connected run. A part from an incompatible family receives no magnetic slot. If the author holds Ctrl or Cmd, the editor removes the magnetic target, alignment guide, and 4dp grid for the duration of the gesture. That modifier is not a minor keyboard convenience. It is a statement that automatic regularization must have a visible off switch when the author needs exact, unusual placement.
Alignment guides solve a related but different problem. They compare the edges and centers of the part being moved with nearby parts and, in the phone canvas, with useful lines on the frames themselves. When the part is close to one of those lines and is not already being pulled into a magnetic run, the guide nudges it into alignment and draws the corresponding visual guide. The guide does not change a list into a list or a pair of buttons into a connected group. It only helps the author make a geometric relationship precise.
This difference gives the two interactions distinct meanings. The magnet proposes a structural relationship: “this part may belong in this compatible run.” The guide proposes a geometric relationship: “this edge or center appears intended to line up.” Tidy, discussed below, will make a larger layout decision. Keeping those scales separate helps the author understand what the editor is doing at each moment.
The flow has two separate entry points because a live drag and a Tidy operation have different ownership. During a drag, the author controls the cursor and the editor offers a suggestion. During Tidy, the author explicitly invokes a rule set and accepts a larger transformation. Even then, locked or intentional groups remain protected. The diagram is therefore a map of authority as much as a map of geometry.
A simple example makes the conditions concrete. Suppose two buttons are dropped on the same horizontal line with a small gap. When the second button enters the compatible field, the canvas shows it easing toward the insertion slot. On release, the two become a connected button run. Their outer corners remain rounded while the adjoining inner corners use a tighter treatment, so the shape communicates that the two controls are related. If a list item is dragged near the bottom of a vertical list, the same logic applies along the other axis. If a text label is placed near that list, nothing fuses: visual nearness is not enough.
The model also avoids treating the temporary drag preview as a new kind of persistent group. Until the release commits, the document still contains the original arrangement. If the author moves away, the part can land as a separate object. This is a small example of a larger design principle in M3E Canvas: transient interaction state should help a person decide, while the saved document should record only the decision that was actually made.
Tidy regularizes the result without owning the design
The Tidy command operates at a broader scale. It is a rule-based layout transformation for one screen, not an AI that studies a canvas and invents a design rationale. Its rules begin by joining eligible neighboring runs. A pair of compatible button groups can fuse into one row, and adjacent list-item groups can fuse into one vertical list, provided their geometry and ordering meet the joining conditions. The command keeps the members in reading order and preserves the later layer position of the merged run, so joining does not silently change what the parts draw over.
After joining, Tidy assigns special components to their expected regions. A top app bar and a tab row belong at the top. A navigation bar belongs at the bottom. A toolbar or snackbar floats above the lower edge, a bottom sheet sits at the bottom, a FAB takes the lower-right position, and a dialog is centered. The command does not have to infer these roles from color or from a screenshot; they are component kinds with known layout responsibilities. This is why a component model is more useful than a set of rectangles: the same position can mean something different for a dialog and a list.
Everything that is not anchored is flowed into the body between those special regions. The body observes the screen's margins, rails, bars, and floating elements, then lays ordinary units out in rows. A row can contain one unit, several side-by-side units, or the common settings pattern of a label paired with a control. Wide units line up with the content margins; a narrow unit can remain left-aligned, centered, or right-aligned according to the relationship visible in the original placement. Tidy also supports different vertical intentions: the body can start from the top, sit in the center, gather toward the bottom, or spread its rows through the available height.
These choices are not a universal layout theory. They are a bounded grammar for common app screens. The tests in the repository illustrate the intended invariants: a top bar reaches the top edge, a navigation bar reaches the bottom edge, a FAB moves to the lower-right margin, neighboring buttons and list items join, and a second Tidy pass reports no change when the frame is already tidy. The point of such rules is not to claim that every screen has one correct arrangement. It is to make a common arrangement repeatable and explainable.
Locked groups complicate the screen in a productive way. A lock marks a finished section that Tidy must not merge, move, delete, or regroup. The rest of the body flows around the locked section instead of treating it as empty space. A locked app bar still reserves the height below it; a locked navigation rail still leaves room for content beside it; a locked card in the body becomes an obstacle that ordinary rows avoid. The author can therefore finish one region and continue arranging another without having to accept a whole-screen reflow every time.
This is where Tidy differs from a destructive “clean up everything” command. It has an explicit obstacle model. It preserves locked geometry and, where the document carries an intentional overlap or a free group, keeps that relationship together. If an author wants a badge to remain over an icon, or several elements to move with a container while retaining their offsets, grouping is the stronger signal than proximity. Tidy may regularize the screen around that unit, but it does not dissolve the unit into unrelated rows.
The layers panel exposes the structure that makes these decisions possible. It shows the frontmost group first, so the author can inspect which section is drawn above another. A connected run can be opened to reorder its members in reading order. A free group can be opened to reveal the runs it contains and then the members within those runs. This is not just an organizational sidebar. It gives the author a way to correct a result when the visual order is wrong without dragging every part through the canvas again.
Layer order also has a downstream consequence. The prompt compiler later uses containment, overlap, and group order to describe a box with parts layered inside it or one element drawn in front of another. If Tidy were allowed to flatten every spatial relationship, the prompt would lose information that a coding tool needs to reproduce the composition. By keeping free groups and z-order explicit, the editor preserves a path from manipulation to language.
Connected runs and free groups should therefore not be confused as two competing ways to organize the same thing. A connected run encodes regular adjacency. Its axis, member order, gap, and corner treatment describe a row or column that can be moved and, in bounded cases, extended. A free group encodes coordinated movement while leaving each member's offset intact. It is appropriate when the author has made a composition that should move as one but should not be reinterpreted as a regular run.
The distinction becomes important when a user asks for alignment. A selected connected run moves as a unit; a selected free group moves as a unit while retaining its internal geometry. When a selection is ungrouped, the editor can split the free group back into runs at their current positions. That preserves the current placement rather than snapping every part to a fresh default. The operation changes the convenience boundary, not the visual meaning the author has already established.
There are also limits to what Tidy can know. It can identify a top bar because the part is a top bar. It can see that two compatible runs are close enough and lined up. It can preserve a lock or an explicit group. It cannot know that a pair of buttons was intentionally separated to signal different levels of risk unless the separation exceeds its joining conditions or the author keeps the groups distinct. It cannot infer that a card is a special editorial callout rather than an ordinary content block from geometry alone. The safest response to an unusual intention is to encode it through grouping, locking, a note, or manual placement—not to hope that a general cleanup rule will discover it.
That boundary is not a failure of the feature; it is the condition that makes the feature trustworthy. Automation is useful when its trigger, scope, and escape route are legible. In M3E Canvas, the magnet works within a compatible nearby field, the guide aligns geometry without changing structure, and Tidy performs a named set of layout transformations. The author can override the live assistance, protect finished sections, inspect layers, and undo the operation. Those controls do not make the editor omniscient. They make its ignorance manageable.
The practical lesson is to decide which kind of help the screen needs. Use the magnet when a part should probably join a compatible row or list and you want the editor to make the movement feel natural. Use a guide when the relationship is alignment rather than membership. Use Tidy when the screen's component roles are settled and you want a repeatable reflow around bars, margins, and body rows. Use grouping and locks when the relationship is intentional but cannot be safely reconstructed from proximity.
M3E Canvas thus makes space behave by refusing to treat all spatial relationships as equivalent. Some are suggestions during a gesture; some are deterministic layout roles; some are author-owned structures that must be protected. That layered control is what allows the canvas to become more than a freehand board without pretending to understand an unrecorded rationale. The next test is harder: whether the same structured layout can survive a change from a phone screen to a wide screen, where component roles and available space may change together.