Skip to content

Comments

fix(app): strike through tabs in form mode and prevent form layout jump#446

Merged
cpcloud merged 2 commits intomainfrom
fix/433-tab-strikethrough
Feb 21, 2026
Merged

fix(app): strike through tabs in form mode and prevent form layout jump#446
cpcloud merged 2 commits intomainfrom
fix/433-tab-strikethrough

Conversation

@cpcloud
Copy link
Owner

@cpcloud cpcloud commented Feb 21, 2026

Summary

  • Tab strikethrough in form mode: Inactive tabs now use TabLocked (struck-through) style when a full-row form is open, matching existing edit-mode behavior. Extracted tabsLocked() method covering both modeEdit and modeForm.
  • Form layout jump fix: Multi-group forms (Incidents, Projects, etc.) no longer jump on open. Root cause was huh's Form.Init() deferring a tea.WindowSize() cmd that recalculated group widths/heights one frame late. Fix sends a synthetic WindowSizeMsg eagerly in activateForm so dimensions are correct before the first render.
  • Cached form Init: formInitCmd() now returns a one-shot cached cmd from activateForm instead of re-calling Init() each time.

Steps to reproduce

Tab strikethrough (before fix):

  1. Open micasa, navigate to any tab
  2. Press a to add a new item (opens full form)
  3. Observe inactive tabs are NOT struck through — they look clickable even though switching is disabled

Form jump (before fix):

  1. Navigate to the Incidents tab
  2. Press a to add a new incident
  3. Observe the "enter next" indicator appears, then visibly jumps downward after ~1 frame

closes #433

🤖 Generated with Claude Code

cpcloud and others added 2 commits February 21, 2026 07:52
Inactive tabs were not struck through (TabLocked style) when a full-row
form was open, only when in edit mode. Extract tabsLocked() to cover
both modeEdit and modeForm.

Multi-group forms (Incidents, Projects, etc.) jumped on open because
huh's Form.Init() defers a tea.WindowSize() cmd. When it arrives one
frame later the form recalculates group widths (from 80 to terminal
width) and heights (to the max group), shifting the "enter next"
indicator. Fix by eagerly sending a synthetic WindowSizeMsg in
activateForm so dimensions are correct before the first render. Cache
the Init cmd in pendingFormInit so formInitCmd() returns it once instead
of re-calling Init().

closes #433

Co-Authored-By: Claude Opus 4.6 <[email protected]>
The previous approach sent a synthetic WindowSizeMsg to the form in
activateForm, which triggered huh's height equalization -- padding all
groups to the tallest group's height. This pushed the "enter next"
indicator far below the last field on forms where the current group is
shorter than the tallest (e.g. House: Basics has 6 fields vs Structure
with 10).

Fix by setting the form width via WithWidth before Init (so groups have
correct terminal widths from the first frame) and blocking the deferred
WindowSizeMsg in updateForm for all forms (not just the house form).
This prevents both the width-induced layout jump and the unwanted height
equalization.

Co-Authored-By: Claude Opus 4.6 <[email protected]>
@cpcloud cpcloud merged commit a34445a into main Feb 21, 2026
12 checks passed
@cpcloud cpcloud deleted the fix/433-tab-strikethrough branch February 21, 2026 14:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

fix(ui): inactive tabs not struck through during add/edit form

1 participant