A way to opt out of highlighting on informational rows

[franrich-cyber]

#538 notes that actionless coloured rows remain enabled and highlightable by design. I would like to make the case for an opt-out, and I want to be upfront that I can see why the current behaviour exists.

The trade-off as I understand it

The obvious way to stop a row from highlighting is to disable the menu item. But AppKit greys out disabled items, which would destroy the custom color= that these rows are usually there to display. Keeping them enabled preserves the colour. That is a reasonable call, and I suspect it is exactly why it works this way.

So this is not a request to disable those rows. It is a request for a way to say "this row is text, not a control", while keeping its colour.

Why it matters from a plugin author's point of view

Most SwiftBar plugins use plain rows as content, not as controls: statistics, counters, section bodies, status lines. In my case a menu has four such rows under a bold section heading, all displaying numbers.

On 2.0.1 those rows were visually inert. A user moving the pointer down the menu could tell at a glance which rows did something and which did not, because only the actionable ones lit up. On 2.1.2 every row lights up identically, so the highlight no longer carries that information. The rows invite a click that does nothing.

This also departs from the macOS convention users bring with them: in a system menu, a row that highlights is a row that acts.

What I am asking for

A per-row way to mark a row as informational. Something like:

echo "Cette semaine: 40 PDFs (100 pages) | color=#1f3d7a inert=true"

where the row keeps its custom colour but does not highlight and does not respond to the pointer.

If a per-row parameter is too narrow, inferring it would cover most cases: a row with no bash=, no href=, no shortcut= and no submenu has nothing to do when clicked. That was effectively the 2.0.1 behaviour. A global preference would also work.

I recognise this is more subjective than the other points I have raised, and I am not asking for the previous behaviour to be restored unilaterally — several plugins may well look better with uniform highlighting. An opt-out would let both exist.

Context

• SwiftBar 2.1.2 (build 604), macOS Tahoe 26.5.2 (build 25F84), MacBook Air M1
• Compared against SwiftBar 2.0.1, same machine, same plugins
• Related: 2.1.2 beta 2: three menu rendering regressions - multi-line title alignment next to image=, highlight and color= loss on non-actionable rows, sfsize= ignored and larger default sfimage= size #533, fix(menu): correct inline image alignment and hover redraw #538

[thealinamichelle]

I just want to add that this also helps the information render and allow the user to build information with accessibility in mind. The greyed out text is difficult to read, and adding color / contrast improves readability for informational rows that have important context.