[CGH0S7]

Description

This PR introduces pbpctui, a new crate in the workspace providing a TUI (Terminal User Interface) for interacting with the Pixel Buds Pro.

It serves as a visual wrapper around the pbpctrl CLI, allowing users to monitor device status and adjust settings in a more interactive way.

Features

• Status Dashboard: Real-time view of:
  • Connection status (Local/Remote peer)
  • Battery levels (Left, Right, Case) & Charging status
  • Firmware versions & Serial numbers
• Settings Editor: Interactive controls for:
  • ANC Modes: Off, Active, Adaptive, Aware
  • Audio: 5-band EQ, Volume Balance, Mono Audio
  • Smart Features: Multipoint, In-Ear Detection (OHD), Speech Detection
  • System: Touch Controls, Diagnostics, Volume Notifications

Implementation Details

• Built with ratatui and crossterm for the UI.
• Uses tokio for async runtime and process management.
• Acts as a frontend that spawns pbpctrl subprocesses to fetch data (show ...) and apply settings (set ...).
• Polling mechanism to keep status updated.

Dependencies

• ratatui
• crossterm
• tokio
• anyhow
• regex

Usage

cargo run -p pbpctui

or install:

cargo install --path tui
pbpctui

Additional Changes

• Dependency Update: Upgraded the bluer crate to a newer version to align with recent BlueZ changes and reduce the risk of future incompatibilities.
  • No behavior changes intended.
  • Existing APIs used by pbpctrl / pbpctui remain compatible.

[CGH0S7]

Screenshots:

[qzed]

Thanks for the PR, it's a nice idea.

I have a couple of notes: I think it would be better to not call the binary but use libmaestro directly. That doesn't require the pbpctrl binary to be at a specific path and also gives you more direct control. Specifically, it would allow you to use

pbpctrl/libmaestro/src/service/impls/maestro.rs

Line 107 in 2620367

pub fn subscribe_to_settings_changes(&mut self) -> Result<StreamResponse<SettingsRsp>, Error> {

which allows you to update display values when settings have changed externally (either other app or through gestures).

[CGH0S7]

Thanks for the review and the positive feedback!

Using libmaestro directly is a cleaner design and avoids the dependency on the pbpctrl binary path. I initially went with spawning the CLI to keep the first version simple and decoupled, but I agree that integrating with libmaestro is the better long-term approach.

I’ll look into refactoring pbpctui to use libmaestro directly and see how best to structure the async event handling around the settings stream. This may take a bit of rework, but I think it’s worth doing properly.

Thanks again for the suggestion and for pointing me to the relevant API. I'll update the PR once the changes are ready.

[CGH0S7]

Hi, I've completed the refactoring as we discussed. Here’s a summary of the changes:

• Direct Integration: pbpctui now uses libmaestro directly instead of spawning pbpctrl as a subprocess.

• Real-time Updates: I’ve implemented the subscribe_to_settings_changes API as you suggested. The UI now stays in sync with external changes in real-time.

• Stability & Testing: I’ve been using and testing this version for a while now. Most initial bugs and edge cases have been resolved, and it feels stable for daily use.

• Conflict Resolution: I have also resolved the merge conflicts with the latest main branch.

[CGH0S7]

Fixed unused_assignments warnings in maestro_client.rs. Sorry for the oversight—I was using a nightly toolchain and didn't see these warnings until I switched back to stable.