Skip to content
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

TextInput: Input validation #4288

Open
hunger opened this issue Jan 8, 2024 · 2 comments
Open

TextInput: Input validation #4288

hunger opened this issue Jan 8, 2024 · 2 comments
Labels
a:text Text rendering, fonts, Text input (mS,bF) enhancement New feature or request

Comments

@hunger
Copy link
Member

hunger commented Jan 8, 2024

We should have a simple way to have common input validation on input.

Common things like "number", "float", "time" and maybe something pattern-based would be nice to have.

Currently you can work around this using the edited() and accepted() callbacks, but that is not very convenient nor designer-friendly.

(Originate from #4154)

@ogoffart ogoffart added enhancement New feature or request a:text Text rendering, fonts, Text input (mS,bF) labels Jan 8, 2024
@hunger
Copy link
Member Author

hunger commented Jan 8, 2024

This would improve on the InputType hack in #3356.

@Enyium
Copy link
Contributor

Enyium commented Sep 20, 2024

Since these use cases are often associated with specific data types that one would want to two-way-bind to, I believe dedicated widgets would be more appropriate. I talked about IntEdit and FloatEdit here.

In my app, I implemented a rudimentary version of a DurationEdit with an in-out property <duration> value. It allows for colon-separated integers with up to two colons. Values >= a day are represented using an hour value >= 24.

My widget also has an out property <string> unit that you can bind to to display the appropriate SI (or SI-near) unit to the right of the widget (i.e., s, min, or h). This is the unit of the leftmost number.

I want to recommend that a DurationEdit should be one of the dedicated text input widgets.

  • It could additionally support up to 3 decimal places for millisecond precision, which is all that Slint's duration type supports.
  • You should be able to specify the smallest unit as either ms, a hundredth or tenth of a second (allowing for decimal places), s or min.
  • You could also add support to opt-in to use the SI-near unit d (for "day") as the largest possible unit, which would then replace h as the largest unit. This is relevant regarding whether hour values >= 24 should be allowed, which is different from a maximum duration.
  • When the callback described in accepted callback should trigger when losing focus (incl. on window deactivation) #5930 is triggered, the widget should change its text to a canonical, clean format according to its property configuration.
  • It should support negative durations. A possible use case that comes to mind would be the synchronization-related audio delay/advancement in the context of video.
  • You should be able to specify minimum and maximum values. There should be a way to make these values quasi-unbound. For the minimum, when you don't need negative durations, you can just use 0. For the maximum, or when needing negative durations, something simlar to Rust's type constants like duration::MIN and duration::MAX would be needed. The defaults should be: minimum 0, maximum duration::MAX.
  • The unit of the most significant (leftmost) number currently in the text box could be offered as an enum that's convertible to a string. The conversion to string provided by Slint would use SI/SI-near units. But an app writer could provide their own conversion to string, if they don't want SI units (I've heard Americans aren't so used to them). In this context, it may also be useful to be informed whether the unit is in plural form, e.g., to decide for hr ("hour") or hrs ("hours"). This could be handled by that same enum, which could just have the double amount of variants (singular and plural for each), while the conversion to SI unit strings would simply make no difference between singular and plural. Although, if you're thinking forward to more exotic language support (like Arabic with special number rules), you may not want to go the many-enum-variants route, but instead separately provide the number that the enum describes, so one can check themselves what grammatical rules apply, which may go beyond singular and plural.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
a:text Text rendering, fonts, Text input (mS,bF) enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants