ui: back the accounts editor's fields with native OS controls - #278
Merged
Conversation
The reader is a self-rendering toolkit.Surface, so it publishes the controls it wants natively backed the same way it publishes its accessibility tree: a flat list the platform reads each frame (Scene.NativeControls, forwarded by the windowapp Handler through application v0.2.0's NativeControlProvider onto the Surface's Controls field; the cocoa backend then embeds real AppKit controls over the framebuffer). Each accounts field emits a descriptor next to the drawn widget that stays as the fallback: a secret field becomes an NSSecureTextField — where a drawn mask cannot keep the keystrokes from the process — a plain field an NSTextField, and the boolean field a checkbox. Every callback writes back through the same SetAccountField the drawn control's keypress or click reaches, so the credential store is the one source of truth. First screen of the native-controls rollout. Bumps application v0.1.1 -> v0.2.0, toolkit v0.293.0 -> v0.299.0, window -> v0.59.0.
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
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.
First screen of the native-controls rollout — the accounts editor's credential fields become real OS controls (macOS today; Windows/Linux when their backends land — the reader code is platform-neutral).
How
The reader is a self-rendering `toolkit.Surface`, so it publishes native controls the way it publishes accessibility: `Scene.NativeControls()` accumulates a descriptor per interactive control during `Draw`, the `windowapp` Handler forwards them (satisfying application v0.2.0's `NativeControlProvider`) onto the Surface's `Controls` field, and go-widgets/window's cocoa backend (v0.59.0) embeds real AppKit controls over the framebuffer.
Each accounts field emits a descriptor beside the drawn widget, which stays as the fallback on a platform whose backend can't embed controls:
Every callback writes back through the same `SetAccountField` a keypress/click reaches, so the credential store stays the single source of truth.
Tests
Deps
application v0.1.1 → v0.2.0, toolkit v0.293.0 → v0.299.0, window → v0.59.0.
Note: the rest of the interactive controls (settings, search, buttons) follow in subsequent PRs; this is the vertical slice proving the reader path.