Skip to content

ui: back the accounts editor's fields with native OS controls - #278

Merged
tannevaled merged 1 commit into
mainfrom
feat/native-controls
Aug 31, 2026
Merged

ui: back the accounts editor's fields with native OS controls#278
tannevaled merged 1 commit into
mainfrom
feat/native-controls

Conversation

@tannevaled

Copy link
Copy Markdown
Contributor

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:

  • a secret field → `NSSecureTextField` (a drawn mask can't keep keystrokes from the process),
  • a plain field → `NSTextField`,
  • the boolean field → a checkbox.

Every callback writes back through the same `SetAccountField` a keypress/click reaches, so the credential store stays the single source of truth.

Tests

  • `TestAccountsEmitNativeControls` — the screen emits the right kinds + geometry, and callbacks update the store.
  • `TestNativeControlsResetEachFrame` — the list is per-frame (controls don't linger).
  • `TestNativeControlsForwardsSceneControls` — the Handler forwards them.
  • New code 100% covered; full suite green; verified on-device (a real secure field in the running .app).

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.

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.
@tannevaled
tannevaled merged commit 186fdbd into main Aug 31, 2026
13 checks passed
@tannevaled
tannevaled deleted the feat/native-controls branch August 31, 2026 12:52
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