Introduce `TextInput.caps-mode`
This introduces a caps-mode field that sets up the Android soft-keyboard's auto-capitalization (and also allows similar features in other soft keyboards)
This PR is more of a "request for comments", because:
- We needed this property for our own soft keyboard, and I never actually tested the Android implementation, only our custom
input_method_requestwindow callback. It does work well there. - I'm not sure about naming and the documentation.
- I couldn't run the doc update because
pnpm icrashed with a heap overflow. (I also forgot to put the Changelog entry in the commit message, but I can amend it later.)
It would be awesome if someone could help with the above points.
(BTW, it would also be nice if InputMethodRequest and the callback was public API, because we really need it for our custom platform implementation, and using i_slint_core::InternalToken is super dirty.)
Cool :). Generally, I think this makes sense. What's most unclear to me is what we should call this. I see this mode as well as other options (such as whether to enable auto-correct, or even auto-completion) as hints the developer/designer specifies. A keyboard may take it into account, but might not. So somehow it feels like we need a combination of two things:
- The ability to declare flags (as opposed to enums).
- A name for this. Something like
InputMethodHints.
Another option for (1) would be to use a structure:
struct InputMethodHints {
capitalization-mode: CapitalizationMode,
auto-correct: bool,
auto-complete: bool,
}
(I know this isn't totally actionable advice, but I'm curious first what your thoughts are)
I think flags as named bool properties are fine from a user perspective.
I'm wondering how the struct version would look in actual slint code.
Regular properties:
LineEdit {
input-type: text;
capitalization-mode: sentences;
auto-complete: false;
...
}
Structure:
LineEdit {
input-type: text;
input-hints: { capitalization-mode: sentences, auto-complete: false };
...
}
This would probably make it easier to add more flags/attributes, because it would automatically drip through the properties. It's also intuitive that this is some advanced functionality.
(Capitalization mode needs to be an enum, btw, as the options are mutually exclusive)
I'm OK with both versions, and would leave the decision to y'all, as the maintainers.