1. 21 Jan, 2023 1 commit
  2. 20 Dec, 2022 1 commit
  3. 12 Sep, 2022 1 commit
  4. 10 Aug, 2022 1 commit
  5. 09 Aug, 2022 1 commit
  6. 30 Jul, 2022 1 commit
  7. 29 Jun, 2022 1 commit
  8. 22 Mar, 2022 1 commit
  9. 12 Mar, 2021 1 commit
  10. 14 Dec, 2020 1 commit
  11. 11 Dec, 2020 1 commit
  12. 10 Oct, 2020 1 commit
  13. 06 Aug, 2020 1 commit
  14. 29 Jul, 2020 1 commit
  15. 11 Jun, 2020 1 commit
  16. 31 Jan, 2020 1 commit
  17. 28 Jan, 2020 1 commit
  18. 24 Jan, 2020 1 commit
  19. 08 Jan, 2020 1 commit
  20. 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
  21. 26 Nov, 2019 1 commit
  22. 04 Jun, 2019 2 commits
  23. 03 Jun, 2019 1 commit
  24. 27 May, 2019 1 commit
  25. 08 Nov, 2018 1 commit
  26. 05 Nov, 2018 1 commit
    • Greg Spencer's avatar
      Rewrite the analyze-sample-code script to also analyze snippets (#23893) · 202b045b
      Greg Spencer authored
      This rewrites the sample code analysis script to be a little less of a hack (but still not pretty), and to handle snippets as well.
      
      It also changes the semantics of how sample code is handled: the namespace for the sample code is now limited to the file that it appears in, so some additional "Examples can assume:" blocks were added. The upside of this is that there will be far fewer name collisions.
      
      I fixed the output too: no longer will you get 4000 lines of numbered output with the error at the top and have to grep for the actual problem. It gives the filename and line number of the original location of the code (in the comment in the tree), and prints out the source code on the line that caused the problem along with the error.
      
      For snippets, it prints out the location of the start of the snippet and the source code line that causes the problem. It can't print out the original line, because snippets get formatted when they are written, so the line might not be in the same place.
      202b045b
  27. 23 Sep, 2018 1 commit
  28. 14 Sep, 2018 1 commit
  29. 13 Jun, 2018 1 commit
    • Chris Bracken's avatar
      Revert elimination of Dart 1 (#18460) · 2ae48845
      Chris Bracken authored
      fuchsia_tester.dart still assumes Dart 1. Previously, it ran tests directly
      from source, flutter_platform.dart automatically runs a kernel compile when
      operating in Dart 2 mode, but this assumes a functional Dart SDK is available
      in the artifacts directly, and fuchsia_tester.dart mocks out the artifacts
      directory with an empty temp dir.
      
      Remaining work is:
      1. Get the frontend server building as a dependency on Fuchsia.
      2. Patch fuchsia_tester.dart to use a valid Dart SDK and frontend server.
      
      This also reverts migration to Dart 2 typedef syntax.
      
      This reverts commit 6c56bb24. (#18362)
      This reverts commit 3daebd05. (#18316)
      2ae48845
  30. 11 Jun, 2018 1 commit
    • Greg Spencer's avatar
      Update typedef syntax to use Function notation and turn on lint for old notation. (#18362) · 6c56bb24
      Greg Spencer authored
      Now that Dart 1 is turned off, reapplying my change to turn on the prefer_generic_function_type_aliases analysis option, and fix all the typedefs to Dart 2 preferred syntax.
      
      Also eliminated the unused analysis_options_repo.yaml file and turned on public_member_api_docs in analysys_options.yaml.
      
      No logic changes, just changing the typedef syntax for all typedefs, and updating analysis options.
      6c56bb24
  31. 30 May, 2018 2 commits
  32. 19 Jan, 2018 1 commit
  33. 21 Jun, 2017 3 commits
  34. 08 May, 2017 1 commit
  35. 15 Apr, 2017 1 commit
    • Ian Hickson's avatar
      Support chaining await calls on controllers (#9389) · 14e728d0
      Ian Hickson authored
      With this patch, you can do:
      
      ```dart
         Future<Null> foo() async {
           try {
             await controller.forward().orCancel;
             await controller.reverse().orCancel;
             await controller.forward().orCancel;
           } on TickerCanceled {
             // did not complete
           }
         }
      ```
      
      ...in a State's async method, and so long as you dispose of the
      controller properly in your dispose, you'll have a nice way of doing
      animations in sequence without leaking the controller. try/finally
      works as well, if you need to allocate resources and discard them when
      canceled.
      
      Simultaneously, you can do:
      
      ```dart
         Future<Null> foo() async {
           await controller.forward().orCancel;
           await controller.reverse().orCancel;
           await controller.forward().orCancel;
         }
      ```
      
      ...and have the same effect, where the method will just silently hang
      (and get GC'ed) if the widget is disposed, without leaking anything,
      if you don't need to catch the controller being killed.
      
      And all this, without spurious errors for uncaught exceptions on
      controllers.
      14e728d0
  36. 15 Sep, 2016 1 commit