May I propose this for the Framework too? #19143

I currently have some pretty ugly code to allow me to sequence an animation of changing tab and then scrolling to a certain position. This is because while ScrollController.animateTo returns a Future so I can sequence something to happen after scrolling is done, TabController.animateTo is void.

Workaround (in the referenced issue above) is complicated and slightly absurd :-)

We should just be able to fix #19143, turning something from returning void to returning a Future when it's something that we don't expect people to implement shouldn't be a breaking change.

This bug is specifically about changes we can never really make because they're breaking changes.

Adding a type parameter to invokeMethod would be nice too: #17333

Done, and non-breaking

May I complain here that I dislike how Stack expects its children ordered back-to-front in z-order? For example:

Stack(children: [
  child1,
  child2,
  child3,
])

I find it rather unintuitive that child1 appears on top in the code but is actually at the bottom of the stack.

Just passing there after listening to your awesome podcast on itsallwidgets.com

ChangeNotifier and Listenable and company are a bit mixed up. We could refactor the code here so that we more clearly have a Listenable and a ListenableController, and a ValueListenable and a ValueListenableController, and so on.

What does it mean? Moving toward an API closer to Stream vs StreamController for Listenable?

Container's width and height properties should size the child, and imply an alignment.

I'm not sure I agree with that one.
While the current behavior is definitely surprising for newcomers, that's a good thing IMO.

From my experience mentoring in Flutter, that specific API is usually the first step that led peoples understanding that Flutter does layout differently.
This helped my mentees a lot in understanding that, in Flutter, UI elements means nothing without the rest of the tree – and that everything is declarative to the core.

AnimatedWidget, ImplicitlyAnimatedWidget and their subclasses should be named consistently. For the most part, subclasses of AnimatedWidget are named FooTransition and subclasses of of ImplicitlyAnimatedWidget are named AnimatedFoo. There are annoying/unnecessary exceptions, though, which should be renamed for consistency:

• AnimatedModalBarrier (subclass of AnimatedWidget) should be renamed to ModalBarrierTransition
• AnimatedBuilder (subclass of AnimatedWidget) should be renamed to something like TransitionBuilder *)
• AnimatedWidget itself should probably more accurately be named TransitionWidget
• Maybe: ImplicitlyAnimatedWidget should just be AnimatedWidget
• Name the Foo vs FooTransition vs AnimatedFoo widgets more consistently (e.g. Opacity vs FadeTransition vs AnimatedOpacity).

*) This would also fix another item on the list above: "Rename AnimatedBuilder to make it clear it takes any Listenable (even AnimationBuilder would be more consistent...)."

Please feel free to edit the list above so that we just have one comment with all the proposed changes.

@Hixie I added a bullet to the list in the top post and linked to the detailed description in the comments.

It seems to me that some naming-related items on this list could be done by renaming the offending identifiers, and introducing a temporary (for ~1 year/4 major releases) type-alias with the old name.

For example:

• Adapter -> Adaptor
• BlendMode.srcATop -> BlendMode.srcAtop
• BlendMode.dstATop -> BlendMode.dstAtop

Adding this one as well: #61690

One more thing a few more things for the list…

• Convert Builder classes into constructors.

StatefulBuilder can be useful, but there's really no benefit to extending the class. Instead, we could follow the example of ListView.builder and turn it into StatefulWidget.builder, and the same could apply to every "builder" class.
Freeing up the namespace would be beneficial, e.g. a developer could use Builder as a class or typedef without a name overlap.

• Separate packages for framework layers

I don't like when "intellisense" gives me multiple copies of the same suggestion. It'd be nice if, for instance, material and foundation were separate packages, so projects would have an indirect dependency on foundation rather than a direct one.

• Combine Animatable<T> and ParametricCurve<T>

Animatable has a transform method which creates a value based on a double t parameter (a fraction in the range 0.0 to 1.0); ParametricCurve.transform() does pretty much exactly the same thing.
But a few differences in the implementation make it so we can't just have one of those classes as a subtype of the other without breakages.

A small one: SelectionChangedCause.scribble should be renamed to SelectionChangedCause.stylusHandwriting to indicate that it is not iOS-specific.

Tracked in: #159223

could you please add some gesture information to the hitTest method for custompainter??? for example when using interactiveViewer and painting a list of items, say like a map with points of interest, i need to detect taps on those items.

hitTest gets triggered when panning on the map, causing accidental clicks. if hitTest has some info about which gesture happened i could make it work. Current workaround is to wrap CustomPaint in a GestureDetector and use onTapDown.

I think you might be using hitTest wrongly. It's purpose is not to tell you that your widget was tapped, so you can call a callback, or trigger some logic. It's purpose is for you to inform the framework that there's something in those coordinates, so the gesture detection algorithm can decide which widget is being tapped (as you might be tapping on a transparent area in your widget, so the widget that's behind can get that gesture instead), and will get the gesture callback activated.

Developers often use ValueChanged<T> in contexts where the function isn't being called on changes and has nothing to do with changing values-they just wanted a type def for void Function(T) and ValueChanged was handy.

As such, ValueChanged<T> should've just been called ValueCallback<T> to make it more obviously usable outside of strictly on change callbacks.

Developers often use ValueChanged<T> in contexts where the function isn't being called on changes and has nothing to do with changing values-they just wanted a type def for void Function(T) and ValueChanged was handy.

As such, ValueChanged<T> should've just been called ValueCallback<T> to make it more obviously usable outside of strictly on change callbacks.

This can be no breaking. If found valuable, we can introduce one without removing the other. They would be virtually equal, but have different semantics.

I agree this would be a nice addition, in the mean time remember that the framework also provides ValueSetter<T>.