Not sure, if this should rather go to “learn”, but this topic also will have some ideas.
When looking at the available widgets in iced and iced_aw, I wondered:
- Are the iced_aw widgets experiments which eventually will end up in iced? Or asked differently: when designing new widgets, when should they go into iced and when to iced_aw?
- Why iced alread has some quite “exotic” functionality like QR code, icons in
TextInput
, when other more “basic” functionality like iced_aw’sGrid
andTabs
, or even a standalone icon widget (only available inTextInput
) are not part of the iced “batteries”?
Now to my ideas:
- Make a standalone icon widget, like the icon in
TextInput
but withoutTextInput
. I already use such a custom widget in my code and could prepare it for a MR, if desired. Atm, it is single bytes only (e.g. wont work). But I would try to also support multi byte emojis. - In my usecase, I heavily rely on something like
iced_aw::widget::TypedInput
for floating point numbers.
However I did not like the user experience ofTypedInput
.
Example:
- type
0.001
- Delete the last
1
→ The text immediately will be reset to0
.
What if I actually wanted to just change the1
into a2
?
Or: - type
1e1
→ The text immediately will be expanded to10
What if I wanted to actually write1e10
?
Therefore, I came up with an own custom widget ParsedInput
, which behaves a bit differently:
Change events are only fired when:
- pressing
Enter
and the input is parseable - the focus leaves
ParsedInput
and the input is parseable
Moreover: - pressing esc resets the input to the unchanged value
- Focusing out of the widget when the input is unparseable also resets the input
- When the input is unparsable, a “!” char is at the right border of the widget.
What do you think?