ui: back the Settings text fields with native OS controls - #282
Merged
Conversation
The preferences view's seven text fields (profile rename, add-channel, cache path, cache size, cache backend, the two zoom-shortcut keys) were drawn-only; now each publishes a native-entry descriptor over its drawn twin, the way the Accounts fields already do. Keystrokes flow to the same buffer (OnText → setSettingsField, which also keeps Scene focus in step and clamps a zoom field to one rune), and the native entry's Enter commits through the SAME commitSettingsField the drawn field's keyboard Enter uses — persisting the value and re-aggregating — via a NativeSettingsCommit record the windowapp Handler wires to OnActivate (the settings-view analogue of the button hit bridge). So on a host that embeds native controls (cocoa, win32, gtk) the settings fields are real OS text fields; the drawn field stays as the fallback. Fully reachable on macOS/Windows today; on GTK the fields render but the view is not yet navigable until the backend routes pointer input to the Surface. Tests: TestSettingsFieldsEmitNativeControls (all seven published, buffers written, zoom clamped) and TestNativeSettingsFieldCommitsOnEnter (the native Enter commits through the real Handler and the app applies it).
The 100% gate flagged the new setSettingsField (FocusZoomOut branch), FocusSettingsField, and lastRune (empty input) as uncovered. Extend TestSettingsFieldsEmitNativeControls to type into the zoom-out field, clear a zoom field, and focus a field by name.
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.
The preferences view's seven text fields (rename, add-channel, cache path/size/backend, the two zoom-shortcut keys) were drawn-only; now each publishes a native-entry descriptor over its drawn twin, like the Accounts fields already do. Keystrokes flow to the same buffer (
OnText→setSettingsField, keeping Scene focus in step and clamping a zoom field to one rune), and the native entry's Enter commits through the samecommitSettingsFieldthe drawn field's keyboard Enter uses — persisting the value and re-aggregating — via aNativeSettingsCommitrecord the windowapp Handler wires toOnActivate(the settings analogue of the button hit-bridge).So on a host that embeds native controls (cocoa, win32, gtk) the settings fields are real OS text fields; the drawn field stays as the fallback. Fully reachable on macOS/Windows today; on GTK they render but the view isn't navigable until the backend routes pointer input to the Surface.
Tests:
TestSettingsFieldsEmitNativeControls(all seven published, buffers written, zoom clamped) andTestNativeSettingsFieldCommitsOnEnter(native Enter commits through the real Handler and the app applies it).