Repository navigation
Stop the Exit item flashing red, and grey packet capture instead of hiding it - #259
Merged
Merged
Conversation
…iding it Two menu fixes. Hovering File > Exit washed the row in red. A red background under the cursor reads as "something went wrong", not "this is destructive", and it fired on nothing more than passing over the item on the way somewhere else. It now uses the same neutral highlight every other item uses; the red icon still marks which item is the destructive one. A tool that cannot run is now shown greyed with the reason in its tooltip, rather than looking identical to one that can. Packet capture is the only such tool today: "Packet Capture needs Npcap/libpcap before it can run. Open for setup instructions." It stays clickable while greyed, which is deliberate. The pane behind it carries the setup instructions and the link to them, so an inert entry would remove the one place that explains how to fix what it is greyed for -- and removing the entry entirely is what the app used to do, which is how people ended up looking for packet capture, finding no trace of it, and no explanation either. Also splits the menu-item construction and the packet-capture message out of MenuBar.tsx and App.tsx, which were both at the size guard. One bug fixed on the way: the reason was computed only when a pcap tab was already active, so the menu entry would have greyed out only after you had opened the thing the entry is for. The menu asks whether the tool can run at all; Run asks whether this tab can run. They are different questions.
An independent acceptance pass blocked on this, and it was right. Discover merges probe replies with the OS neighbour table, and the core has always distinguished them: a probe reply means the host is there now, a neighbour entry means the OS spoke to it recently and it may since have left. The GUI dropped found_by while building rows and hardcoded the detail summary to "Responded host", so a host that answered nothing was reported as having replied. On this network that was 6 rows of 22. The truth sat one tab away in the raw view, which said "found_by": "neighbor" while the primary view said the opposite. PRODUCT.md exists partly to name this: "No wrong answers. The scanner never silently reports something false." design-direction.md's never-do is "present a result as certain when the underlying probe failed." This was both, on the primary path, shipped by the same change that added found_by to the core and never carried it any further. found_by now reaches the row, a "Found by" column shows "probe reply" or "neighbour table" without opening anything, and the summary reads "No probe reply; listed in the neighbour table, so it may have left". Also: an empty result no longer blames a filter. "No rows match the current filter" was printed whenever the table had no rows, so a scan that legitimately found nothing sent people hunting for a filter they had never set. With no filter it now says the run completed and found nothing. ux-walkthrough.md gains the column it should have described, and loses a row that contradicted itself: background-tab completion toasts cannot appear at the defaults the same table specifies.
fstubner
added a commit
that referenced
this pull request
Aug 28, 2026
Yes/No became ✓/– with a legend, and several cells that said No were wrong about why. The table presented four programs. Three of them are one binary: `netscli` with a command is the CLI, with no command it opens the terminal UI, and `netscli serve` starts the MCP server. Installing one installs all three. The page now says so before the table, because otherwise a dash in the MCP column reads as "you need another install for that", which is never true. "Setup and doctor" was one row for two different commands -- an interactive first-run wizard and a headless capability report that works on every build. Split. "ARP neighbor cache" was one row for reading the table and changing it. The MCP server can read it and deliberately cannot change it: that needs administrator rights and edits machine state. Split, with the reason. Two dashes that were really "not applicable" now say which: - Result bundles are the desktop app's save format. The CLI's `--json`, the TUI's `/export` and MCP's JSON-RPC results are the equivalent, not an absence -- so "Structured output" is a tick on all four and the row says what it means on each. - Reverse DNS over MCP works through `dns_lookup` with a PTR record; what is missing is the convenience of passing an address. Two are genuine gaps and are labelled as such: trace route has no MCP tool, and everything it needs is already in the core. The build-availability section said the desktop app hides tools whose feature is absent. It greys Packet Capture with an explanation instead, since #259 -- a tool that vanishes leaves nowhere to say why. Verified from the built page: 19 rows, ticks and dashes rendering, legend present, table still inside its horizontal scroll wrapper with no page overflow at 500px or 1440px. astro check 0 errors, a11y 0 violations.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two menu fixes from using the app.
Red hover on File ▸ Exit
.menu-popover-item.danger:hoverwashed the row in an 18% red tint. A red background under the cursor reads as something went wrong, not this is destructive, and it fired on nothing more than passing over the item on the way elsewhere. It now uses the same neutral highlight every other item uses; the red icon still marks which item is destructive.Exit is the only
dangeritem, so this is the whole blast radius.Packet capture: greyed with a reason, not identical to a working tool
An unavailable tool now renders greyed with the reason in its tooltip:
It stays clickable while greyed, deliberately. The pane behind it (
PcapUnavailableState) carries the setup instructions and an "Open setup docs" link, so a genuinely inert entry would remove the one place that explains how to fix what it is greyed for. Removing the entry outright is what the app used to do — the comment inuseTauriRuntimeState.tsrecords that people went looking for packet capture, "found no trace of it, and no explanation of why".If you'd rather it were fully non-interactive, say so and I'll move the setup guidance somewhere reachable first — the two have to move together.
A bug found while wiring it
pcapUnavailableReasonwas computed asactiveTab?.kind === 'pcap' && !available, i.e. only while a pcap tab was already open. Used for the menu, that would have greyed the entry only after you opened the thing the entry is for. Split into two values: the menu asks whether the tool can run at all, Run asks whether this tab can run.Verified
toolItemFactoryhas 4 unit tests (148 total). The greyed state was observed in a throwaway build with the capability forced off — Packet Capture muted with the tooltip, the other five entries untouched — then that patch was reverted.MenuBar.tsxandApp.tsxwere both at the size guard, so the menu-item construction and the packet-capture message moved into their own modules.Not addressed here
You also reported the settings window not being centred. I could not reproduce it: measured on
mainand on your installed build at 1000×700, 1280×800, 1920×1080, 2560×1400, 1000×560 and 900×500 — vertical and horizontal deltas were 0 at every size. Asking rather than guessing.