Follow-up #985: calculator number pad UX & widget edit-mode reorder polish

[jvsena42]

Summary

Follow-up to #985 (feat: v61 compact widgets support, merged). The PR was approved, but two review passes by @ovitrif flagged a set of non-blocking UX regressions and lifecycle/dismiss concerns around the calculator number pad and the edit-mode drag-to-reorder grid that were deferred to a follow-up.

• Review 1 (comments): feat: v61 compact widgets support #985 (review)
• Review 2 (approval): feat: v61 compact widgets support #985 (review)

These items are intentionally batched here for a post-merge UX-polish pass.

---

1. Number pad reveal/dismiss transition regression

The calculator number pad now renders as an external screen-bottom overlay (CalculatorNumberPadBar shown conditionally from HomeScreen) rather than living inside CalculatorCard. As a result the previous show/dismiss choreography (numpad slide, tab bar, page layout coordination) is gone — the pad pops in/out rigidly. Confirmed as a visible behavior change on both Android and iOS (so platforms are at least consistent).

• app/src/main/java/to/bitkit/ui/screens/widgets/calculator/components/CalculatorNumberPadBar.kt
• app/src/main/java/to/bitkit/ui/screens/wallets/HomeScreen.kt (overlay shown at calcState.activeInput?.let { ... CalculatorNumberPadBar(...) }, ~line 912)

Goal: restore a smooth slide-up/down reveal/dismiss transition for the pad.

2. Active-input lifecycle / stale-state cleanup

The active-input lifecycle is now split across HomeScreen, CalculatorCard, and CalculatorNumberPadBar, whereas the old CalculatorCard owned cleanup when the editor/card went away. There is a LaunchedEffect in HomeScreen (~line 800) that drops input when editing or when the calculator widget is removed, but the full set of dismiss paths should be QA'd for stale active-input / stale keypad state:

• Input active → navigate away from Home
• Input active → switch between wallet/widgets pager pages
• Input active → open another sheet
• Input active → enter edit mode
• Input active → delete the calculator widget
• Input active → tap outside

3. Editing widget settings discards an unsaved reorder ⚠️ (root cause confirmed)

Most-concerning item from review 2. If a user reorders widgets in edit mode and then taps a widget's ⚙️ settings icon, the new position is lost.

Root cause: HomeViewModel.moveWidget() only mutates in-memory _uiState; the reordered list is persisted via widgetsRepo.updateWidgets(...) only inside onClickEditWidgetList() (the top-right check toggle). The settings tap path is:

onClickEditWidget = { widgetType ->
    homeViewModel.disableEditMode()   // does NOT persist; only flips isEditingWidgets = false
    val route = widgetType.toWidgetsEditRoute() ?: widgetType.toWidgetsPreviewRoute()
    appViewModel.showSheet(Sheet.Widgets(route))
}

disableEditMode() never calls updateWidgets, so the reorder is dropped before navigating to settings.

Fix direction: persist the current order before leaving edit mode on the settings path (e.g. reuse the save in onClickEditWidgetList/extract a commitWidgetOrder() and call it from onClickEditWidget).

• app/src/main/java/to/bitkit/ui/screens/wallets/HomeViewModel.kt (moveWidget ~228, onClickEditWidgetList ~243, disableEditMode ~281)
• app/src/main/java/to/bitkit/ui/screens/wallets/HomeScreen.kt (onClickEditWidget ~347)

4. Drag-reorder glitches

• Gap between calculator and its numpad when the calculator is the first widget in the list — looks odd. (Edge case; lists start pre-populated so rarely hit.)
• Constant jumping while the user is undecided where to drop a widget (placement oscillation). Non-blocking.
• Dragged card shrinks when moved to the very top of the list.

Relevant: app/src/main/java/to/bitkit/ui/screens/widgets/components/EditableWidgetGrid.kt (drag preview sizing from cellBounds, animateBounds/ReorderBoundsTransform, nearestWidgetSlot targeting).

5. Tapping the toolbar doesn't dismiss the number pad (Android)

On Android, tapping the toolbar area (not an icon) while the number pad is shown does not hide the pad; on iOS it does. The outside-tap dismiss (Modifier.dismissCalculatorInputOnOutsideTap in HomeScreen, ~line 928) excludes the calculator and pad bounds but the toolbar tap isn't routed to dismiss.

6. Size-change discoverability nit (design — cc @aldertnl)

Users may not realize they must open Preview to change a widget's compact/wide size. The calculator jumps straight to the preview+size carousel when ⚙️ is tapped (it has no other settings), while every other widget shows its settings screen first and only reveals the size carousel inside Preview. The inconsistency reads as "only the calculator can be resized." Consider surfacing the size control more directly / consistently.

---

Notes

• Item 1 and the Android-nicer page-scroll behavior (iOS numpad doesn't scroll with the page, Android does and looks better with no bugs) were both noted as cross-platform consistency observations.
• None of these were blocking; feat: v61 compact widgets support #985 was approved and merged.