1. 29 Sep, 2017 3 commits
    • Chris Bracken's avatar
      Improved behaviour for text-editing widgets (#12273) · 85c425ac
      Chris Bracken authored
      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.
      85c425ac
    • Ian Hickson's avatar
      Retry on failed download. (#12293) · e1fa035b
      Ian Hickson authored
      e1fa035b
    • Ian Hickson's avatar
      SafeArea (#12292) · 4c83ea8b
      Ian Hickson authored
      * SafeArea
      
      * AnimatedSafeArea
      
      * AppBar test
      
      * Apply feedback
      4c83ea8b
  2. 28 Sep, 2017 9 commits
  3. 27 Sep, 2017 4 commits
  4. 26 Sep, 2017 11 commits
  5. 25 Sep, 2017 3 commits
  6. 24 Sep, 2017 8 commits
  7. 23 Sep, 2017 2 commits
    • Adam Barth's avatar
      Clean up TableBorder#paint API (#12226) · ebffe159
      Adam Barth authored
      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.
      ebffe159
    • Adam Barth's avatar
      Add RTL support to Table (#12225) · 1a0bdb96
      Adam Barth authored
      Also, fix asserts in TableBorder#paint to match documentation.
      
      Fixes #12009
      1a0bdb96