I'm integrating NativeTextViewWrapper into my app, where the editor sits inside a keyboard-navigable card. Text binding, undo, and documentId already cover most of what I need. The part I can't handle cleanly from outside the package is coordinating focus and passing unused keyboard commands back to the surrounding UI.
For focus, it would be useful to have an optional two-way binding (or an equivalent small API) that:
- lets the host request focus after switching from a read view to the editor;
- reports user-driven focus and blur;
- only resigns the editor when the binding becomes
false, without disturbing another control that has since become first responder.
For keyboard handling, could the wrapper expose a fallback callback for commands such as cancelOperation:, insertTab:, and insertBacktab:? The engine should keep first refusal: inline-link UI, list indentation, and any other editor behavior would run first. The callback would only see commands the engine did not consume, and its return value would say whether the host handled them.
Very roughly, the call site might look like this:
NativeTextViewWrapper(
text: $text,
isFocused: $isFocused,
onUnhandledCommand: { command in
// Leave the editor or move to another field.
}
)I'm not attached to these names or this exact shape. The important part is that an embedder can participate without finding the internal NSTextView or installing a competing key monitor. Both additions could be optional, so existing call sites keep their current behavior.
I plan to consume a tagged release rather than pinning a fork or commit.
I'm integrating
NativeTextViewWrapperinto my app, where the editor sits inside a keyboard-navigable card. Text binding, undo, anddocumentIdalready cover most of what I need. The part I can't handle cleanly from outside the package is coordinating focus and passing unused keyboard commands back to the surrounding UI.For focus, it would be useful to have an optional two-way binding (or an equivalent small API) that:
false, without disturbing another control that has since become first responder.For keyboard handling, could the wrapper expose a fallback callback for commands such as
cancelOperation:,insertTab:, andinsertBacktab:? The engine should keep first refusal: inline-link UI, list indentation, and any other editor behavior would run first. The callback would only see commands the engine did not consume, and its return value would say whether the host handled them.Very roughly, the call site might look like this:
I'm not attached to these names or this exact shape. The important part is that an embedder can participate without finding the internal
NSTextViewor installing a competing key monitor. Both additions could be optional, so existing call sites keep their current behavior.I plan to consume a tagged release rather than pinning a fork or commit.