Repository navigation
Disabling a button is non-obvious #287
Description
Monday Nov 09, 2015 at 20:35 GMT
Originally opened as https://github.com/flutter/engine/issues/2017
It's not obvious from the API or docs that the way to disable a button is to pass a null onPressed. In retrospect it's kinds of obvious, but I ended up reading the source to work it out.
Metadata
Metadata
Assignees
Labels
No labels
Activity
FlutterIssues commentedon Nov 10, 2015
Tuesday Nov 10, 2015 at 02:32 GMT
Thanks for the feedback!
abarth commentedon Dec 5, 2015
@alhaad ran into this issue too. He wanted to set the color of the button, but it wasn't working because the button was disabled.
Hixie commentedon Mar 5, 2016
We're going to try making onPressed @required. cc @pq.
Use `@required` for onPressed and onChanged
5 remaining items
feinstein commentedon Aug 4, 2019
I don't think a simple change as a
isEnabledjustifies a whole package.I honestly don't see much confusion on this. We are talking about only 2 ways of disabling a button (if we aim for a no-breaking change).
Currently IMHO the whole "give it a null
onPressedto disable" is a confusion on itself for many beginners (not mentioning readability issues), this would simplify things. Specially as creating a Button with anullonPressedis something almost no one desires when creating a Button, the goal of a Button is to have aonPresseddelegate.Hixie commentedon Aug 4, 2019
We have to look at it holistically. It's not just this widget. If we aren't strict about it, we end up bloating the API across the board.
Packages are cheap. You should totally feel free to create a package. And hey, if it proves popular that would be a good way to signal to us that I'm wrong about this.
feinstein commentedon Aug 4, 2019
I understand your point, it makes perfect sense, but if I create a package I would have to update it all the time with the latest releases of the Flutter Widgets. Also, I would have to make wrappers for all the current Widgets, which will be a lot more work than just adding a simple
isEnabledhere and there. So not wanting to sound selfish but this would be a lot of work on my side just to have a simpler API for a button, which I can't justify right now with my current schedule.Would you mind if I create a new issue with my proposal, to see if it gathers support from the community (through 👍), instead of basing on package popularity? It has already 9 votes, but I think many people don't see it as it's lost in the middle of the original post.
Hixie commentedon Aug 4, 2019
You are welcome to file a bug. I don't know if thumbs up will really help here though because people in general like features like this in theory and then report a general dissatisfaction with the platform, they don't realize that the dissatisfaction comes from the feature.
Re the package, I guess the difficulty would by adding constructor arguments when we add features to these widgets?
feinstein commentedon Aug 4, 2019
Yes, and having to check at each new release of Flutter all the constructors to see if they changed at all.
Hixie commentedon Aug 4, 2019
Might be worth filing a bug on the Dart SDK asking for a feature that would let you extend a class and add a constructor that forwards all the arguments from the superclass except those you explicitly override.
feinstein commentedon Aug 4, 2019
I don't feel comfortable filling a feature request like this because I am kinda new to Dart, I don't feel confident enough to discuss this, as other advanced language topics might show up. Would you mind filling it yourself if you think it could be helpful and send me the link?
Hixie commentedon Aug 4, 2019
https://github.com/dart-lang/sdk/issues/37736
feinstein commentedon Aug 4, 2019
Thanks @Hixie.
github-actions commentedon Aug 17, 2021
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.