Add first-party GUI frontend and retire Zenity brightness dialog

[Staphylococcus]

Problem statement

LG Buddy currently exposes its only graphical control through zenity: lg-buddy brightness opens a small brightness slider dialog. The installer treats zenity as a hard prerequisite even though core lifecycle, sleep/wake, screen monitoring, and TV automation do not require it.

That is too narrow for the project direction. LG Buddy should eventually be usable without terminal commands or config-file editing. Removing zenity therefore should not mean simply dropping the brightness dialog; it should be replaced by a first-party frontend that can grow into the normal user-facing configuration and control surface.

Goals

• Remove zenity as a runtime/install dependency.
• Provide an alternative graphical frontend for brightness control.
• Establish a frontend foundation that can later support setup, configuration, status, and diagnostics.
• Keep runtime policy and side effects in the Rust backend, not in the GUI layer.
• Choose the frontend framework based on the broader control surface, not just a one-slider replacement.

Non-goals

• Do not add a long-lived collection of dialog-tool backends such as zenity, kdialog, and yad.
• Do not move lifecycle or screen policy into the frontend.
• Do not require config-file editing for normal GUI-managed settings once the frontend covers them.

Frontend scope to evaluate

The initial replacement can be small, but framework choice should account for the likely future surface:

• brightness get/set
• TV pairing state and repair/re-pair flow after native webOS support lands
• TV reachability and current input/status
• HDMI input selection
• idle timeout and screen restore policy
• screen backend status
• lifecycle automation status
• service/status diagnostics
• logs or troubleshooting export

The immediate deliverable may only cover brightness, but the design should not corner us into a toolkit that is unsuitable for the broader control center.

Backend/API implications

The GUI should consume stable LG Buddy-owned backend surfaces rather than reimplementing behavior.

Possible staged path:

1. Add non-GUI CLI/API operations for brightness, e.g. lg-buddy brightness get and lg-buddy brightness set <0-100>.
2. Make config updates available through Rust-owned commands/API rather than only configure.sh.
3. Add structured status/diagnostics output that a GUI can consume.
4. Build the GUI on top of those surfaces.

Longer term, a local service API may be cleaner than shelling out from the GUI for every operation, but the first step should keep the backend/runtime ownership clear.

Dependencies

This should follow #20 for any TV-pairing or native TV status work. Brightness-only GUI work can start earlier if it stays compatible with the current TvClient abstraction, but full frontend setup/status work should assume the native webOS client exists.

Testing scope

• backend tests for any new structured brightness/config/status commands
• GUI-facing command output should be stable enough to consume from tests
• installer/release smoke tests should stop requiring zenity
• installed desktop entry should launch the new frontend instead of lg-buddy brightness through zenity

Packaging implications

This issue is a prerequisite for reliable .deb/.rpm packaging: packages should not require zenity just to install LG Buddy, and the user-facing GUI should be part of the packaged experience.

---

Migrated from #27 before repository ownership transfer.
Original issue: #27
Original author: @Staphylococcus
Original created: 2026-04-30T17:47:29Z
Original comments at migration time: none.