gui: Add optional graphical interface - #65
BenWestgate wants to merge 3 commits into
Conversation
Add the GTK/libadwaita frontend as an optional package and entry point. The GUI delegates codex32 operations to the existing library, keeps Bitcoin Core integration behind one adapter module, and packages its desktop identity and Codex32 Book artwork. Keep PyGObject in the gui extra so the base installation retains its existing runtime dependency boundary. Recovery and wallet secrets remain inside the documented GUI/Core boundaries. Validation: exercised by the complete pytest and optimized pytest suites, mypy, Ruff, package build/twine checks, and the Xvfb GUI walkthrough on the final stack.
Add toolkit-free tests for entry interpretation and Bitcoin Core orchestration, static checks for the GUI security boundary, and an Xvfb walkthrough that exercises every user task. The boundary tests keep GUI entropy, persistence, networking, and Core access constrained to the documented surfaces and enforce the GUI review-line budget. Validation: 107 focused GUI tests and the full Xvfb walkthrough pass; the complete and optimized suites each pass 974 tests, and GUI mypy and Ruff checks pass.
Document installation and use of the optional GUI, its review boundaries, Bitcoin Core passphrase and wallet-creation departures, and the corresponding security model and API map. Keep the GUI review budget synchronized with its boundary test and the current v1 library budget. Validation: reviewed the rebased diff against reviewability-v1 and verified the built wheel contains the GUI package data, desktop file, and launcher icon.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d6dfa816f6
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| "Wallet", | ||
| content, | ||
| actions=_actions( | ||
| _button("Check again", lambda: _wallets(view, core, secret, timestamp)), |
There was a problem hiding this comment.
Preserve restore mode when refreshing wallets
When a restore user clicks Check again, this callback omits restoring=restoring, so _wallets defaults the refreshed flow to creation mode. After import, _finished_page consequently shows “Your wallet is ready” and a new approximate creation date instead of asking the user to compare the restored wallet against the existing record; copying that date could overwrite the wallet's original recovery metadata.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Confirmed. This is a real bug on the standalone #65 head. The stacked follow-up #66 removes the manual Check again transition entirely and replaces it with in-page polling, so there is no refresh callback left that can drop restoring. I’m keeping this thread open on #65 rather than claiming the parent is independently fixed; review/integration order is #65 then #66, and the GUI integration candidate must include both before qualification.
Add an optional GTK/libadwaita graphical interface for the existing codex32 master-seed workflows.
The GUI uses the existing codex32 library rather than reimplementing domain logic;
src/codex32/is unchanged. PyGObject remains optional, and Bitcoin Core access from the GUI is confined tocodex32_gui/wallet_setup.py.The three-commit stack separates the GUI implementation, tests/security boundaries, and documentation for easier review.
Integration note: do not merge this parent as the final GUI candidate by itself. The standalone #65 head has a reviewed restore-mode bug in the manual Check again refresh path. Stacked PR #66 removes that manual transition entirely and replaces it with serialized in-page wallet polling, which eliminates the mode-dropping path. Review order is #65 then #66; the frozen GUI integration candidate must contain both before final qualification/adversarial review.
Validation on #65 includes the full and optimized test suites, focused GUI tests, the Xvfb GUI walkthrough, mypy, Ruff, package build, and Twine checks. The current #65 Python-package workflow is green; #66 is separately green on top.