wifui

The Problem

On Windows machines many users rely on the GUI to manage Wi‑Fi, which forces them out of a terminal‑centric workflow. Switching between a terminal and the network settings UI adds friction for developers, sysadmins, or anyone who prefers keyboard‑only interaction.

What This Does

wifui implements a keyboard‑driven TUI that scans, connects to, and manages Wi‑Fi networks without leaving the console. The core logic lives in the src/ tree:

• src/main.rs – parses CLI flags (--ascii, --show‑keys) and builds an App instance.
• src/app.rs – owns the main state machine (AppState, UiState, ConnectionState) and drives UI refreshes.
• src/event/mod.rs exposes run() which processes input events and dispatches to the handlers in src/event/handlers.rs.
• Wi‑Fi operations are wrapped in src/wifi/handle.rs (WlanHandle, as_raw, get_interface_guid) and src/wifi/connection.rs (connect_profile, disconnect).
• UI rendering is in src/ui.rs (render, display_auth_name).

The program is built with Cargo (Cargo.toml) and distributed via winget, Scoop, Chocolatey, and crates.io.

How It Is Wired

Execution starts at main in src/main.rs:45. After argument parsing it creates an App (App::new) and immediately calls run from src/event/mod.rs:38. run registers a terminal event loop and forwards each keystroke to the appropriate handler in src/event/handlers.rs (e.g., handle_main_view, handle_manual_add_popup).

Key pathways:

• UI refreshes: App::draw → ui::render → ratatui drawing calls.
• Network scanning: wifi::scanning::get_wifi_networks → wifi::handle::as_raw (called from 13 places) → Windows WLAN API.
• Connection flow: event::handlers::handle_main_view → wifi::connection::connect_profile (called from 3 places) → wifi::profile::create_profile_xml → wifi::profile::write_element.

The most‑used internal functions are:

These hubs give a high “blast radius”: changing as_raw or get_interface_guid impacts many UI and event paths. No circular import edges were detected, but deep nesting (max indentation depth 8) appears in src/app.rs, src/event/handlers.rs, and src/event/mod.rs, making the control flow harder to follow. The UI module (src/ui.rs) contains 920 lines, a single point of responsibility that would benefit from being split into logical sub‑components (e.g., status bar, network list, pop‑ups).

How To Use It

# Clone the exact upstream repository
git clone https://github.com/moses-y/wifui
cd wifui

# Build and install locally
cargo install --path .

# Run the TUI
wifui               # default UI (requires Nerd Fonts)
wifui --ascii       # ASCII‑only mode
wifui --show-keys   # show raw key logger for debugging

No additional configuration files are required; the program reads the current Windows WLAN profile store directly via the WlanHandle wrapper.

Real‑World Use

A DevOps engineer can embed wifui in a remote PowerShell session to quickly switch between corporate and guest Wi‑Fi without leaving the terminal. Example workflow:

ssh user@build‑agent
wifui                # scan, select, connect
# continue with build commands

The TUI’s Vim‑style navigation aligns with typical console tooling, reducing context switches.

Code Health & Issues

• High – Add a test suite – 16 source files, no test files.
• Medium – Enable Dependabot – only Cargo.toml present, no bot config.
• Medium – Dependency‑vulnerability gate – CI workflow (.github/workflows/release.yml) lacks a scan step.
• Low – Set timeout‑minutes – workflow jobs have no explicit timeout, risking runaway runs.

• High – Deep nesting – src/app.rs, src/event/handlers.rs, src/event/mod.rs each have indentation depth 8.
• Medium – Duplicated code – 6‑line block repeated in src/event/mod.rs and src/main.rs.
• Medium – Oversized UI file – src/ui.rs spans 920 lines, making localized changes risky.

No tests, no automated dependency updates, and no CI timeout controls currently limit maintainability.

The Bottom Line

wifui delivers a functional, keyboard‑centric Wi‑Fi manager for Windows, with a clear separation between UI, event handling, and Windows API wrappers. However, the codebase suffers from deep nesting, a monolithic UI module, and a complete lack of automated tests or dependency‑health checks. It is suitable for users who need a quick terminal tool and are comfortable working around the identified maintainability constraints; contributors should prioritize adding tests, refactoring the UI, and tightening CI before extending the feature set.