Skip to content

Highlight the objects one hop from the selection - #9

Merged
pakdekro merged 2 commits into
mainfrom
feat/8-highlight-neighbours
Aug 18, 2026
Merged

Highlight the objects one hop from the selection#9
pakdekro merged 2 commits into
mainfrom
feat/8-highlight-neighbours

Conversation

@pakdekro

Copy link
Copy Markdown
Owner

Closes #8.

What it does

Selecting an object rings what it is directly connected to, brings the relationships it is an end of forward, and steps everything else back. It works whatever arrangement the canvas is currently in, which is the point: the layout no longer has to carry the structure.

Why it is a mode, off by default

Ringing the neighbours on every selection sounds free and is not. Selecting is also how you pick an object up to move it, so rearranging a canvas meant the whole thing dimming and undimming under the cursor at every click. A signal that fires when nobody asked a question stops being a signal.

So it is reached by l for links, or by a toolbar toggle, and it starts off. When it is off the canvas behaves exactly as it did before.

A mode with no visible state is a trap, so this one announces itself twice: the toolbar button latches in the colour of what it switches on, and the toggle says so out loud for the times it was reached by the keyboard. It is in the shortcuts sheet and in the command palette too.

Choices worth arguing with

  • A second colour rather than a thinner ring of the accent. It has to read as "related to", never as "also selected".
  • 3px and a halo. Two pixels of a quiet hue read as a rendering artefact and the eye went straight past the answer; this was tried on a real 31-object investigation before it was settled.
  • The unrelated objects go to 45%, not the 20% the search uses. A search is a question about the whole canvas and answers it by elimination. Selecting is an everyday gesture, and dimming that hard on every click would be a light show.
  • Edges faded, never hidden. An edge that vanishes while an object is selected reads as an edge that was deleted.
  • Derived from React Flow's own selection, on the model of the search highlight right above it, so there is no second copy of the selection to disagree with the first. When a search is running its verdict keeps the opacity and the ring is added on top: a neighbour the search rejected must not come back from the dead.

Verified in the browser

On a real 31-object, 37-relationship investigation: selection with the mode off changes nothing; l rings 5 neighbours, dims 25 objects and brings 5 relationships forward; l again undoes it; the toolbar button does the same; and typing l in a text field writes an l instead of toggling.

509 tests, tsc clean.

pakdekro and others added 2 commits August 18, 2026 22:33
A CTI graph is a star and no automatic layout makes one readable; that
was measured, at length, and it is why the re-layout became a menu of
arrangements instead. What does make a star readable is asking it rather
than drawing it: select an object and what it touches lights up, wherever
the arrangement happened to put it.

Neighbours take a 3px ring plus a halo, in a second canvas colour named
`--linked`. A different hue rather than a thinner ring of the accent,
because it has to read as "related to" and never as "also selected"; and
three pixels rather than two, because two of a quiet hue read as a
rendering artefact and the eye went straight past the answer.

Everything the selection does not touch steps back to 45%, which is what
makes the ring land at a glance. Not the 20% the search uses: a search is
a question about the whole canvas and answers it by elimination, whereas
selecting is also the everyday way to open the inspector, and dimming
that hard on every click would turn an ordinary gesture into a light
show.

The relationships the selection is an end of come forward in the same
colour while the others go to 15% - the ring says which objects, only the
edge says which link, and thirty-five other edges cross that answer.
Faded, not hidden: an edge that vanishes while an object is selected
reads as an edge that was deleted.

Derived from React Flow's own selection rather than kept in state, on the
model of the search highlight right above it, so there is no second copy
to disagree. When a search is running its verdict keeps the opacity and
the ring is added on top: a neighbour the search rejected must not come
back from the dead.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Ringing the neighbours on every selection sounds free and is not.
Selecting is also how you pick an object up to move it, so rearranging a
canvas meant the whole thing dimmed and undimmed under the cursor at
every click. A signal that fires when nobody asked a question stops being
a signal.

So it is a mode now, reached by "l" for links or by a toolbar toggle, and
it starts off. When it is off the canvas behaves exactly as it did before
the highlight existed.

A mode with no visible state is a trap, so this one announces itself
twice: the toolbar button latches in the colour of what it switches on,
and the toggle says so out loud for the times it was reached by the
keyboard. It is also in the shortcuts sheet and in the command palette,
whose entry names the direction it will go rather than the mode it is in.

The key is a bare letter, guarded like "/" is: pressing "l" while writing
in a field types an l.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@pakdekro
pakdekro merged commit e0d80f6 into main Aug 18, 2026
3 checks passed
@pakdekro
pakdekro deleted the feat/8-highlight-neighbours branch August 18, 2026 20:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Highlight the objects one hop from the selection

1 participant