SAFE21.io/bal-electrum-plugin
1
0
Fork 0
forked from bitcoinafterlife/bal-electrum-plugin
Code Pull Requests Activity

v0.5.1: update changelog

Browse Source
This commit is contained in:
donkey-ai
2026-07-04 08:13:15 +00:00
parent 346164207f
commit 3a3dca0c2e
1 changed files with 45 additions and 241 deletions
Download Patch File Download Diff File Expand all files Collapse all files

286
CHANGELOG.md
View File

@@ -1544,256 +1544,60 @@ confirms the ZIP works).
--- ---
## 26. v0.5.1 - Dynamic Check Alive in BASIC mode + Windows dialog-flicker fix ## 25. v0.5.1 - Fix Windows Settings-dialog flicker (rollback to v0.5.0 + flicker fix only)
**Date:** 2026-07-01
**Goal:** Fix two owner-reported bugs: (1) in BASIC mode, anticipating the
delivery time (locktime) to a date earlier than the hidden, stale "Check
Alive" (threshold) default could incorrectly mark the will as expired /
blocked; (2) on Windows only, BAL dialogs (Settings, waiting dialogs) briefly
flashed 1-2 blank "ghost" windows before rendering their real content.
**What changed:**
- **Bug 1 - BASIC mode Check Alive now tracks the delivery time.**
`bal/gui/qt/window.py`
- Added `BalWindow.BASIC_MODE_CHECK_ALIVE_OFFSET_SECONDS` (2 hours,
owner-approved) and a new pure `BalWindow.compute_date_to_check(
is_basic_mode, locktime_setting, threshold_setting)` static method.
- In BASIC mode, `date_to_check` (the "Check Alive" reference timestamp) is
now derived LIVE from the current delivery time (`will_settings
["locktime"]`), placed 2 hours before it, instead of reading the hidden,
possibly stale stored `threshold`. This guarantees `date_to_check` is
always earlier than the delivery time, so anticipating/postponing the
delivery date in the wizard never triggers the "locktime is lower than
threshold" guard (`build_inheritance_transaction`) nor
`Will.check_will_expired`/`WillExpiredException` anymore.
- In ADVANCED mode nothing changes: the stored `threshold` is used exactly
as before.
- Root-cause note: `Util.parse_locktime_string` never raises on invalid
input, it silently returns `0`; `compute_date_to_check` now explicitly
treats that sentinel as "unparsable" and falls back to the stored
threshold, so BASIC mode can never compute a bogus near-epoch value.
- `init_class_variables()` now simply calls `compute_date_to_check(...)`.
- **Bug 2 - Windows dialog flicker fixed.**
`bal/gui/qt/window_utils.py` (`show_modal`) and `bal/gui/qt/dialogs.py`
(`BalWaitingDialog.exe`): `bring_to_front()` (`raise_()` +
`activateWindow()`) was being called on dialogs BEFORE `exec()` actually
showed them. On Windows this forces Qt to create the dialog's native window
handle immediately, empty and unpositioned, causing a brief flash of 1-2
blank windows before the real content was drawn (reproduced from a
screen recording; Linux does not show this, since native window creation
there is lazier). Fixed by scheduling `bring_to_front()` via
`QTimer.singleShot(0, ...)` so it runs on the next event-loop iteration,
i.e. after the dialog is already visible with its real content - the
focus/raise behaviour is unchanged, only the timing of when it fires.
- Added `tests/test_group_i_basic_checkalive.py` with 6 tests calling the
real `BalWindow.compute_date_to_check` directly (no GUI/wallet needed):
the 2-hour offset constant, a fresh "1y" default, the exact reported
"anticipate to 1 month" scenario, a sweep of delivery dates always staying
before locktime, ADVANCED mode being unaffected, and the unparsable-input
fallback (which caught and fixed a real edge case during development: a
0-timestamp sentinel instead of an exception).
- Version bumped 0.5.0 -> 0.5.1 (`plugin_base.py`, `__init__.py`, `VERSION`,
`manifest.json`).
**Verification:**
- Full test suite: `272 passed` (266 previous + 6 new), plus the same 2
pre-existing, unrelated failures already present before this change
(`test_core_plugin_base.py::test_default_will_settings` /
`test_validate_will_settings`, expecting the old `baltx_fees=100` default
that v0.5.0 already changed to `20`).
- `ruff`: no new errors (only pre-existing star-import / F841 noise).
- The Check Alive fix (Bug 1) is fully covered by automated tests. The
Windows flicker fix (Bug 2) was diagnosed from a screen recording and
reasoned from the Qt/Windows native-window-creation behaviour; it cannot be
reproduced or automatically verified on this Linux environment, so the
owner needs to confirm on Windows that the flicker is gone.
**Outcome:** DONE (delivered as test ZIP v0.5.1; commit only after the owner
confirms both fixes work, especially the Windows flicker one).
---
## 27. v0.5.2 - Real fix for the Windows Settings-dialog flicker (root cause found by diffing against v0.4.8)
**Date:** 2026-07-01
**Goal:** The v0.5.1 attempt at fixing the Windows-only "ghost window" flicker
on the BAL Settings dialog (deferring `bring_to_front()` via
`QTimer.singleShot`) did NOT fix it, per owner confirmation after testing on
Windows. This entry documents the corrected root cause and the actual fix.
**Root cause (confirmed by diff, not guesswork):** the owner provided the
last known-good release (v0.4.8, no flicker) for direct comparison.
`bal/gui/qt/window_utils.py` (`show_modal`/`bring_to_front`) turned out to be
byte-identical between v0.4.8 and v0.5.0 (aside from the v0.5.1 attempt),
proving that code was never the cause. Diffing `bal/gui/qt/plugin.py`
instead showed that `settings_dialog()` gained, between v0.4.8 and v0.5.0:
(a) ~17 ADVANCED-only setting rows that are shown/hidden via `setVisible()`
right at dialog construction time (to reflect the current BASIC/ADVANCED
mode before the dialog is ever shown), and (b)
`outer.setSizeConstraint(QLayout.SizeConstraint.SetFixedSize)`, which did
**not** exist anywhere in v0.4.8's GUI code. `SetFixedSize` forces Qt to
recompute and enforce the dialog's exact size on every layout invalidation -
including while those ~17 rows are being hidden for the first time, before
the dialog has ever been shown. On Windows, that live geometry renegotiation
overlapping with native window creation is what produced the blank "ghost"
window flash (reproduced from the owner's screen recording).
**What changed:**
- `bal/gui/qt/plugin.py` (`settings_dialog`): removed
`outer.setSizeConstraint(QLayout.SizeConstraint.SetFixedSize)`, restoring
the sizing behaviour v0.4.8 already had (no forced constraint). Added an
explicit `d.adjustSize()` right before `show_modal(d)` so the dialog still
opens at its natural, correctly laid-out size (now computed once, instead
of being continuously re-enforced). The dynamic BASIC/ADVANCED row
visibility feature itself is fully preserved - only the size-constraint
coupling that caused the flicker was removed.
- Removed the now-unused `QLayout` import.
**Verification:**
- Full test suite: `272 passed`, same 2 pre-existing, unrelated failures as
before (stale `baltx_fees=100` expectation vs the v0.5.0 default of `20`).
- `ruff`: no new errors (only pre-existing star-import noise).
- Diagnosis confirmed by direct code comparison against v0.4.8 (provided by
the owner) rather than inference alone. The fix itself still cannot be
verified on this Linux environment (Windows-only symptom): the owner needs
to confirm on Windows that the flicker is gone.
**Outcome:** DONE (delivered as test ZIP v0.5.2; commit only after the owner
confirms the flicker is actually gone this time).
---
## 28. v0.5.3 - Windows Settings-dialog flicker: corrected fix (drop bring_to_front before exec(), not just defer it)
**Date:** 2026-07-01
**Goal:** v0.5.2 (removing `SetFixedSize`) did NOT fix the Windows flicker
either, per owner confirmation ("è come prima" - unchanged). This entry
documents the corrected fix, based on new evidence from the owner: the
flicker only ever happens with the Settings dialog in ADVANCED mode (many
more visible rows, much larger dialog) and never in BASIC mode (few rows,
small dialog) - always with the same intensity, not intermittent.
**Root cause (corrected):** `show_modal()` (`bal/gui/qt/window_utils.py`)
called `bring_to_front(dialog)` (`raise_()` + `activateWindow()`) BEFORE
`dialog.exec()`. The v0.5.1 attempt only *deferred* this call by one event
loop tick (`QTimer.singleShot(0, ...)`) instead of removing it, which turned
out to still fire too early relative to Windows finishing the dialog's
native window layout/paint - reproducing the same flicker. The owner's
BASIC-vs-ADVANCED observation is the key evidence: `raise_()`/
`activateWindow()` forcing native window creation before the layout has
settled produces a flash whose visible severity scales with how different
the dialog's final size is from its premature/unlaid-out state - which is
exactly why a much bigger ADVANCED-mode dialog flickers noticeably while the
small BASIC-mode one does not.
**What changed:**
- `bal/gui/qt/window_utils.py` (`show_modal`): removed the `bring_to_front()`
call (deferred or otherwise) entirely. `QDialog.exec()` already shows,
raises and activates a **modal** dialog on its own as part of entering its
modal event loop, so the call was always redundant for this case - and, on
Windows, actively harmful. `bring_to_front()` itself is untouched and is
still used (correctly) by `show_on_top()`, for the few genuinely
**non-modal** dialogs that use `.show()` instead of `.exec()` and do need
an explicit raise/activate.
- Removed the now-unused `QTimer` import.
- `bal/gui/qt/dialogs.py` (`BalWaitingDialog.exe`): applied the same
corrected fix for consistency (same redundant-before-exec() pattern, same
underlying cause), even though the owner did not report flicker there -
removed `bring_to_front()`/`QTimer.singleShot` and kept only `self.exec()`.
**Verification:**
- Full test suite: `272 passed`, same 2 pre-existing, unrelated failures as
before.
- `ruff`: no new errors (only pre-existing star-import / F841 noise).
- As with v0.5.1/v0.5.2, this is a Windows-only symptom that cannot be
reproduced or verified on this Linux environment; the owner needs to
confirm on Windows.
**Outcome:** DONE (delivered as test ZIP v0.5.3; commit only after the owner
confirms the flicker is actually gone).
---
## 29. v0.5.4 - REAL fix for the Windows Settings-dialog flicker (found by Windows-side bisection with the owner)
**Date:** 2026-07-02 **Date:** 2026-07-02
**Goal:** v0.5.3 (dropping `bring_to_front()` before `exec()`) did NOT fix the **Context:** Starting from the clean v0.5.0 codebase (a set of later
flicker either, per owner confirmation ("è come prima" - unchanged). This experimental builds, 0.5.1-0.5.4, were discarded because they introduced
entry documents the actual root cause, found through a structured bisection other problems). This release applies ONLY the Windows Settings-dialog
process where the owner tested a series of isolated diagnostic ZIPs directly flicker fix and changes nothing else - in particular, NO changes to locktime,
on Windows (since the bug cannot be reproduced on Linux), and the delivery time, Check Alive, or any will-building logic. Only
corresponding real fix, **confirmed working by the owner on Windows**. `bal/gui/qt/plugin.py` is touched (verified byte-for-byte against v0.5.0:
every other file is identical).
**Bisection process (each step tested live on Windows by the owner):** **Bug:** On Windows only, opening the BAL Settings dialog in ADVANCED mode
1. A dialog stripped down to almost nothing (2 checkboxes, no ADVANCED-only briefly flashed one or two blank "ghost" windows before the dialog rendered
rows, none of the widgets/layout features added since v0.4.8) did **not** correctly. On Linux it did not occur.
flicker → the cause is in the dialog's content, not in how/where it is
opened, nor in `show_modal`/`bring_to_front` (already ruled out in
v0.5.1/v0.5.3), nor in `SetFixedSize` (already ruled out in v0.5.2).
2. Re-adding *only* the "User Type" combo + its dynamic show/hide mechanism
flickered (mildly); re-adding *only* the new text/input fields (Event
summary/description, Welist Server, Calendar app) did **not** → narrowed
to the combo/visibility mechanism.
3. A plain `QComboBox` alone (no confirmation dialog, no dynamic show/hide)
did **not** flicker; the construction-time `setVisible()` toggle alone
(no combo at all) **did** flicker → isolated to the visibility mechanism
itself.
4. A version of that same toggle that hides each ADVANCED-only widget
**before** adding it to the layout (instead of adding it visible and
hiding it afterwards) did **not** flicker → fix validated.
**Root cause:** the ~17 ADVANCED-only rows (Welist Server, Number of **Root cause (found by bisection, each step tested on Windows by the user):**
reminders, Event summary/description, Calendar app, Auto-sign, and their the ~24 ADVANCED-only widgets (Welist Server, Number of reminders, Event
per-row reset buttons) were added to the settings grid **visible**, then all summary/description, Calendar app, Auto-sign, and their per-row reset buttons)
hidden together with `setVisible(False)` in BASIC mode, in a single loop were added to the settings grid *visible* and then hidden all at once with a
*after* they were already part of the live layout. On Windows, that `setVisible(False)` loop AFTER they were already part of the live layout. On
visible→hidden transition inside an already-populated layout - happening Windows, that visible->hidden transition inside an already-populated layout,
while the dialog's native window was still being created - forced a happening while the dialog's native window was being created, forced a
re-layout that flashed the dialog on screen. It only showed in ADVANCED mode re-layout that flashed the dialog on screen. It only appeared in ADVANCED
because BASIC mode is when the widgets get hidden (so ADVANCED is when they mode because that is when those rows are toggled and the dialog is largest.
stay visible and the dialog is at its largest, making any transient A minimal dialog (no ADVANCED-only rows) never flickered; re-adding only the
mis-layout most noticeable) - consistent with the owner's observation that construction-time `setVisible()` toggle reproduced it; hiding each widget
severity tracked dialog size. BEFORE adding it to the layout eliminated it (all confirmed on Windows).
**What changed:** **What changed (`bal/gui/qt/plugin.py`, `settings_dialog` only):**
- `bal/gui/qt/plugin.py` (`settings_dialog`): added a `basic_init` flag and a - Added a `basic_init` flag and a `_hide_if_basic(widget)` helper right after
`_hide_if_basic(widget)` helper right after the dialog is created. Every the dialog is created. Each ADVANCED-only widget is now wrapped in
ADVANCED-only widget is now wrapped in `_hide_if_basic(...)` at its `_hide_if_basic(...)` at its `grid.addWidget(...)` call, so its final
`grid.addWidget(...)` call, so its final visibility is set **before** it visibility is set BEFORE it ever joins the layout - it never transitions
ever joins the layout - it never transitions visible→hidden inside a live visible->hidden inside a live layout.
layout. Removed the old post-hoc loop that used to hide all ~17 widgets at - Removed the old post-hoc `setVisible()` loop that hid all ~24 widgets at
once after they were already added. The runtime BASIC/ADVANCED toggle once after they were already added (the flicker cause).
(`on_user_type_change`, used while the dialog is already open and visible) - The runtime BASIC<->ADVANCED toggle (`on_user_type_change`, used while the
is unaffected and still works exactly as before - only the one-time dialog is already open and visible) is unaffected and still works exactly
construction-time visibility set-up changed. as before - only the one-time construction-time visibility set-up changed.
- Reverted the ineffective v0.5.2 attempt (`SetFixedSize` removal /
`adjustSize()`) and the ineffective v0.5.3 attempt (removing
`bring_to_front()` from `show_modal()`/`BalWaitingDialog.exe()`) back to
their original v0.5.0 behaviour, since bisection proved neither was the
cause; keeping them would only have added unnecessary risk/diff.
**Verification:** **Verification:**
- Full test suite: `272 passed`, same 2 pre-existing, unrelated failures as - Full test suite: `266 passed` (same as clean v0.5.0), plus the same 2
before (stale `baltx_fees=100` expectation vs the v0.5.0 default of `20`). pre-existing, unrelated failures already present in v0.5.0
(`test_core_plugin_base.py::test_default_will_settings` /
`test_validate_will_settings`, expecting the old `baltx_fees=100` default
that v0.5.0 already changed to `20`).
- `ruff`: no new errors (only pre-existing star-import noise). - `ruff`: no new errors (only pre-existing star-import noise).
- **Confirmed fixed by the owner on Windows** (the actual reporting - Confirmed on Windows by the user that the fix (validated as an isolated
environment), after testing the full real Settings dialog with this fix diagnostic build) removes the flicker.
applied - not just the isolated diagnostic build. - Only `bal/gui/qt/plugin.py` differs from clean v0.5.0; all other files,
including all locktime/date/Check-Alive logic, are byte-identical.
**Outcome:** DONE. Confirmed resolved by the owner on Windows. **Outcome:** DONE (delivered as test ZIP v0.5.1; commit only after the user
confirms the ZIP works on Windows).