...and other minor Border improvements.
And tests.
This changes the merge logic I added yesterday to not support nulls
but instead support BorderSide.none and equivalents. This makes more
sense when dealing with actual Borders.
Temporary workaround to the fact that the Analyzer API
doesn't have a way to turn on asserts in initializers, coupled
with the fact that this file is being parsed by package:intl
using the Analyzer API.
In 85c425ac88, a test was added to ensure that widget.onChanged was
fired when the contents of an EditableText changed via system paste
events (e.g. triggered from a TextSelectionOverlay). Due to a long stack
of rebases and (less-than-perfect) manual merge conflict merge
resolution, it was inadvertently added twice.
This patch fixes a collection of issues with widgets involved in text
editing:
* Fire widget.onChanged on EditableText value change:
The value of an EditableText is composed of the text value as well
as other editing-related data such as selection-related information.
Previously, widget.onChanged() was only called for updates via
updateEditingValue(). For pastes via a TextSelectionOverlay, updates
are signalled via _handleSelectionOverlayChanged(), which only ever
triggered widget.onSelectionChanged(), but not widget.onChanged().
Both updateEditingValue() and _handleSelectionOverlayChanged()
perform the value update via _formatAndSetValue(), which is where
this patch moves the widget.onChanged() call.
* Correctly update TextFormField value on edits via controller:
The textual value of a TextFormField exists in two locations:
1. FormField.value, as with all FormFields and subclasses.
2. TextEditingController.value associated with the TextField
underlying the TextFormField.
Previously, edits to the TextEditingController associated with a
TextFormField resulted in updates to the rendered TextField widget,
but did not update TextFormField.value. FormField.value is updated
via FormField's onChanged function, which is called from the
EditableText underlying the TextField underlying the TextFormField.
EditableText only fires onChanged when it receives changes from the
engine. It does not fire onChanged for changes made to the
underlying TextController, since the owner of the TextController is
the one making these changes and thus, already aware of them.
FormField, however, *does* need to listen to these changes to update
its value.
* Adds an initialValue parameter to the TextFormField constructor:
FormField's constructor already takes an initialValue parameter,
which specifies the initial value in the field, which is also the
value to which reset() returns the field.
Previously, TextFormField took its initial value from the controller
value (if a controller was passed in) or the empty string (if not).
This had the undesirable effect that calling reset() always resets
the value to the current value of the controller... i.e., does
nothing.
We now take an initial value explicitly.
* Clone hot reload benchmark for --preview-dart-2 option.
* Get rid of linux and win preview_dart_2 (only android would be sufficient for now). Refactor code into lib/tasks
* Revert 2016 to 2017
* Mark new test as flaky
Adds a test that verifies that EditableText sends a
TextInput.setEditingState message to the engine when the associated
TextEditingController is replaced.
This class lives in the Context and allows callers to "inject"
flag values, where flag values are first extracted from the
command arguments, then from the global arguments as a fallback.
* Make switch widget accept 3 other colors: inactiveThumbColor, inactiveTrackColor, activeTrackColor.
* Make switch widget accept 3 other colors.
* Make switch widget accept 3 other colors.
* _SaltedKey solution to `ExpansionPanelList`
_SaltedKey implementation courtesy of @Hixie
Tested and confirmed working.
Fixes#11166
* Added a simple test
* Style correction to test
This makes command validation happen as part of `verifyThenRunCommand()`,
using a newly introduced protected method (`validateCommand()`) rather than
a `commandValidator` property (that subclasses were responsible for manually
invoking).
Just some very minor tweaks to remove subtle LTR bias.
We use the same arrow rotation animation in RTL and LTR, but I think
that's correct. Usually, rotations are either clockwise or
anitclockwise, which are the same in RTL and LTR. We might need to check
with someone who reads an RTL language to confirm.
Fixes#11845
Previously, the rows and columns arguments had different semantics. Now
they have the same semantics. The new API also uses Iterable rather than
List to give clients more flexiblity in how they construct these
arguments. For example, RenderTable no longer needs to reify the
reversed list of column positions.
