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
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.
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
Adds a VisualDensity.adaptivePlatformDensity static function that returns different values for visual density based on the defaultTargetPlatform. Returns compact for desktop platforms, and a default visual density for other platforms.
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.
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
Adds initial support for `flutter create` of apps and plugins. This is derived from the current FDE example app and sample plugin, with a few changes:
- Added template values where it makes sense.
- Moved some likely-to-change values into separate files for now, to simplify the delete/recreate cycle that will be necessary until it's stable.
- Added some minor Makefile flag handling improvements
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.
* Move embedding and linking Flutter frameworks into the tool
* Unused import
* Migrate
* Rename run, add comments, remove typedef
* Add status log to tell the user what we did
* Remove Podfile migration, create IOSMigration superclass
* word-smiting
Co-Authored-By: Jonah Williams <jonahwilliams@google.com>
* for space
Co-Authored-By: Jonah Williams <jonahwilliams@google.com>
Co-authored-by: Jonah Williams <jonahwilliams@google.com>
This PR adds the linux and windows target platform enum values, along with automatically setting the defaultTargetPlatform to the appropriate value on those platforms.
Fixes#31366
Now that the new schema is supported on the stable channel, and the old
schema is considered legacy, the template should always create plugins
using the new schema.
Now that the new schema is supported on the stable channel, and the old
schema is considered legacy, the template should always create plugins
using the new schema.
