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.
When generating the plugin registrant for Linux, also generate a
makefile that can be included in the app-level Makefile to manage all of
the plugin targets and flags, exporting them in a few known variables
for use in the outer makefile.
Part of #32720
When Focus.unfocus is called, the caller usually just thinks about wanting to remove focus from the node, but really, unfocus is a request to automatically pass the focus to another (hopefully useful) node.
This PR removes the focusPrevious flag from unfocus, and replaces it with a disposition enum that indicates where the focus should go from here.
The other value of the UnfocusDisposition enum is UnfocusDisposition.scope.
UnfocusDisposition.previouslyFocusedChild is closest to what focusPrevious used to do: focus the nearest enclosing scope and use its focusedChild field to walk down the tree, finding the leaf focusedChild. This PR modifies it slightly so that it walks up to the nearest focusable enclosing scope before trying to focus the children. This change addresses #48903
A new mode: UnfocusDisposition.scope will focus the nearest focusable enclosing scope of this node without trying to use the FocusScopeNode.focusedChild value to descend to the leaf focused child. This is useful as a default for both text field finalization and for what happens when canRequestFocus is set to false. It allows the scope to stay focused so that nextFocus/previousFocus still work as expected, but removes the focus from primary focus.
In addition to those changes, unfocus called on a FocuScope that wasn't the primary focus used to unfocus the primary focus instead. I removed that behavior, since it was buggy: if the primary focus was inside of a child scope, and you called unfocus on the parent scope, then the child scope could have focused another of its children instead, leaving the scope that you called unfocus on with hasFocus returning true still. If you want to remove the focus from the primary focus instead of the scope, that's easy enough to do: just call primaryFocus.unfocus().
Fixes#48903
