- Add x and y to the parent data, in case it's useful. In point of fact,
I ended up not needing it.
- Make columnWidths settable rather than having a setter so that the
code in the widgets layer is more idiomatic.
- Teach setFlatChildren about avoiding unnecessary drop/adopt loops.
- Assert that the child list length is correct more aggressively so that
we catch the dumb bug I had more quickly next time.
- Improve the toString() to handle empty tables better.
- Resort the imports in framework.dart.
- Introduce a LocalKey for cases where you don't want to allow use of
GlobalKey.
- Make inflateWidget and deactivateChild public for subclass use.
- Table widget.
- Cell widget.
- TableRow fake widget.
The elaboration will continue until morale improves.
Specific exceptions considered here:
- size setter checking when you set the size
- layout verifying that you do set the size
- hitTest verifying that you aren't dirty and have a size
- flex complaining about canFlex
We really shouldn't have two separate network library wrappers... I filed https://github.com/flutter/flutter/issues/2889 on that. But for now, this makes one of them have a generally better error handling story, and makes the other one only dump to the console in debug mode. It also makes both use debugPrint instead of print, and makes one use the 'mojom' prefix for mojom imports.
Previously, border with '0' was ambiguous. Sometimes we treated it as
hairline borders, sometimes as "don't show the border", though even in
the latter case we did some graphics work sometimes. Now we have an
explicit BorderStyle.none flag to not draw the border efficiently.
Previously we updated only the reactivated element's inherited widgets. Now we
update all the inherited widgets for the whole subtree that's being
reactivated. We need to visit the whole subtree anyway, so there isn't much of
a loss.
Fixes#2733Fixes#2438Fixes#1701
Previously, when the content extent changed during a scroll interaction, we'd
stop the current scroll interaction and reset the scroll offset. Now we try to
continue the scroll interaction (e.g., drag, fling, or overscroll) even through
the underlying scroll behavior has changed.
For physics-based scroll interactions, we keep the current position and
velocity and recompute the operative forces. For drag interactions, we keep the
current position and continue to let the user drag the scroll offset.
After this patch, we still disrupt non-physical scroll animations that are
operating outside the new scroll bounds because it's not clear how we can
sensibly modify them to work with the new scroll bounds.
