1. 02 3月, 2021 1 次提交
  2. 21 9月, 2020 1 次提交
    • S
      Remove path_provider_fde (#801) · 927f8cbc
      stuartmorgan 提交于
      Removes path_provider_fde, since path_provider now supports Windows.
      
      flutter_plugins is no longer needed as a concept since the APIs have stabilized
      on all platforms, so this removes it entirely, and updates all the READMEs
      accordingly.
      
      All the previous-flutter_plugins-plugins have been removed from testbed, since
      there is no longer any reason to test them in this repository.
      927f8cbc
  3. 30 6月, 2020 1 次提交
  4. 24 3月, 2020 1 次提交
    • S
      Remove 'example' and 'sample' (#701) · 8e658651
      stuartmorgan 提交于
      Now that flutter create has support for all three desktop platforms, neither example/ nor plugins/sample are necessary. This removes both, and all discussion of using them as the basis for creating new apps or plugins.
      8e658651
  5. 04 3月, 2020 1 次提交
  6. 28 2月, 2020 1 次提交
    • S
      Use generated plugin makefile on Linux (#686) · 888f5888
      stuartmorgan 提交于
      The Flutter tool now generates a makefile suitable for inclusion in the
      main makefile that adds all the necessary plugin flags and targets.
      This switches to using that new system.
      
      The header copy step is removed from the plugins, since the
      generated makefile adds the necessary include paths.
      
      Linux plugins no longer require manual build integration, so
      those instructions are removed. Since there's now no need
      for instructions in most cases, this removes most of the plugin
      instructions. The sections about building plugins manually
      are removed since there's no evidence that people are doing
      manual add-to-app experimentation at this point, and it's
      not something that we're supporting enough to encourage
      it with partial instructions. The result is a much simpler set
      of plugin instructions, which should be more approachable.
      888f5888
  7. 26 2月, 2020 2 次提交
    • S
      Update plugin readme · 92d1af60
      stuartmorgan 提交于
      Remove obsolete reference to Windows plugins copying headers to the output directory
      92d1af60
    • S
      Regenerate testbed solution from tool (#684) · b2677205
      stuartmorgan 提交于
      Regenerates the testbed solution's plugin integration using
      flutter/flutter#51246. Other than adding the
      Flutter Plugins folder, it just ends up reordering some of the
      entries.
      b2677205
  8. 15 2月, 2020 3 次提交
    • S
      Remove accidental fragment from plugin README · 6c78f9bc
      stuartmorgan 提交于
      6c78f9bc
    • S
      Fix Windows plugin instructions · 9848d885
      stuartmorgan 提交于
      9848d885
    • S
      Switch Windows to generated plugin properties (#671) · 9eca7ca7
      stuartmorgan 提交于
      Use the new generated plugin integration property sheet, rather than the
      hand-written ones. Since the generated version has include paths for all
      plugins, this means plugins no longer need to copy their headers into
      a build output directory, simplifying the projects and removing a potential
      failure point.
      
      Also updates all projects to use AdditionalIncludeDirectories and
      AdditionalLibraryDirectories instead of IncludePath and LibraryPath.
      This makes them consistent with the generated files, and with
      what appears to be the preferred practice (the *Path versions use
      environment variables, and are apparently legacies of earlier
      VS build system designs, rather than flags passed to the
      compiler and linker).
      9eca7ca7
  9. 14 2月, 2020 2 次提交
    • S
      Update plugin README · 33dc7bde
      stuartmorgan 提交于
      Now that all platforms have symlinks, there's no need to use path-based dependencies in pubspec.yaml.
      33dc7bde
    • S
      Use plugin symlinks on Windows and Linux (#670) · d01a4f56
      stuartmorgan 提交于
      Switches Windows and Linux to using the new plugin symlinks. This eliminates
      the need for project files/makefiles to have developer-specific paths
      (especially if pulled via pub).
      
      Now that the plugin plumbing is mostly generic for Linux, most of it in moved
      into the example Makefile so that the changes necessary to use plugins are
      much more targeted. Updates the documentation for using plugins on Linux
      to be more specific now that the process is more straightforward.
      
      Part of #578
      d01a4f56
  10. 30 1月, 2020 1 次提交
    • S
      Overhaul example plugin, and rename it 'sample' (#654) · 1eac3065
      stuartmorgan 提交于
      Renames the plugin from 'example_plugin' to 'sample' so that the naming is
      consistent with all the actual plugins (which have 'plugin' in the class name,
      but not the actual plugin name).
      
      Also makes various improvements to the sample code and documentation,
      as described in the associated bug.
      
      Fixes #648
      1eac3065
  11. 17 1月, 2020 1 次提交
  12. 24 12月, 2019 1 次提交
  13. 15 12月, 2019 1 次提交
  14. 05 11月, 2019 1 次提交
  15. 28 9月, 2019 1 次提交
  16. 27 9月, 2019 1 次提交
    • S
      Update plugin README · 5b75ebab
      stuartmorgan 提交于
      Make the instructions for using plugins more specific to
      the FDE example proto-template, and more detailed about the
      necessary steps.
      
      More work is needed for both Linux and Windows to make the
      process easier to follow.
      5b75ebab
  17. 20 9月, 2019 1 次提交
    • S
      Update plugin README for macOS template support · 4e25c5be
      stuartmorgan 提交于
      Other minor changes:
      - Mention git references as an option for macOS.
      - Update Windows instructions to reference plugin_registrant.cpp
      
      (Windows and Linux still better instructions on how to update example/
      to add plugins, rather than having more generic instructions that are
      not going to be as useful to most people.)
      4e25c5be
  18. 18 6月, 2019 1 次提交
    • S
      Add desktop implementation of url_launcher from flutter/plugins (#433) · adb9052b
      stuartmorgan 提交于
      Sets up a new structure and README for landing implementations of
      plugins from the flutter/plugins repository before they are ready to
      be officially hosted (e.g., while plugin APIs stabilize).
      
      Using that structure, adds an initial implementation of url_launcher
      for macOS and Linux as a proof of concept.
      
      Fixes #224 (except for Windows, for which we have #105)
      adb9052b
  19. 12 6月, 2019 1 次提交
  20. 11 6月, 2019 2 次提交
  21. 01 6月, 2019 1 次提交
    • S
      Podify all macOS plugins (#412) · 08fcf25c
      stuartmorgan 提交于
      Converts all the macOS implementations of plugins to be pods. Removes
      the projects and framework-related files, restructures them to follow
      the Flutter plugin podspec convention, and adds podspec files.
      
      The common definitions of the channel constants are removed in this
      restructuring, since having source files that live outside the pod
      directory is problematic. This means slightly more duplication, but the
      constants should not be changing frequently (and this is a general
      problem with Flutter plugins). The documentation that was in the
      channel_constant.h files has moved to the appropirate Dart files.
      
      Since the plugins are no longer including C++ constant definitions,
      converted them to ObjC (.m) files.
      
      Testbed now builds and loads all plugins via the Flutter tooling rather
      than direct project dependencies.
      08fcf25c
  22. 30 5月, 2019 1 次提交
    • S
      Implement example_plugin for Windows (#408) · 64cb8e92
      stuartmorgan 提交于
      Adds an example_plugin implementation for Windows.
      
      As with other platforms, the current build approach is a placeholder
      which will be replaced with real dependency management in the future.
      For now, the structure is that the plugin project is designed to only be
      buildable from a Runner.sln; it uses Generated.props from the
      Runner's source directory, and it builds into the Runner's build
      directory.
      
      As with the other platforms, this does not have dependencies on the rest
      of FDE, should should be copyable as a starting point for making other
      experimental plugins on Windows.
      
      Also updates the plugin README to reflect that Windows now has an
      example, and does some minor cleanup (e.g., standardizing example
      code on using the example plugin).
      
      Fixes #357
      64cb8e92
  23. 23 5月, 2019 1 次提交
    • S
      Migrate Linux plugins to make, and remove GN (#394) · d524e88e
      stuartmorgan 提交于
      Updates the existing Linux plugins to use 'make', using slightly modified
      copies of the example_plugin Makefile. As part of that change, restructures
      the Linux plugin sources to remove the src/ and include/... structure since
      it was a legacy of older structures (C++ namespaces expressed via folder
      name, direct inclusion of headers from the tree rather than the build output).
      
      This moves the plugins a small step closer to what actual Linux plugin
      development will look like (since to the extent that there is any build
      logic in plugins themselves on Linux, the template would almost certainly
      use Makefiles rather than GN).
      
      This removes the last use of GN, so all the GN infrastructure is removed
      from the project as well.
      
      Fixes #392
      d524e88e
  24. 16 5月, 2019 1 次提交
    • S
      Add engine_override instructions to plugins README · c8f53e4c
      stuartmorgan 提交于
      The top-level local engine instructions were removed when all platforms
      gained --local-engine support in the flutter tooling, but since that doesn't
      apply to plugins the instructions are still needed for plugin builds that
      need a local engine.
      c8f53e4c
  25. 26 4月, 2019 1 次提交
  26. 21 4月, 2019 2 次提交
  27. 09 4月, 2019 1 次提交
  28. 08 4月, 2019 1 次提交
    • S
      Use the prebuilt shells on Windows and Linux (#318) · 909e7985
      stuartmorgan 提交于
      - Removes the library/ directory, since all that code has migrated to flutter/engine.
      - Removes some tooling that is no longer used (e.g., update_flutter_engine, fetch_glfw).
      - Updates the Windows and Linux examples to download the library directly, rather than
         rely on a GN-downloaded copy, matching macOS.
      - Moves the GN rules to download a library for use by the plugins to plugins/common,
         matching macOS.
      - Does a first pass of updating the READMEs to reflect the fact that the shells are no
         longer conceptually part of this project (including pointing to the new Flutter
         desktop wiki page).
      - Moves some information that was in library/README.md and is still useful, but not
         moved to the Flutter wiki, to other READMEs.
      
      Note: Although the Windows example now doesn't actually rely on anything built by
      GN, the include paths and the call to run the GN build remain to avoid the churn of
      removing them now and then re-adding them when plugins are added.
      909e7985
  29. 03 4月, 2019 1 次提交
  30. 08 3月, 2019 1 次提交
    • S
      Move plugin registration to a C API (#298) · 306773e5
      stuartmorgan 提交于
      Addresses the ABI issues with plugin registration by using a C API
      rather than a C++ API for registering plugins. To support that, there
      are now C handles corresponding to the primary plugin APIs (registrar,
      messenger) instead of the window pointer being used as the only handle.
      306773e5
  31. 14 2月, 2019 1 次提交
    • S
      Switch to FlutterMacOS.framework (#277) · 2a806167
      stuartmorgan 提交于
      Removes the MacOS library code, replacing it with use of the prebuilt
      FlutterMacOS.framework downloaded from the Flutter binary server.
      
      Plugin code has been updated to use the adjusted API; FLE* versions
      of many classes were removed in the migration to flutter/engine, in favor
      of sharing the existing iOS versions.
      
      What was FlutterEmbedderMac.xcodeproj exists now only as a project to
      provide a shared dependency for downloading the framework, and has been
      moved to plugins/common/macos/SharedFlutterFramework.xcodeproj.
      
      In order to avoid people thinking their apps should depend on that
      project, the example instead fetches its own copy of the framework to a
      different location. This is slightly wasteful, but simplifies
      understanding of the example.
      
      Most of the logic of update_flutter_engine.dart has been refactored
      into a helper class for sharing with the new sync_flutter_library.
      There is still some duplication in the top-level scripts, but since
      fetch_flutter_engine will be eliminated once the migration is complete
      this isn't a significant issue.
      2a806167
  32. 01 2月, 2019 1 次提交
    • S
      [linux] Switch to GN, and remove Makefiles (#261) · 34da3ad8
      stuartmorgan 提交于
      For the library and plugins, switch to GN as the only supported build
      system on Linux. GN will be used for the library in the flutter/engine
      repository, so the make build will no longer be necessary; remove it now
      to avoid the overhead of maintaining an extra build system until the
      transition happens.
      
      The example continues to use Make in order to show typical usage of the
      library, and the color_panel plugin has an example makefile (updated to
      reflect the use of GN to build the library) as an example/starting point
      for someone making a plugin outside of the FDE repository.
      
      Addresses #114 for Linux.
      34da3ad8
  33. 23 1月, 2019 1 次提交
    • S
      Restructure the example app (#242) · 3c276ec3
      stuartmorgan 提交于
      * Re-organize the example app
      
      Instead of making the platform implementations peers of the example
      Flutter application, make them subdirectories of it. This matches the
      structure of a standard Flutter application's mobile implementations,
      and provides a better example of how to use the project to add desktop
      support to an existing Flutter app.
      
      Since interest so far has been for that use case rather than adding
      Flutter to an existing application (and the current Linux and Windows
      implementations don't really support the hybrid use case anyway), this
      should be more reflective of how it would actually be used.
      
      * Move Linux build output under example/build/
      3c276ec3
  34. 14 10月, 2018 1 次提交
    • S
      Restructure the repository to make platform secondary (#137) · 8868927b
      stuartmorgan 提交于
      Flips the structure of the repository so that instead of top-level platform directories each containing library and example directories, those two become top-level and the platform divisions are underneath them.
      
      This has several advantages:
      - There's a much clearer path to sharing code between platforms in the library (e.g., plugin code on Windows and Linux should be largely the same)
      - It's better suited to a cross-platform build system (i.e., GN).
      - It better groups the example code that's not actually needed by a client, especially the previously-top-level Flutter example application.
      8868927b