Skip to content

Fix Settings page key navigation order#77

Merged
DemonGiggle merged 2 commits into
mainfrom
fix/settings-key-order
May 10, 2026
Merged

Fix Settings page key navigation order#77
DemonGiggle merged 2 commits into
mainfrom
fix/settings-key-order

Conversation

@DemonGiggle
Copy link
Copy Markdown
Owner

Summary

  • align Settings page up/down navigation with the rendered widget order
  • drive focus traversal from an explicit UI-order list instead of enum values
  • add a regression test covering the Theme/Search/Debug/Local Storage focus sequence

Testing

  • go test ./...
  • go vet ./...

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copy link
Copy Markdown

@gemini-code-assist gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request introduces a settingsFocusOrder slice to explicitly define the keyboard navigation order in the settings page, decoupling it from the enum order. It also updates the cycleFocus method to utilize this new order and adds a corresponding test case. Feedback suggests adding a defensive test to ensure the focus order remains synchronized with the field enum and improving the robustness of the index lookup in cycleFocus to handle cases where the focused field might not be found in the slice.

Comment thread tui/pages/settings.go
fieldCount // sentinel
)

var settingsFocusOrder = []settingsField{
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

The settingsFocusOrder slice must be manually kept in sync with the settingsField enum and the layout in renderContent. If a new field is added to the enum but omitted from this slice, it will be unreachable via keyboard navigation. Consider adding a defensive check in a test to ensure len(settingsFocusOrder) == int(fieldCount) and that all fields are present.

Comment thread tui/pages/settings.go Outdated
Comment on lines +522 to +528
currentIdx := 0
for i, field := range settingsFocusOrder {
if field == p.focused {
currentIdx = i
break
}
}
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

Initializing currentIdx to 0 makes it impossible to distinguish between the first field being focused and the focused field not being found in the settingsFocusOrder list. While p.focused is currently initialized correctly, this is fragile. Initializing to -1 and handling the "not found" case explicitly would be more robust.

currentIdx := -1
	for i, field := range settingsFocusOrder {
		if field == p.focused {
			currentIdx = i
			break
		}
	}
	if currentIdx == -1 {
		currentIdx = 0
	}

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@DemonGiggle
Copy link
Copy Markdown
Owner Author

/gemini review

Copy link
Copy Markdown

@gemini-code-assist gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request introduces an explicit focus order for the settings page fields by adding a settingsFocusOrder slice and updating the cycleFocus logic. This ensures that keyboard navigation follows a specific sequence regardless of the underlying enum values. Additionally, several unit tests were added to verify the navigation order, ensure all fields are covered, and test recovery from unknown focus states. I have no feedback to provide.

@DemonGiggle DemonGiggle merged commit d23a23f into main May 10, 2026
7 checks passed
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.

1 participant