Slint language: Add numbers such as integer, float, etc to InputType enum

[chianti-ga]

I think that adding numeric types like integers and floats (etc...) to the InputType enum is a good idea to simplify working with numeric types.

For exemple:

 LineEdit {
    placeholder-text: "mass in KG";
    text: Logic.mass;
    **input-type: InputType.integer**
}

By doing this for exemple user can only write integer to this line edit.

[tronical]

I think it makes sense to extend the API to permit for more fine-grained validation. I think however just allowing arbitrary integer input might also not be what you want. Perhaps your line edit that allows the user to input the pass should only allow at least say 2000 KG.

So perhaps we need a accept-input(string) -> bool type of callback that permits delegation to a user-defined callback.

[ogoffart]

InputType is meant for this kind of things, yes. And in general, having fields that supports only number still make sense in many case. (So accept-input is an orthogonal thing) When using virtual keyboard, this can also be used to show keyboard with number only.

I'm tagging this as a good first issue because i think this is fairly easy to add:

• Add the value in enums.rs
• Check if the input is a number in TextInput::key_event : https://github.com/slint-ui/slint/blob/93a8f604a80707b8f7fdeaff9dd12673c7458d45/internal/core/items/text.rs#L398
• Add a test similar to tests/cases/text/control_keys_input.slint

[darknight]

I'll try it.

[darknight]

I raised PR but I do have one doubt: should I consider the whole text as numeric value? For example, negative integer (-100), float (123.456) or event scientific number (4.59E+06). If so, I need to update my implementation accordingly.

[tronical]

InputType is meant for this kind of things, yes. And in general, having fields that supports only number still make sense in many case. (So accept-input is an orthogonal thing) When using virtual keyboard, this can also be used to show keyboard with number only.

I see and I'm inclined to agree. I see a distinction though. To me InputType is only about providing a hint about what type of data is expected, in order to for example adjust the virtual keyboard. So other input types in the future could be email, telephone-number, etc. similar to the HTML input mode attribute ("It's important to understand that the inputmode attribute doesn't cause any validity requirements to be enforced on input."). But it's merely a hint, and validation would not be part of it. So in my opinion the second bullet point is not in scope but rather part of an orthogonal validation.

[ogoffart]

@tronical and I had a discussion about this trying to figure out what's best for the InputType enum that is used in LineEdit.input-type and TectInput.input-type

There are a few things it could control:

1. The look: (eg, password use password character, "search" may have a lookingglass icon, ...)
2. The virtual keyboard: It can be a hint to the virtual keyboard as to what kind of keys to show and such.
3. The validation that what is entered is valid (eg: number, email)

These things are in principle orthogonal. My idea with the InputType is that it is a preset that control all of these things somehow. Although we could add API to control them more precisely.

But I do agree that it is only a hint and this is not about validation. That the dev still need to do proper validation. But it just makes the UI more intuitive for the end user if only the number "works" (even if we don't validate paste or so)

I raised PR but I do have one doubt: should I consider the whole text as numeric value? For example, negative integer (-100), float (123.456) or event scientific number (4.59E+06). If so, I need to update my implementation accordingly.

We could have InputType.decimal that allow . and -. I'm not sure if number should allow -

[darknight]

Thanks for the explanation. Based on it, I updated my PR to include InputType::Decimal, which allows . and -.

For InputType::Number, I'll leave it without allowing -, but we can change it later without much effort I suppose.

[ogoffart]

That was implemented in #3377

[hunger]

IMHO we should not mix 1 and 3 in @ogoffart list above:

How I do a PIN with the InputType merged in #3377? You can either accept numbers or hide the input now :-/