snowcap: add TextInput widget

[Ph4ntomas]

The title say it all.

This PR adds TextInput widget, which will be useful as a building block for e.g. prompts.
On top of that, I've enabled support for key-repetition so the prompt themselves feel more natural.

TODO:

• Basic TextInput integration
  • Transmit text in Key Events (very basic for the time being)
  • Enable key repetition
  • on_input event
  • on_submit event
• Advanced TextInput integration
  • Styling support
    • Implements all & methods
    • Make gradient less unwieldy (add strongly typed angles & better color-stop handling)
  • Copy/Paste support -- This works. The clipboard itself is not set-up. Not sure if I'll set it up in this MR
  • cursor control from the config ?
  • Find a way to focus text input from the config
• Rust configuration support
  • basic
  • advanced
• Lua configuration support
  • basic
  • advanced
• find & remove server-side except() and raw unwrap() Postponed to [API] Gracefully handle protobuf translation issues #370 Removed the ones from this PR.
  • add a TryFromApi trait so we can log error iso crashing.
• Documentation
  • Rust
  • Lua

[Ph4ntomas]

• find & remove server-side except() and raw unwrap()
  • add a TryFromApi trait so we can log error iso crashing ?

@Ottatop do you have thought on that ?

Most except and unwrap are justified in the sense that the config library should always produce 'correct' value, but IMO the server should be resilient to protocol error.

The second point is only for types without a default implementation.
If a default exist, I'd assume unwrap_or_default() to be called instead (tho we might tracing::warn! when that happen if a value was expected).

The alternative is to hardcode our own default when the translation between protobuf & iced types fails.

[Ottatop]

do you have thought on that ?

Agree, it would be best to crack down on these panics (especially if anyone wants to make protobuf bindings), though I strongly recommend doing this in another PR seeing as this one's already up to 2.5k lines

[Ph4ntomas]

though I strongly recommend doing this in another PR seeing as this one's already up to 2.5k lines

Agree, I'll only try to remove the ones introduced by this PR and removable :)

[Ph4ntomas]

Allright, I think that's all.

FYI, the PR is on top of #364. because I needed some of the changes from that PR, and it makes for a cleaner history that cherry-picking the commits I need (plus the eventual rebase hell if I discovered some issue in that PR).

It should rebase cleanly should you choose to first pull the other one, and then rebase + merge this one (which could also be easier to review, I guess ?)

OTOH, you can also close the other one and track everything here if you prefer.

[Ottatop]

I'd like to come up with a more detached protobuf API

The more I think about this, the less viable it seems without either missing out on some iced functionality or essentially "flattening out" messages. Plus we'd still have to maintain previous messages for a time.

The alternative solution is to follow iced and make additive changes to support any breaking iced updates (like a TextInput0_16 for example). I'm not thrilled about this but it's both much easier to do and gives us the most flexibility in terms of functionality.

I'd like to move forward with adding the background message here and deprecating any background_color fields. Preferably in another PR.

[Ph4ntomas]

I'd like to move forward with adding the background message #369 (comment) and deprecating any background_color fields. Preferably in another PR.

Okay ! Just to clarify, you want another PR to add both the background and the depreciation, right ?

I keep this one as-is, but I cherry-pick back the old commit in a new MR). That way this MR can move along, and depending on which is merged first, the new one will have to remove the background color from text-input, or I'll remove the background_color from this one

[Ottatop]

you want another PR to add both the background and the depreciation, right ?

Yep. I'm probably going to merge it first before reviewing this PR.