Skip to content

v2.3.0 - Keyboard access for the Windows GUI, frames and descriptions for the TUI

Latest

Choose a tag to compare

@ChaoticSi1ence ChaoticSi1ence released this 06 Sep 14:13
510689e

Two things this release: the Windows GUI works without a mouse, and the Linux/macOS TUI explains every policy the way the GUI has since v2.2.0 — in a boxed pane, with frames around the list and the buttons.

No policy changes. Same 79 policies over the same 75 keys; nothing about what gets written to your registry or policy file moved. One description was reworded so it stops naming the registry on Linux and macOS.

Windows: keyboard access

v2.2.0 disclosed it: every control in the Fluent window was owner-drawn and could not take focus, so the GUI was unusable without a mouse. Now:

Key Does
Tab / Shift+Tab Sidebar → search → list → buttons, and round again
Space / Enter Press whatever has focus — on release, so a held key acts once
Right / Left Open / close a row's description
Home / End / PageUp / PageDown Walk the list
Escape Clear the search; otherwise close, asking first if you have staged changes you have not applied

A dotted outline marks the focused control, and it appears only once the keyboard moves focus, so a mouse session looks as it did. Keyboard activation goes through the same handler the mouse uses, so the two cannot drift apart.

One crash, never reproduced, made harmless. During testing the window once ended in .NET's "Unhandled exception" dialog from the DNS template box — an error that should have been a line in the console. Seven attempts to reproduce it failed. What was proven instead: a handler error turns into that dialog only while a PowerShell try block is active up the chain, and two handlers had UI work inside one. The tool now catches an escaped handler error and prints one line instead of ending the process, that handler catches its own, and the two try blocks were narrowed. If you ever see a red line starting SlimBrave Neo: in the console, please open an issue with what you did just before.

Linux and macOS: frames and a description pane

The TUI never had the descriptions — the Python tables did not hold the text. The 79 descriptions from the Windows script are now in both scripts, and a test pins each one to the Windows wording, so the three scripts explain a policy identically.

The screen is three boxes: the list, a Description pane under it, and the buttons. The pane shows whatever the cursor is on — a setting, a section's live count and its folding keys, the DNS mode and template, or what the focused button does. d shows or hides it. It starts shown wherever it fits, steps aside on its own when the list would drop under four rows, and takes as many lines as the longest description needs at your terminal's width, up to four; one that still does not fit ends in an ellipsis. Unicode box lines, with the same +-| fallback the fold markers use on a terminal that cannot show them; under nine rows the frames go and the old layout returns.

New in CI: a job runs the actual script inside tmux on Ubuntu and macOS, sends keys, and reads the screen back — under a UTF-8 locale and under C. The README's TUI screenshot is new.

Verifying this release

de3e6e483ff9adf356668a8db488cc7d0d52cfd2cced7f90b8adcb20f386be51  SlimBrave.ps1
60e2dfe846986b1c4ff5b1bba6726deb82fd12ab88a62f836a69ca2c3b7704eb  slimbrave-linux.py
dd883e88343e2568e8f1b1e46444ef418075034824239ee53255da612b24a9ec  slimbrave-mac.py
Get-FileHash -Algorithm SHA256 .\SlimBrave.ps1
sha256sum slimbrave-linux.py     # Linux
shasum -a 256 slimbrave-mac.py   # macOS

These are the bytes GitHub serves, checked against the raw URL before publishing.