Styling one file type

Everything in the editor can be set twice: once for every file, and once for a particular kind of file. That second setting is what turns the graph into something you can read.

The scope selector#

A single dropdown sits in the Nodes tab, below the style bar and the apply buttons, and it decides what you are editing — not what you are looking at. Every control below it follows the choice.

All files is the base. Editing here changes every node that hasn't been given something more specific. The banner underneath reads editing All files · the base for every node.

A file extension — .ts, .rs, .json — narrows the edit to files of that type. The banner changes to editing .ts · inherits All files, which is the whole model in three words.

An exact filename covers files that have no useful extension. The list is short and fixed: .gitignore, .dockerignore, and the Semantix binaries. It exists for dotfiles, not as a general per-file mechanism.

The extension list is partly built from the graph you're currently looking at, so it grows to include whatever your project actually contains rather than offering a fixed menu.

Note

Those are the only two levels there are. There is no styling a single node, and no styling a folder or a path. The graph can be made to distinguish kinds of file, not individual files.

Overrides are sparse#

When you change one slider with .ts selected, that one value is stored for .ts. Nothing else is.

This matters more than it sounds. Everything you did not touch keeps inheriting from All files — so you can give .ts a hexagonal shape today, change the base metalness next week, and your TypeScript files pick up the new metal while staying hexagonal. An override is a short list of differences, not a copy of the whole look.

Reading the dots#

A ● in front of something means this is set here, rather than inherited.

In the dropdown, a dot marks a file type that carries at least one override — a quick way to see which types you've already touched.
On a knob label, a dot marks a value that belongs to the type you're editing rather than coming down from the base.

There is no per-knob "put this one back". The available undo is one level coarser: see below.

The rule that will catch you#

Exact-filename scopes and extension scopes do not blend. If a file matches an exact-name override, its extension override is not consulted at all.

Say you give every .ts file a hexagon and a glow, then separately set index.ts to be purple. Your index.ts will be purple — and it will be a shield with no glow, because the moment the name rule matched, the extension rule stopped applying. It doesn't take the hexagon and add purple; it takes the base and adds purple.

This is only a two-level cascade: base, then one override. Not base, then extension, then name.

Note

The glyph icon is the one exception. Unlike everything else, it does fall through: a file with a name override but no icon of its own still picks up the icon set for its extension. So in the example above, index.ts ends up a purple shield with no glow — still wearing the TypeScript icon you chose.

Clearing a type#

When the selected type has overrides, a small reset type button appears in the banner, tooltip Clear all .ts overrides → back to All files. It drops everything set for that type in one go — no confirmation — and those files go back to inheriting the base.

To clear everything, for every type, the Reset button in the apply bar does that as part of restoring the factory look. It is not a gentle button: see the warning on the overview.

Two small behaviours#

The scope survives switching between the Nodes and Physics tabs, so you don't lose your place. It resets to All files when the window is closed and reopened.

The preview pane follows the scope too — it renders a stand-in file of whatever type you're editing, so what you see is that type's effective look, base plus override, and not the base alone.

As everywhere else, nothing lands in the graph until Apply.