1. 18 Feb, 2016 1 commit
  2. 17 Feb, 2016 1 commit
  3. 16 Feb, 2016 3 commits
  4. 15 Feb, 2016 1 commit
  5. 12 Feb, 2016 2 commits
  6. 11 Feb, 2016 1 commit
  7. 10 Feb, 2016 1 commit
  8. 09 Feb, 2016 1 commit
  9. 08 Feb, 2016 1 commit
  10. 28 Jan, 2016 2 commits
  11. 27 Jan, 2016 1 commit
  12. 22 Jan, 2016 1 commit
  13. 12 Jan, 2016 1 commit
  14. 02 Jan, 2016 1 commit
  15. 31 Dec, 2015 1 commit
  16. 01 Dec, 2015 1 commit
  17. 29 Nov, 2015 1 commit
    • Adam Barth's avatar
      Clean up code organization in flutter_tools · 9662d49e
      Adam Barth authored
      1) Moved basic utility code into base/ directory to make it clear which code
         doesn't depend on Flutter-specific knowldge.
      2) Move the CommandRunner subclasses into a runner/ directory because these
         aren't commands themselves.
      9662d49e
  18. 18 Nov, 2015 1 commit
  19. 12 Nov, 2015 1 commit
    • Hixie's avatar
      flutter analyze command · a0227cab
      Hixie authored
      Other changes in this patch:
      - Make the 'flutter' tool say "Updating flutter tool..." when it calls
        pub get, to avoid confusion about what the pub get output is about.
      - Make the bash flutter tool call pub get when the revision has
        changed. (This was already happening on Windows.)
      - Fix a raft of bugs found by the analyzer.
      - Fix some style nits in various bits of code that happened to be near
        things the analyzer noticed.
      - Remove the logic in "flutter test" that would run "pub get", since
        upon further reflexion it was determined it didn't work anyway.
        We'll probably have to add better diagnostics here and say to run the
        updater script.
      - Remove the native velocity tracker script, since it was testing code
        that has since been removed.
      
      Notes on ignored warnings:
      - We ignore warnings in any packages that are not in the Flutter repo or
        in the author's current directory.
      - We ignore various irrelevant Strong Mode warnings. We still enable
        strong mode because even though it's not really relevant to our needs,
        it does (more or less accidentally) catch a few things that are
        helpful to us.
      - We allow CONSTANTS_LIKE_THIS, since we get some of those from other
        platforms that we are copying for sanity and consistency.
      - We allow one-member abstract classes since we have a number of them
        where it's perfectly reasonable.
      - We unfortunately still ignore warnings in mojom.dart autogenerated
        files. We should really fix those but that's a separate patch.
      - We verify the actual source file when we see the 'Name non-constant
        identifiers using lowerCamelCase.' lint, to allow one-letter variables
        that use capital letters (e.g. for physics expressions) and to allow
        multiple-underscore variable names.
      - We ignore all errors on lines that contain the following magic
        incantation and a "#" character:
          // analyzer doesn't like constructor tear-offs
      - For all remaining errors, if the line contains a comment of the form
          // analyzer says "..."
        ...then we ignore any errors that have that "..." string in them.
      a0227cab
  20. 10 Nov, 2015 1 commit
  21. 09 Nov, 2015 1 commit
  22. 08 Nov, 2015 1 commit
  23. 07 Nov, 2015 1 commit
  24. 02 Nov, 2015 1 commit
  25. 29 Oct, 2015 2 commits
  26. 24 Oct, 2015 1 commit
  27. 21 Oct, 2015 1 commit
  28. 12 Oct, 2015 2 commits
    • Adam Barth's avatar
      Add some print statements to smooth first run · 0e06feee
      Adam Barth authored
      This patch adds a couple print statements to explain why the first run of
      `flutter start` takes a while. (We need to download the APK and install it on
      the device.)
      0e06feee
    • Adam Barth's avatar
      Teach sky_tools about prebuilt artifacts · bdd20661
      Adam Barth authored
      This patch makes `flutter start` work without a clone of the engine git
      repository. Making this work pulled a relatively large refactor of how the
      commands interact with application packages and devices. Now commands that want
      to interact with application packages or devices inherit from a common base
      class that holds stores of those objects as members.
      
      In production, the commands download and connect to devices based on the build
      configuration stored on the FlutterCommandRunner. In testing, these fields are
      used to mock out the real application package and devices.
      bdd20661
  29. 11 Oct, 2015 2 commits
  30. 10 Oct, 2015 2 commits
  31. 09 Oct, 2015 1 commit
  32. 07 Oct, 2015 1 commit