Add an accessibility text size for the app chrome - #774
Open
sageframe-no-kaji wants to merge 1 commit into
Open
Conversation
There is no in-app way to enlarge the sidebar, tab bar, toolbars, or Settings without changing the OS-wide display scale, which resizes the terminal along with everything else. macOS SwiftUI does not resize text in response to dynamicTypeSize, so the size is applied by resolving each semantic font explicitly: a uiTextScale environment value is published at every window root, and chrome text opts in through appFont(_:weight:monospaced:) in place of .font(.body). The Ghostty terminal surface is NSView-backed with its own font system and is unaffected. The toolbar title publishes the size a second time inside its TerminalSchemeHost closure, because that host re-hosts its content in a fresh NSHostingView rather than inheriting the window's environment. Section headers take appFontInheriting instead. List styles its own headers and SwiftUI does not expose the font it resolved, so there is nothing to scale in place; the modifier leaves them alone at Default and only supplies a point size above that, so the repository name and the Active and Pinned titles grow with the rows beneath them. A missing or unrecognized chromeTextSize falls back to the default rather than throwing, which would reset the rest of the settings file. macOS has no Dynamic Type step table to inherit, so the two steps are chosen to land near where iOS's .xLarge and .xxLarge sit, and scaled point sizes round to whole points. The Accessibility pane holding the picker is reachable at supacode://settings/accessibility and `supacode settings accessibility`, like every other pane. Tests cover the case order and raw-value stability, the decode migration from a file predating the setting, the fallback for an unrecognized value, and that an unrelated settings change no longer resets the size.
4 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #662
Summary
Adds a chrome text size setting so the sidebar, tab bar, toolbars, and Settings can be enlarged without changing the OS-wide display scale, which resizes the terminal along with everything else.
macOS SwiftUI does not resize text in response to
dynamicTypeSize, so the size is applied by resolving each semantic font explicitly: auiTextScaleenvironment value is published at every window root, and chrome text opts in throughappFont(_:weight:monospaced:)in place of.font(.body). The Ghostty terminal surface is NSView-backed with its own font system and is unaffected.Three points that may be worth a closer look during review:
TerminalSchemeHostclosure. That host re-hosts its content in a freshNSHostingView, which starts a new environment rather than inheriting the window's. Views behind the other imperatively-constructed hosting roots (command palette panel, terminal split tree) are deliberately left alone rather than plumbed, to keep this change out of the terminal internals.appFontInheriting.Liststyles its own headers and SwiftUI does not expose the font it resolved, so there is nothing to scale in place. The modifier leaves them alone at Default and only supplies a point size above that, so the repository name and the Active and Pinned titles grow with the rows beneath them.chromeTextSizeis mirrored intoSettingsFeature.Statelike the other global fields, so the picker binds through the store and persists on the existing.bindingpath. Scaled point sizes are rounded to whole points, and the system text-style metrics are read once rather than on every body evaluation.A missing or unrecognized
chromeTextSizefalls back to the default rather than throwing, which would reset the rest of the settings file — matching the existingappVisibilitydecode. The new pane is reachable atsupacode://settings/accessibilityandsupacode settings accessibility, like every other pane.Type of change
ready)How was this tested?
make checkandmake testboth pass locally. New tests cover the case order and raw-value stability, the decode migration from a settings file predating the key, the fallback for an unrecognized value, and that an unrelated settings change no longer resets the size.Also verified by running a Debug build against an isolated data directory at Extra Large: the toolbar title, the sidebar rows, and the Active/Pinned section headers all scale, and the terminal surface is unaffected.
make checkpasses (format + lint)make testpassesChecklist
Closes #above.ready.