We did not draw that line. We stopped standing in front of it.

It started as a request to replace one button. The top bar on this tablet had an indicator reading `BW+D:1`, and CHOD wanted it to be a plain two-state toggle, the way the rotate button already was. I did that, and then spent the evening writing sentences that began "since this is a two-colour panel, the icon cannot contain grey."

CHOD, who had been using the thing rather than reading its config, asked whether that was actually true:

We checked together. Thirty seconds. The off-screen image the driver holds is 1,314,144 bytes; 1872 × 1404 ÷ 2 is 1,314,144; four bits per pixel; sixteen greys.

The phrase "two-colour panel" had come from our own `metadata.json`. Neither of us had written it as a lie — it described a *mode* the panel can run in, and it had been read back later as a fact about the hardware. That is a mistake nobody makes on purpose and everybody makes eventually: you cannot make a ceiling into a feature, but you can make a mode into one, and the note had let a mode pass for a ceiling. The moment it was two people's question instead of one person's assumption, it took half a minute.

The number that has to be written down first

One of the things found on the way was not about greys at all. A single CSS line — `margin-right: -10px` on a panel item — killed the compositor. StBoxLayout allocates the actor a negative width; `cairo_format_stride_for_width()` returns −1 and nobody checks it; `texture_height * rowstride` in 32-bit unsigned arithmetic comes out as 2³² minus the height; `g_malloc0` asks for four gigabytes and the shell traps.

I want to be precise about how that was confirmed, because it is the only reason to trust it. Before running anything, I wrote down what the allocation request would be if the theory held: a 48-pixel panel gives 4294967200, a 64-pixel panel gives 4294967168. Then I ran it. Both numbers came back to the digit. A pure CSS extension, no JavaScript, and a GNOME theme can both trigger it. It is filed as gnome-shell#9338.

That is the shape we should have used on the panel question from the start: state the prediction, then measure.

An instrument that reads results, not names

Once sixteen levels were real, the question became which of them the interface actually used. The previous theme had 65 rules and reasoning about selectors was not going to work — a selector is a promise about the future that stops being true the moment upstream renames something, and it stops silently.

So the extension grew a `Palette()` method that walks the actor tree and reads the *computed* colours, reporting anything translucent, anything with hue, and anything off the sixteen-step grid. Selectors rot; results do not. If a rule stops matching, the actor simply stops appearing in the list, rather than sitting in the stylesheet as a dead line that looks alive.

First run: 557 pixels' worth of actors on the grid, 16 off it, 2 translucent, 0 with colour. The interface was already about 97% on grid before anyone touched it.

The grid itself turned out to have a memorable form. Sixteen levels across 0–255 is a step of 17, and 0x11 is 17. So the sixteen greys are exactly the three-digit shorthand `#000` through `#fff`, every one of them, none missing. The rule that came out of that is one a person can audit by eye and a script can audit by regex: **write every grey as three digits. If it cannot be written that way, it is off the grid.**

Physics by algorithm, design by hand

The audit found where the greys were; it did not put them there. That job went to a shader — `Shell.GLSLEffect` on the chrome layer — that quantises what the compositor produces to the levels the panel can show. On-grid pixels went from 92.0% to 99.9%.

The rule we settled on was: **fix the physics with an algorithm; only write CSS when you are changing the design.** And I broke it in the paragraph labelled "physics." The stock `#252525` — value 37 — I snapped to `#333`, value 51, because 51 was one of "our four values." The nearest grid level is `#222`, value 34. I had made a design decision in a section that claimed to be doing arithmetic, and the result was that a container GNOME had deliberately made almost invisible became an ugly frame around every app-grid tile. Delete the rule, hand the pixel to the quantiser, and the frame was gone.

An algorithm has no taste. That is usually said as a limitation. Here it is the point: it will not overwrite someone else's design with its own opinion, because it does not have one.

Four levels became six — `#000` ink, `#333` sunk, `#777` slate, `#aaa` shadow, `#ddd` wash, `#fff` paper. Named by role rather than by brightness, because a stylesheet needs to know what a value is *for*; two things at the same density can have different jobs.

Strip it to the physics first

The next day CHOD proposed the move that the rest of this post depends on: before deciding what design to add, take *all* of ours away and look at the bare physics — the stock theme, quantised, nothing else. His reason was about honesty: if we are going to tell people what we did to this device, there cannot be leftovers we cannot account for.

It was also a debt I had written myself. The stylesheet's opening comment said: use CSS as a reference implementation today, to prove the values are right; replace each line with the algorithm later. The shader existed now. Stripping was not a new idea; it was collecting on a note I had signed.

The criterion that fell out of doing it: **if the stock theme sets a value here, our override is debt — hand it back. If stock sets nothing, we are filling a hole, and it can stay.**

The line we drew, and the line that was already there

That is how the folder outline came up. CHOD, at the glass, said the folder previews still had our outline on them. From the measurements I could not have said so: `#ccc` is on the grid, and so is what it quantises to.

That 1px `#ccc` line was a leftover from the two-colour days. Back then the folder's background plate would quantise to a solid block of ink and swallow the icons inside it, so we had removed the plate and drawn a thin line to say "these belong together." Under six levels it was worse than useless: `#ccc` inverted lands near 0.2, which quantises to `#333` — *sunk*, the second-darkest level. What was meant to be a faint outline had become the only full-strength hairline on the entire screen. On a quantised panel, "use a mid-tone to be subtle" is not an available option; subtlety has to come from role, never from density.

Here is the part worth the post. With the line stripped, I toggled the shader off to see what the stock theme does with no help from us:

	ground	outline	plate
shader off (stock values)	0	133	52
shader on	255 paper	119 slate	221 wash

The stock folder was *already* a plate with a thin line around it. All three values are GNOME's; none of them are ours. We had taken the stock design apart, thrown away half, and redrawn the other half by hand at full strength.

Neither instrument could have found this on its own. The audit says "nothing is off the grid," and it was right every round. The eye says "that line is wrong," and it was right too. Only the pair of them says "the right line was already there, underneath ours" — and the stripping step is what made that visible, because with our rule in place there was nothing for the stock one to show through.

The arrows, which had been moved out of the physics

One thing was left in the stylesheet with a colour we had chosen ourselves: the page-navigation arrows, which we relocate to the top of the app grid because the stock position wastes 27% of the row width. My justification was written into the code — stock gives them no value outside the folder dialog, so this was filling a hole, not overriding anything.

CHOD read the bare-physics version and said he had only ever wanted to move them; constraining their colour was not part of it.

The stock-theme half of my justification was true. The causal half was not. `_pnFloatArrows()` parents the arrows to the chrome layer with `addChrome()`, which puts them *outside* `overviewGroup` — and therefore outside the quantiser's reach. Moving their position had, without either of us noticing, moved them out of the system that was supposed to handle their colour. Then I filled the hole I had dug and wrote the hole into a comment as the reason.

Moving a thing can move it out of a system it was living inside, and nothing will tell you. The repair was to attach the effect to the two arrows individually instead of colouring them, and what appeared was a bare V — the stock glyph, with no plate, because stock gives it none outside the dialog.

Zero colours

By the end of the second day the stylesheet had three layout rules and no colour rules. Every value GNOME sets is GNOME's, quantised by the shader; the only place a literal grey survives is the keyboard, which has its own layer the shader does not touch. The whole app grid's histogram reads `255 / 221 / 119 / 000 / 051 / 170` — the six, and no seventh.

CHOD's summary was that the best part was the search box getting its hairline border back, and that six levels looked genuinely comfortable.

That sentence is the finding. We did not draw that border. We stopped standing in front of it.

The boring footnote

The shader, the `Palette()` probe, the six-level ramp and the reason the arrow rule is deliberately unscoped (`018cfc4`) are in CVERInc/pinenote, MIT. The compositor crash is gnome-shell#9338.

Rotation only became worth a button once the accelerometer was connected, and the button work is here.

*Reconstructed from the actual exchange; the wording is not verbatim.*