Skip to content

Introduce TextInput.caps-mode #9016

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

badicsalex
Copy link
Contributor

@badicsalex badicsalex commented Jul 29, 2025

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_request window callback. It does work well there.
  • I'm not sure about naming and the documentation.
  • I couldn't run the doc update because pnpm i crashed 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.)

@badicsalex badicsalex marked this pull request as draft July 29, 2025 16:45
@tronical
Copy link
Member

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:

  1. The ability to declare flags (as opposed to enums).
  2. 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)

@badicsalex
Copy link
Contributor Author

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.

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.

2 participants