Iced::widget vs iced_aw::widget

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’s Grid and Tabs, or even a standalone icon widget (only available in TextInput) are not part of the iced “batteries”?

Now to my ideas:

  • Make a standalone icon widget, like the icon in TextInput but without TextInput. 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. :pencil2: 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 of TypedInput.
    Example:
  1. type 0.001
  2. Delete the last 1 → The text immediately will be reset to 0.
    What if I actually wanted to just change the 1 into a 2?
    Or:
  3. type 1e1 → The text immediately will be expanded to 10
    What if I wanted to actually write 1e10?

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?

I believe iced_aw is maintained by a different group of people. They may have different expectations from iced’s author as to what may be included in their project.

1 Like