Iced: Doubts on design choices

[janosimas]

I'm a little puzzled with some design choices:
1) Why Button has a .on_press but TextInput uses a callback in the constructor?
2) Why a callback in TextInput and a message on Button? why not a stateful closure with no argument?
3) Text accepts a String but TextInput only accepts a &str. Why is that? This is restrictive when you try to create a NumberInput but you cannot use 6.to_string() in your TextInput.

[hecrj]

1. Because I feel buttons should be able to be disabled, and text inputs shouldn't.
2. Why would you use a sateful closure with no argument? What's the point?
3. No reason. It started this way and I forgot to change it to stay consistent with the other widgets. PRs welcome!

These are hardly design choices, just the result of an experimental API. We are still figuring things out, nothing is set in stone.

[janosimas]

1. I don't understand what you mean with disable in this context.
2. The 'strong' argument is consistency.
3. I'm still a little shy for PRs, I'm new to rust. I've read the book but now that I'm do some code I'm having a lot of surprises...

[hecrj]

I don't understand what you mean with disable in this context.

The idea is that if you do not use Button::on_press, then that button will appear as disabled. I simply wanted to play with this idea and see how it works in practice. We may change TextInput (and other widgets) if it works well.

The 'strong' argument is consistency.

Consistency can be subjective. I think it is consistent to use a closure only if we need one. I believe APIs should be hand crafted with each use case in mind.

I'm still a little shy for PRs, I'm new to rust.

No worries! Feel free to ask any questions. And welcome to Rust!

[janosimas]

The idea is that if you do not use Button::on_press, then that button will appear as disabled. I simply wanted to play with this idea and see how it works in practice. We may change TextInput (and other widgets) if it works well.

I like your idea, I think for other widgets it would be easier to understand if the had the same behavior. At some point you may have widgets with more then one listener. I like more the .on_press

Consistency can be subjective. I think it is consistent to use a closure only if we need one. I believe APIs should be hand crafted with each use case in mind.

I can accept that but, for my current experience, it makes it harder to learn as you look for one pattern but it may be different for other widgets.

No worries! Feel free to ask any questions. And welcome to Rust!
:-)

[drojf]

The idea is that if you do not use Button::on_press, then that button will appear as disabled.

While I like this feature, I only found out that this is how you you're meant to do it by finding this thread. It might have been in one of the demos but I didn't remember/encounter it. Searching in the docs for "disabled" only comes up with the "disabled" stylesheet for button, which I was looking into until I found this thread.

I understand that iced is still under development, just thought it's worth mentioning that it should be specifically documented if you choose to stick with this implementation, as it may not be what people expect coming from other frameworks (even though this way makes perfect sense).

I could do a pull request to modify the 'tour' example - when you get to the "Radio button" stage, it currently entirely hides the "next" button rather than disabling it - fixing this would showcase the feature. That might have been why I thought the "disabled" feature wasn't implemented yet. But I would also need to recolor the "back" button, because the "back" button in the tour example is currently colored grey, which may be interpreted as being "disabled", when it's actually clickable.

[janosimas]

I don't know how is the current implementation but could .on_press be a Trait?
This way one could implement the Clickable for other widgets and get a consistent interface.