#[non_exhaustive]pub enum SoftKeyboardSupport {
None,
ViaAccessibility,
Explicit,
}Expand description
What a platform can do about an on-screen keyboard.
Three answers, and the difference between them is what a caller may promise a user, not how much code stands behind them.
Variants (Non-exhaustive)§
This enum is marked as non-exhaustive
None
The framework has no keyboard request to send, and makes no promise that anything will rise on its own. Either the platform has no software keyboard at all, or it has one whose appearance is the platform’s business and not reliable enough to promise. A request is dropped, and a text surface driven by touch needs its own affordance.
ViaAccessibility
A keyboard exists and is guaranteed to rise when a text control takes focus through the accessibility layer, so a touch-driven text surface needs no affordance of its own. There is still nothing to ask: the framework’s ordinary IME-allowance reconcile is what summons it, and an explicit ask would at best duplicate that and at worst re-assert allowance, which cancels a live composition — so a request resolves to “already done”.
The guarantee is what separates this from None, which
covers every platform where a keyboard may or may not appear.
Explicit
A keyboard exists and can be shown and hidden on demand. Only a backend that can honour both directions may report this: a toggle whose current state is unknown cannot, because “show” would sometimes hide.