We had a remarkable number of analyzer failures.
I'll fix the bots to analyze across the whole project
in a follow-up patch, that should prevent this
in the future.
@abarth
Widgets that want to receive drops should include a DropTarget in their build.
Currently there's no widget for initiating a drag. Components can use the
DragController directly. In the future, we'll probably want to add a Draggable
that knows how to do some of this work automatically.
Fixes#612
Setting a ProgressIndicator's value to null (the default) makes it an "indeterminate progress" or activity indicator.
The indeterminate animations for both kinds of progress bars are essentially the same and wrong vis the Material Design spec, http://www.google.com/design/spec/components/progress-activity.html. I'll improve conformity with the visual design in a future CL.
Set the scrollOffset of a widget's Scrollable ancestor so that the
widget is centered within the scrollable. A future CL will add
support for specifying exactly where the widget appears. The scroll
can be animated by specifying the animation: parameter.
Changed the duration Scrollable.scrollTo() parameter from a Duration
to an AnimationPerformance so that one can configure all aspects of
the animation. The caller may also listen to the animation to schedule
other work while it updates or when its status changes.
complete
This introduces the concept of an Anchor, which you can use to link
transitions together. I've used this in the Fitness and Stocks apps to
link the FAB and SnackBar to animate together by sharing the
SlideTransition.
I also fixed the Scaffold hit testing code to apply sub-widget
transforms, so it works with Transformed nodes.
Now it wont crash on save, but it still doesn't display
the error message in a snackbar and this also doesn't
wire up the enter/go key to actually do anything.
We'll need to implement performEditorAction on our
InputConnection implementation to catch this key and
pass it along to dart.
Our Input control needs to get more powerful to handle things
like this, including filtering of input.
The code was crashing by triggering a bug in the SnackBar
which didn't assert for actions, but crashed when they
were not null.
Partial fix for https://github.com/domokit/sky_engine/issues/543
@abarth
This patch converts sky.Paint to be a pure Dart object, which means we don't
need to open a weak handle to sky.Paint. Avoiding the weak handle reduces the
amount of weak handle callbacks we need to process at the end of GC and
therefore reduces jank.
