Skip to content

Fix keyboard navigation in toolbar-paned preference windows - #568

Merged
hannesa2 merged 1 commit into
gitx:masterfrom
goneng:fix-prefs-window-keyboard-navigation
Aug 11, 2026
Merged

hannesa2 merged 1 commit into
gitx:masterfrom
goneng:fix-prefs-window-keyboard-navigation

Conversation

@goneng

@goneng goneng commented Aug 11, 2026

Copy link
Copy Markdown
Collaborator

Summary

Restore keyboard navigation in GitX's toolbar-paned preference windows:
DBPrefsWindowController builds its NSPanel in code and never set
autorecalculatesKeyViewLoop, so no key view chain ever existed and Tab/Shift-Tab
did nothing. Because the panes are separate top-level views added as subviews at
runtime, Interface Builder's own key-view-loop computation never ran over them
either. This affects every window built on it, including the existing App Settings
window (PBPrefsWindowController).

  • Turn on autorecalculatesKeyViewLoop in -windowDidLoad so AppKit derives
    Tab/Shift-Tab order from view geometry, recalculated each time a pane is swapped in
  • Reset the first responder at the end of -showWindow:, mirroring the existing
    work-around in -animationDidEnd:, so a valid key view loop no longer causes the
    first control to grab focus when the window is shown

Test plan

  • Open GitX -> Settings..., and confirm Tab and Shift-Tab move focus forward and
    backward through the controls of the current pane in visual order.
  • Confirm no control shows a focus ring when the window is opened, including on a
    second open after closing it with a control focused.
  • Switch panes via the toolbar and confirm Tab follows the newly shown pane.

Enable Tab/Shift-Tab field navigation, shared by PBPrefsWindowController
(App Settings) and PBGitPrefsWindowController (Git Preferences), both built
on DBPrefsWindowController. The panes are separate top-level views swapped
in as subviews at runtime, so Interface Builder's key view loop never ran
over them and the window never computed one of its own.

- Turn on autorecalculatesKeyViewLoop so AppKit derives the Tab order from
  view geometry, recalculated each time a pane is swapped in
- Reset the first responder at the end of -showWindow:, mirroring the
  existing work-around in -animationDidEnd:, so a valid key view loop no
  longer leaves a control focused when the window is shown
@goneng
goneng force-pushed the fix-prefs-window-keyboard-navigation branch from e1cb604 to 2742baf Compare August 11, 2026 12:39
@hannesa2
hannesa2 merged commit d029960 into gitx:master Aug 11, 2026
3 checks passed
@goneng
goneng deleted the fix-prefs-window-keyboard-navigation branch August 11, 2026 19:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants