- 27 Apr, 2021 1 commit
-
-
Matej Knopp authored
-
- 05 Mar, 2021 1 commit
-
-
Andre authored
-
- 15 Jan, 2021 1 commit
-
-
Niklas Schulze authored
-
- 22 Dec, 2020 1 commit
-
-
J-P Nurmi authored
-
- 30 Oct, 2020 1 commit
-
-
George Wright authored
-
- 15 Oct, 2020 1 commit
-
-
Jay Freeman (saurik) authored
-
- 17 Sep, 2020 3 commits
-
-
stuartmorgan authored
Removes the template version from the Windows template; the API and tooling boundary will now be considered stable, so there will no longer be frequent breaking changes. Also updates the link for adding desktop support to a project for all three platforms to reflect the current location. Fixes https://github.com/flutter/flutter/issues/52748
-
stuartmorgan authored
The engine now has an explicit API for system font changes, rather than expecting the WM_FONTCHANGE message to be forwarded to the Flutter view.
-
stuartmorgan authored
Adds a VERSIONINFO to Runner.rc in the Windows app template, populated from the project creation metadata. Currently the version itself is hard-coded, but it is future-proofed to allow plumbing the actual version through at build time via preprocessor defines.
-
- 15 Sep, 2020 1 commit
-
-
stuartmorgan authored
-
- 10 Sep, 2020 1 commit
-
-
stuartmorgan authored
-
- 31 Aug, 2020 1 commit
-
-
James Clarke authored
-
- 21 Aug, 2020 2 commits
-
-
stuartmorgan authored
* Minor adjustment for engine change, and rev template version * whitespace fix
-
stuartmorgan authored
This wires up the new WindowProc delegation system that allows plugins to handle top-level window messages (e.g., to control resize behavior). Fixes #53168
-
- 14 Aug, 2020 1 commit
-
-
stuartmorgan authored
-
- 13 Aug, 2020 1 commit
-
-
stuartmorgan authored
-
- 06 Aug, 2020 1 commit
-
-
stuartmorgan authored
-
- 06 Jul, 2020 1 commit
-
-
stuartmorgan authored
* First pass at CMake files; untested * First pass of adding CMake generation logic on Windows * Misc fixes * Get bundling working, start incoprorating CMake build into tool * Fix debug, exe name. * Add resources * Move cmake.dart * Rip out all the vcxproj/solution plumbing * Fix plugin cmake generation * Build with cmake rather than calling VS directly * Adjust Windows plugin template to match standard header directory structure * Pass config selection when building * Partially fix multi-config handling * Rev template version * Share the CMake generation instead of splitting it out * VS build/run cycle works, with slightly awkward requirement to always build all * Update manifest * Plugin template fixes * Minor adjustments * Build install as part of build command, instead of separately * Test cleanup * Update Linux test for adjusted generated CMake approach * Plugin test typo fix * Add missing stub file for project test * Add a constant for VS generator
-
- 28 May, 2020 2 commits
-
-
stuartmorgan authored
PR #57749 included changes to the way the project interacts with the build process (e.g., bundling the necessary library), so should have incremented the template version to trigger the messaging to developers.
-
stuartmorgan authored
Builds and bundles an 'app.so' containing AOT data, and downloads and packages the release/profile artifacts for those builds, rather than always using the debug artifacts. Fixes https://github.com/flutter/flutter/issues/38477 Fixes https://github.com/flutter/flutter/issues/39664
-
- 21 May, 2020 1 commit
-
-
Ken VanDine authored
-
- 03 May, 2020 1 commit
-
-
stuartmorgan authored
Redirects stdout/stderr in the Windows template when creating a console. This fixes the console opened when running from Visual Studio to actually show output, instead of being empty. Fixes #53169
-
- 15 Apr, 2020 1 commit
-
-
stuartmorgan authored
Plugins, and the library, should be able to use COM without special setup. This adds COM initialization to the runner template so that it's available for any code on the main thread.
-
- 06 Apr, 2020 1 commit
-
-
stuartmorgan authored
This moves the app template more toward being a more generic starting point for any Flutter application, eliminating some hard-code assumptions about there being a single window/engine pair that is directly bound to the life of the application: - Moves the runloop into its own class, making it capable of servicing any number of engine instances. - Moves the logic for setting up a window containing only a Flutter view into a window subclass for ease of re-use. - Makes quit-on-window-close an optional property. (Long term this should be even more generic, like a quit-when-last-window-closes option, but this is a short-term improvement that removes the binding between the runloop and the window). - Allows for multiple instances of Win32Window to exist without issues relating to the window class registration. Since there are getting to be a non-trivial number of files associated with the runner, this moves the source into a runner/ directory, as is already done on some other platforms. Note that creating multiple Flutter windows at the same time still doesn't work correctly even with this change, but this addresses some of the known issues, and makes it easier to test in the future (e.g., for debugging engine-level issues with multiple instances). Fixes #45397
-
- 27 Mar, 2020 1 commit
-
-
stuartmorgan authored
Updates the Windows app template to use the new DartProject API, significantly simplifying the template. Increments the template version, even though this isn't itself a breaking change, so that users will be prompted to update their projects rather than be broken later when the old API is removed.
-
- 23 Mar, 2020 1 commit
-
-
stuartmorgan authored
Adds initial support for flutter create of apps and plugins. This is derived from the current FDE example app and sample plugin, adding template values where relevant. Since the APIs/tooling/template aren't stable yet, the app template includes a version marker, which will be updated each time there's a breaking change. The build now checks that the template version matches the version known by that version of the tool, and gives a specific error message when there's a mismatch, which improves over the current breaking change experience of hitting whatever build failure the breaking change causes and having to figure out that the problem is that the runner is out of date. It also adds a warning to the create output about the fact that it won't be stable. Plugins don't currently have a version marker since in practice this is not a significant problem for plugins yet the way it is for runners; we can add it later if that changes. Fixes #30704
-