1. 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
  2. 25 Nov, 2019 1 commit
    • Michael Klimushyn's avatar
      Add a note to generated plugins files (#45557) · 901eb0fc
      Michael Klimushyn authored
      There has been some confusion about whether or not
      .flutter-plugins-dependencies should be tracked in version control or
      not. Added a comment to both it and .flutter-plugins explaining that
      it's generated and shouldn't be.
      
      .flutter-plugins-dependencies is parsed through JSON, and the JSON spec
      doesn't support comments. So unfortunately the note is living in an
      arbitrary "_info" key instead of an obvious top level comment.
      901eb0fc
  3. 24 Nov, 2019 1 commit
  4. 22 Nov, 2019 2 commits
  5. 21 Nov, 2019 1 commit
  6. 19 Nov, 2019 1 commit
  7. 11 Nov, 2019 1 commit
  8. 09 Nov, 2019 1 commit
    • Ian Hickson's avatar
      Deprecation cleanup in flutter_tools (#44469) · f4da9f72
      Ian Hickson authored
      One deprecated member was no longer used; removed it.
      
      The other probably shouldn't be deprecated, because it's not the
      parser that's deprecated so much as the format it's parsing. The code
      itself will live on until we decide to stop supporting the format,
      it's not like people calling the member should use something else.
      f4da9f72
  9. 07 Nov, 2019 1 commit
  10. 05 Nov, 2019 2 commits
  11. 04 Nov, 2019 1 commit
  12. 01 Nov, 2019 1 commit
  13. 29 Oct, 2019 1 commit
  14. 25 Oct, 2019 1 commit
  15. 16 Oct, 2019 1 commit
  16. 15 Oct, 2019 1 commit
  17. 04 Oct, 2019 1 commit
  18. 30 Sep, 2019 1 commit
  19. 26 Sep, 2019 1 commit
    • stuartmorgan's avatar
      Add the beginnings of plugin support for Windows and Linux (#41015) · 56d68a90
      stuartmorgan authored
      Adds very preliminary support for Windows and Linux plugins:
      - Adds those platforms to the new plugin schema, initially supporting just a plugin class.
      - Adds C++ plugin registrant generation for any Windows or Linux plugins found.
      
      This doesn't have yet have any build tooling for either platform, so anyone using the generated registrant still needs to do manual build configuration. This reduces the manual work, however, and creates a starting point for future tooling work.
      
      As with all Windows and Linux work at this time, this is not final, and subject to change without warning in the future (e.g., Windows could potentially switch to a C# interface, or
      'linux' may change to 'gtk' or 'linux_gtk' in pubspec.yaml).
      56d68a90
  20. 24 Sep, 2019 1 commit
  21. 19 Sep, 2019 1 commit
  22. 13 Sep, 2019 3 commits
  23. 11 Sep, 2019 1 commit
    • stuartmorgan's avatar
      Make Swift plugin template swift-format compliant (#40195) · ef97a69d
      stuartmorgan authored
      swift-format will alphabetize import statements, so Flutter* should be
      before Foundation. Also, separating the "Generated file" comment
      prevents the formatter from thinking that the comment is associated with
      the following import, rather than the file, if it does re-order.
      ef97a69d
  24. 06 Sep, 2019 1 commit
  25. 03 Sep, 2019 1 commit
    • Harry Terkelsen's avatar
      Automatically generated registrants for web plugins (#39628) · d33cf115
      Harry Terkelsen authored
      * WIP on web plugin registry
      
      * WIP on registering plugins
      
      * WIP on web plugin registration
      
      * Only generate `package:flutter_web_plugins` imports if plugins are
      defined
      
      * Add parsing test
      
      * Add documentation
      
      * Fix analyzer warnings
      
      * add license headers
      
      * Add tests for package:flutter_web_plugins
      
      * Run `flutter update-packages --force-upgrade`
      
      * Fix analyzer errors
      
      * Fix analyzer error in test
      
      * Update copyright and remove flutter SDK constraints
      
      * Enable tests since engine has rolled
      
      * add flutter_web_plugins tests to bots
      
      * Create an empty .packages file for WebFs test
      d33cf115
  26. 30 Aug, 2019 1 commit
  27. 28 Aug, 2019 1 commit
  28. 22 Jul, 2019 3 commits
  29. 06 Jun, 2019 1 commit
    • stuartmorgan's avatar
      Make plugins Swift-first on macOS (#33997) · 17d6f6a0
      stuartmorgan authored
      Instead of sharing the iOS codepath that uses an ObjC generated plugin
      registrant and expecting plugins to have an ObjC interface layer, switch
      to generating a Swift registrant and expecting plugins to have a Swift
      interface.
      
      This means plugins on macOS that use Swift won't need an ObjC wrapper,
      and plugins that use ObjC will need a Swift wrapper (inverting the
      structure relative to iOS).
      17d6f6a0
  30. 31 May, 2019 1 commit
    • stuartmorgan's avatar
      Implement plugin tooling support for macOS (#33636) · 3ebebebb
      stuartmorgan authored
      Enables the CocoaPods-based plugin workflow for macOS. This allows a
      macOS project to automatically fetch and add native plugin
      implementations via CocoaPods for anything in pubspec.yaml, as is done
      on iOS.
      3ebebebb
  31. 25 May, 2019 1 commit
    • stuartmorgan's avatar
      Implement macOS support in `flutter doctor` (#33277) · 81c38b22
      stuartmorgan authored
      Splits Xcode validation out of the iOS validator and into a stand-alone
      validator, and groups the CocoaPods validator with that top-level
      validator instead of the iOS validator. iOS now validates only the
      iOS-specific tools (e.g., ideviceinstaller).
      
      Reorganizes many of the associated clases so that those that are used by
      both macOS and iOS live in macos/ rather than ios/. Moves some
      validators to their own files as part of the restructuring.
      
      This is the macOS portion of #31368
      81c38b22
  32. 24 May, 2019 1 commit
    • stuartmorgan's avatar
      Add macosPrefix to the pubspec schema for plugins (#33287) · 0f6e4e61
      stuartmorgan authored
      Adds a new macosPrefix, which serves the same purpose as iosPrefix but
      for macOS plugins.
      
      It is not yet used by the tooling, but this allows for plugins to start
      to be written using it in preparation for tooling support for plugins.
      
      Part of #32718
      0f6e4e61
  33. 22 Apr, 2019 1 commit
  34. 05 Apr, 2019 1 commit