1. 28 Jul, 2022 1 commit
  2. 03 Feb, 2022 1 commit
  3. 10 Dec, 2021 1 commit
  4. 08 Oct, 2021 3 commits
  5. 18 Sep, 2021 1 commit
  6. 15 Jul, 2021 1 commit
  7. 14 Jul, 2021 3 commits
  8. 13 Jul, 2021 2 commits
  9. 21 Apr, 2021 1 commit
  10. 09 Nov, 2020 1 commit
  11. 07 Nov, 2020 2 commits
  12. 16 Mar, 2020 1 commit
  13. 07 Jan, 2020 1 commit
  14. 27 Nov, 2019 1 commit
    • Ian Hickson's avatar
      License update (#45373) · 449f4a66
      Ian Hickson authored
      * Update project.pbxproj files to say Flutter rather than Chromium
      
      Also, the templates now have an empty organization so that we don't cause people to give their apps a Flutter copyright.
      
      * Update the copyright notice checker to require a standard notice on all files
      
      * Update copyrights on Dart files. (This was a mechanical commit.)
      
      * Fix weird license headers on Dart files that deviate from our conventions; relicense Shrine.
      
      Some were already marked "The Flutter Authors", not clear why. Their
      dates have been normalized. Some were missing the blank line after the
      license. Some were randomly different in trivial ways for no apparent
      reason (e.g. missing the trailing period).
      
      * Clean up the copyrights in non-Dart files. (Manual edits.)
      
      Also, make sure templates don't have copyrights.
      
      * Fix some more ORGANIZATIONNAMEs
      449f4a66
  15. 22 Jul, 2019 1 commit
  16. 26 Apr, 2019 1 commit
  17. 23 Oct, 2018 1 commit
  18. 16 Oct, 2018 1 commit
  19. 12 Sep, 2018 1 commit
  20. 04 Jun, 2018 1 commit
    • Ian Hickson's avatar
      Be less verbose in the logs. (#17401) · e3427550
      Ian Hickson authored
      Now that we have thousands of tests, it doesn't make sense to display a separate line for each test. The result is just megabytes of logs that you have to scrub through to find error messages.
      e3427550
  21. 16 May, 2018 1 commit
  22. 01 May, 2018 1 commit
  23. 30 Apr, 2018 1 commit
  24. 27 Apr, 2018 1 commit
  25. 26 Apr, 2018 1 commit
  26. 25 Apr, 2018 1 commit
  27. 24 Apr, 2018 1 commit
  28. 27 Mar, 2018 1 commit
  29. 22 Mar, 2018 1 commit
    • xster's avatar
      Cupertino pull to refresh part 1: sliver and a simple indicator widget builder (#15324) · feadfd2e
      xster authored
      * Gallery scaffolding
      
      * Started RenderSliver
      
      * demo and initial hookup
      
      * Cleaned up demo more and scaffolding basic sliver->widget communication structure.
      
      * works
      
      * states and default indicator building works
      
      * start adding docs
      
      * added an alignment setting optimized the sliver relayout mechanism
      
      * tested a default bottom aligned sized indicator
      
      * Added a bunch of tests
      
      * more fixes and more tests
      
      * Finished the tests
      
      * Add docs
      
      * Add more doc diffing wrt material pull to refresh
      
      * Mention nav bar synergy
      
      * add more asserts
      
      * review 1
      
      * Fix mockito 2 / dart 2 / strong typed tests
      
      * review
      
      * Remove the vscode config
      
      * review
      feadfd2e
  30. 16 Mar, 2018 1 commit
  31. 02 Feb, 2018 1 commit
  32. 01 Feb, 2018 1 commit
  33. 14 Oct, 2017 1 commit
  34. 08 Aug, 2017 1 commit
    • Michael Goderbauer's avatar
      Don't trigger an assert when markNeedsSemanticsUpdate is called multiple times... · b551f534
      Michael Goderbauer authored
      Don't trigger an assert when markNeedsSemanticsUpdate is called multiple times in edge cases (#11544)
      
      * Don't trigger assert if a render object ceases to be a semantic boundary
      
      This bug was exposed by https://github.com/flutter/flutter/pull/11309, which caused the following assertion to trigger when scrolling in the Animation demo:
      
      ```
      The following assertion was thrown during _updateSemantics():
      'package:flutter/src/rendering/object.dart': Failed assertion: line 2626 pos 16: 'fragment is
      _InterestingSemanticsFragment': is not true.
      ```
      
      A minimal reproduction of the bug can be found in `semantics_10_test.dart`, which has been added as a regression test for the bug by this PR.
      
      Looking at that test, here is a description of the faulty behaviour:
      1. During the second `pumpWidget` call `RenderExcludeSemantics` marks itself as needing a semantics update (due to excluding going from `false` -> `true`).
      2. This causes the nearest ancestor with semantics information (here: `RenderSemanticsAnnotations` representing the "container" Semantics widget) to be added to the `_nodesNeedingSemantics` list.
      3. `RenderSliverList` (implementation behind ListView) marks itself as needing a semantics update (due to its changing children).
      4. This causes the `RenderSemanticsGestureHandler` to be added to the `_nodesNeedingSemantics` list.
      5. Next, canDrag is updated from `true` -> `false`. This means, `RenderSemanticsGestureHandler` is no longer a semantics boundary, it marks itself as needing a semantics update.
      6. The nearest ancestor with semantics (`RenderSemanticsAnnotations`, the "container") is added to the `_nodesNeedingSemantics` list (this is a no-op because it is already in the list).
      7. During `flushSemantics`, the `_nodesNeedingSemantics` list is walked. The first entry (`RenderSemanticsAnnotations`) updates the semantics tree to only contain the container widget and drop everything else (= no children of the ExcludeSemantics widget are walked).
      8. The second entry (`RenderSemanticsGestureHandler`) is updated. It does not add any semantics of its own and is no longer a semantics boundary. Therefore, it wants to merge its descendent semantics into its parents. Here is where the assert throws because the algorithm assumes that every entry in the `_nodesNeedingSemantics` list will produce and own an `_InterestingSemanticsFragment` (passing your semantics on to your parents is not interesting).
      
      The problem here seems to be step 4 in combination with step 5. In step 4 we rely on the fact that `RenderSemanticsGestureHandler` is an (explicit or implicit) semantics boundary and that it will be able to absorb the semantics change of `RenderSliverList`. This is true
      at this time. However, in step 4 `RenderSemanticsGestureHandler` decides to no longer be an (explicit or implicit) semantics boundary and our assumption from step 5 becomes incorrect. We did nothing to correct this assumption.
      
      This PR removes a node, that could potentially cease to be a (explicit or implicit) semantics boundary from the `_nodesNeedingSemantics` list to fix that problem. Please node that this does not mean that the node's semantics will not be updated: The node's closest ances
      tor with semantics is added to that list during the `markNeedsSemanticsUpdate` call. During `flushSemantics` we will walk from this node to update the semantics of it's children (if changed), which will include the node in question.
      
      * tiny fix
      
      * simplify test
      
      * analyzer fixes
      
      * review comments
      b551f534