Skip to content

feat(agent): focus a window by number; SF Symbol glyph and app icon - #18

Merged
rbstp merged 3 commits into
masterfrom
feat/focus-window-hotkeys
Sep 6, 2026
Merged

rbstp merged 3 commits into
masterfrom
feat/focus-window-hotkeys

Conversation

@rbstp

@rbstp rbstp commented Sep 6, 2026 •

Copy link
Copy Markdown
Owner

Control-Command-1 to 9 move keyboard focus to the window with that number, counted in the order the Right and Left shortcuts already walk: screens left to right, then left to right within each screen. With Zen on the left and a terminal on the right, 1 is Zen and 2 is the terminal. One setting, focusWindowHotkey, names the combination for window 1 and the other digits follow under the same modifiers, which is what lets the Shortcut Modifier menu move all nine along with the rest. The nine are registered all or none, the way a modifier change is, and a number with no window on it is logged rather than doing something else. The keyboard focus path is shared: stepFocus and focusWindow each choose a ring index and moveFocus does the rest, so the revalidation, the hold and the ring memory are written once.

The menu bar item is now an SF Symbol: cursorarrow.rays while Heed is on and a plain cursorarrow while it is off, so the switch position shows by shape as well as by dimming, which also means "no permission". The choice lives in MenuBarState, where it is tested. Symbols come out as templates, match the weight of the neighbouring items and follow appearance changes for free; the flash draws its colour into the image through a palette configuration, since a template is a mask. The app icon is the same symbol, white on a dark tile, rendered by make-icon.swift through AppKit so the two cannot drift apart. The wireframe cube is gone from both places.

Verified live with Zen and Ghostty tiling the screen: 1 focused Zen, 2 focused Ghostty, 3 and 5 logged "only 2 windows on screen" and left focus alone, and the pointer did not take focus back afterwards. The iconset was rendered and reviewed at 512, 32 and 16 pixels, make check-package passes, and the installed build shows the glyph changing shape with the switch.

Control-Command-1 to 9 move keyboard focus to the window with that number, counted in the order
the Right and Left shortcuts already walk: screens left to right, then left to right within each
screen. One setting, focusWindowHotkey, names the combination for window 1 and the other digits
follow under the same modifiers, so the Shortcut Modifier menu moves all nine with the rest. The
nine are registered all or none, the way a modifier change is, and a number with no window on it
says so in the log rather than doing something else.

The keyboard focus path is shared: stepFocus and focusWindow each choose an index and moveFocus
does the rest, so the revalidation, the hold and the ring memory are written once.
The status item is now cursorarrow.rays while Heed is on and a plain cursorarrow while it is off,
decided in MenuBarState where it is tested, so the state shows by shape as well as by dimming,
which also means "no permission". SF Symbols come out as templates, match the weight of the
neighbouring items and follow appearance changes for free; the flash draws its colour into the
image through a palette configuration, since a template is a mask. The hand-drawn hexagon is gone.
The app icon is now the same cursorarrow.rays symbol the menu bar item shows, white on a dark tile,
rendered by make-icon.swift through AppKit so the two cannot drift apart. The wireframe cube is gone
from both places.
@rbstp rbstp changed the title feat(agent): focus a window by number, Hyprland style feat(agent): focus a window by number; SF Symbol glyph and app icon Sep 6, 2026
@rbstp
rbstp enabled auto-merge (squash) September 6, 2026 14:28
@rbstp
rbstp disabled auto-merge September 6, 2026 14:28
@rbstp
rbstp merged commit ae0fa9d into master Sep 6, 2026
1 check passed
@rbstp
rbstp deleted the feat/focus-window-hotkeys branch September 6, 2026 14:29
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