Implements focus traversal for desktop platforms, including re-implementing the existing focus manager and focus tree.
This implements a Focus widget that can be put into a widget tree to allow input focus to be given to a particular part of a widget tree.
It incorporates with the existing FocusScope and FocusNode infrastructure, and has minimal breakage to the API, although FocusScope.reparentIfNeeded is removed, replaced by a call to FocusAttachment.reparent(), so this is a breaking change:
FocusScopeNodes must now be attached to the focus tree using FocusScopeNode.attach, which takes a context and an optional onKey callback, and returns a FocusAttachment that should be kept by the widget that hosts the FocusScopeNode. This is necessary because of the need to make sure that the focus tree reflects the widget hierarchy.
Callers that used to call FocusScope(context).reparentIfNeeded in their build method will call reparent on a FocusAttachment instead, which they will obtain by calling FocusScopeNode.attach in their initState method. Widgets that own FocusNodes will need to call dispose on the focus node in their dispose method.
Addresses #11344, #1608, #13264, and #1678Fixes#30084Fixes#26704
* Added support for authentication codes for the VM service.
Previously, a valid web socket connection would use the following URI:
`ws://127.0.0.1/ws`
Now, by default, the VM service requires a connection to be made with a
URI similar to the following:
`ws://127.0.0.1:8181/Ug_U0QVsqFs=/ws`
where `Ug_U0QVsqFs` is an authentication code generated and shared by
the
service.
This behavior can be disabled with the `--disable-service-auth-codes`
flag.
Previously, I used the Android emulator for testing and everything
seemed to work fine with stdout (if I remember correctly). But our
devicelab uses real Android devices and the warnings are routed to
stderr. Hence change stdout to stderr in the test.
## Description
Print actionable warnings if `flutter drive` (where most of our performance benchmarks come from) is run in debug mode and it tries to gather benchmarks using `traceAction`.
## Related Issues
https://github.com/flutter/flutter/issues/30625
## Tests
I added the following tests:
* drive_perf_debug_warning devicelab test
updates the regex the analyzer uses, so it should be able to recognize expressions such as
const Foo a = Foo(); as "other code" rather than a constructor call.
When we package Flutter, we used to find the "current" tag (which is the version number) by starting at the revision we are building on and looking backwards in time to find the most recent tag. This causes problems on release builds when we failed to tag properly.
This PR makes the packaging script be more strict by requiring the given revision to itself have a tag, but only when we're publishing the result. When we're not publishing the result, it's more lenient, since otherwise we couldn't test packaging on non-release commits.
I also renamed ProcessRunnerException to PreparePackageException, since we were using that exception more generally than just for processes.
* add trailing commas on list/map/parameters
* add trailing commas on Invocation with nb of arg>1
* add commas for widget containing widgets
* add trailing commas if instantiation contains trailing comma
* revert bad change
## Description
This moves another 15-20ms from the animation jank of one of our important client to the startup latency. Unfortunately, this is probably not captured in our current benchmarks (presumably some other bottlenecks overshadow this shader compilation in the worst_frame benchmark). Considering that drawing images is such a common operation, maybe we should add one in the future to benchmark this.
We need this PR to land soon for our client because this changes the API to return Future.
## Related Issues
https://github.com/flutter/flutter/issues/813
## Description
Also update the existing dart files with missing licenses.
Without the fix, we'll emit the following error message
```
License headers cannot be found at the beginning of the following files.
/usr/local/google/home/liyuqian/flutter/flutter/packages/flutter/lib/src/animation/tween_sequence.dart
/usr/local/google/home/liyuqian/flutter/flutter/packages/flutter/test/material/raw_material_button_test.dart
/usr/local/google/home/liyuqian/flutter/flutter/packages/flutter/test/widgets/async_lifecycle_test.dart
/usr/local/google/home/liyuqian/flutter/flutter/packages/flutter/test/widgets/sliver_constraints_test.dart
/usr/local/google/home/liyuqian/flutter/flutter/packages/flutter/test/widgets/app_test.dart
/usr/local/google/home/liyuqian/flutter/flutter/packages/flutter/test/widgets/test_border.dart
/usr/local/google/home/liyuqian/flutter/flutter/packages/flutter/test/widgets/physical_model_test.dart
/usr/local/google/home/liyuqian/flutter/flutter/packages/flutter/test/widgets/inherited_model.dart
/usr/local/google/home/liyuqian/flutter/flutter/packages/flutter_tools/lib/src/base/user_messages.dart
/usr/local/google/home/liyuqian/flutter/flutter/packages/flutter_tools/test/src/pubspec_schema.dart
/usr/local/google/home/liyuqian/flutter/flutter/packages/flutter_tools/test/ios/simulators_test.dart
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
```
## Related Issues
Fixes https://github.com/flutter/flutter/issues/28368
## Checklist
Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes (`[x]`). This will ensure a smooth and quick review process.
- [x] I read the [Contributor Guide] and followed the process outlined there for submitting PRs.
- [x] My PR includes tests for *all* changed/updated/fixed behaviors (See [Test Coverage]).
- [x] All existing and new tests are passing.
- [x] I updated/added relevant documentation (doc comments with `///`).
- [x] The analyzer (`flutter analyze --flutter-repo`) does not report any problems on my PR.
- [x] I read and followed the [Flutter Style Guide], including [Features we expect every widget to implement].
- [x] I signed the [CLA].
- [x] I am willing to follow-up on review comments in a timely manner.
## Breaking Change
Does your PR require Flutter developers to manually update their apps to accommodate your change?
- [ ] Yes, this is a breaking change (Please read [Handling breaking changes]).
- [x] No, this is *not* a breaking change.
<!-- Links -->
[issue database]: https://github.com/flutter/flutter/issues
[Contributor Guide]: https://github.com/flutter/flutter/wiki/Tree-hygiene#overview
[Test Coverage]: https://github.com/flutter/flutter/wiki/Test-coverage-for-package%3Aflutter
[Flutter Style Guide]: https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo
[Features we expect every widget to implement]: https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo#features-we-expect-every-widget-to-implement
[CLA]: https://cla.developers.google.com/
[Handling breaking changes]: https://github.com/flutter/flutter/wiki/Tree-hygiene#handling-breaking-changes
Adds SHA256 checksums to the released package database, in preparation for showing them on the download website. (I'll update the existing data by hand).
Fixes#28465
This patch adds a default shader warm up process which moves shader compilation from the animation time to the startup time. This also provides an extension for `runApp` so developers can customize the warm up process.
This should reduce our worst_frame_rasterizer_time_millis from ~100ms to ~20-30ms for both flutter_gallery and complex_layout benchmarks. Besides, this should also have a significant improvement on 90th and 99th percentile time (50%-100% speedup in some cases, but I haven't tested them thoroughly; I'll let our device lab collect the data afterwards).
The tradeoff the is the startup time (time to first frame). Our `flutter run --profile --trace-startup` seems to be a little noisy and I see about 100ms-200ms increase in that measurement for complex_layout and flutter_gallery. Note that this only happens on the first run after install or data wipe. Later the Skia persistent cache will remove the overhead.
This also adds a cubic_bezier benchmark to test the custom shader warm up process.
This should fix https://github.com/flutter/flutter/issues/813 (either by `defaultShaderWarmUp`, or a `customShaderWarmUp`).
This fixes the offline Dash/Zeal docs generation to use the newly added dartdoc markers for different entity types to make it more exact when finding entity names.
Bumped Dartdoc to the next release.
This converts all remaining "## Sample code" segments into snippets, and fixes
the snippet generator to handle multiple snippets in the same dartdoc block
properly.
I also generated, compiled, and ran each of the existing application samples,
and fixed them up to be more useful and/or just run without errors.
This PR fixes these problems with examples:
1. Switching tabs in a snippet now works if there is more than one snippet in
a single dartdoc block.
2. Generation of snippet code now works if there is more than one snippet.
3. Contrast of text and links in the code sample block has been improved to
recommended levels.
4. Added five new snippet templates, including a "freeform" template to make
it possible to show examples that need to change the app instantiation.
5. Fixed several examples to run properly, a couple by adding the "Scaffold"
widget to the template, a couple by just fixing their code.
6. Fixed visual look of some of the samples when they run by placing many
samples inside of a Scaffold.
7. In order to make it easier to run locally, changed the sample analyzer to
remove the contents of the supplied temp directory before running, since
having files that hang around is problematic (only a problem when running
locally with the `--temp` argument).
8. Added a `SampleCheckerException` class, and handle sample checking
exceptions more gracefully.
9. Deprecated the old "## Sample code" designation, and added enforcement for
the deprecation.
10. Removed unnecessary `new` from templates (although they never appeared in
the samples thanks to dartfmt, but still).
Fixes#26398Fixes#27411
This makes Android raw key event handling use the "character" data coming from the engine properly, and gets rid of the "toLowerCase" hack that I was using to normalize logical key events, in favor of using the new "plainCodePoint" that has the unmodified code point (the code point as if no modifier keys were pressed).
This adds support for logical and physical key information inside of RawKeyEvent. This allows developers to differentiate keys in a platform-agnostic way. They are able to tell the physical location of a key (PhysicalKeyboardKey) and a logical meaning of the key (LogicalKeyboardKey), as well as get notified of the character generated by the keypress. All of which is useful for handling keyboard shortcuts.
This PR builds on the previous PR (#27620) which generated the key code mappings and definitions.
Now the sample analyzer can be run locally with:
dart dev/bots/analyze-sample-code.dart --temp=/tmp/samples
And it leaves /tmp/samples around so you can take a look at the code that was generated to see if it's the artificial environment that the samples are evaluated in that is the culprit for a failed analysis.
Before, you had to specify the whole path to the dart executable, and had to modify the code to keep the tempdir around.
This adds a keycode generator that incorporates input from the Chromium and Android source trees, as well as some local tables, to generate static constants for the LogicalKeyboardKey and PhysicalKeyboardKey classes, as well as mappings from each of the platforms we support so far (currently only Android and Fuchsia).
This code generator parses the input files, generates an intermediate data structure (`key_data.json`) that is checked in, and then generates the Dart sources for these classes and some static maps that will also be checked in (but are not included in this PR).
The idea is that these codes don't change often, and so we don't need to generate them on every build, but we would like to be able to update them easily in the future if new data becomes available. If the existing data disappears or becomes unusable, we can maintain the checked-in data structure by hand if necessary, and still be able to generate the code.
This PR only contains the code generator, not the classes themselves. In another follow-on PR, I'll run the generator and check in the output of the generator.
Before this, we had several places where an isReleaseMode was defined, all with the same definition. This just makes it more broadly visible to allow our users to use it, as well as creating debug and profile versions, and adding a device lab test for it.
Since this is a const value, this makes it possible for a developer to easily mark blocks that can be removed at AOT compile time.
This changes the DocSetPlatformFamily key to be "dartlang" instead of the name of the package (usually "flutter"). This is so that the IntelliJ plugin for Dash will be able to go directly to the docs for a symbol from a keystroke, instead of needing to search all the docsets each time.
Without this, flutter isn't part of the list of package names it searches. After this, it finds the flutter docs because they're declared to be part of the "dartlang" family of docs.
Dashing doesn't have a way to configure this, so we modify the Info.plist directly to make the change.
* move flutter_assets to App.framework
* Roll engine to 05fee4eeee0ff6b219b1fcc394371e5f6963cc46
05fee4eee Update default flutter_assets path for iOS embedding (flutter/engine#7518)
02205db01 Roll src/third_party/skia 5d052dac3ac1..02738a86e5fd (4 commits) (flutter/engine#7541)
af907c074 Roll src/third_party/skia 5c7a3ac0e214..5d052dac3ac1 (7 commits) (flutter/engine#7540)
dde286673 IWYU to get SkFontMetrics (flutter/engine#7539)
These are essentially self-inflicted race conditions. Instead of timeouts we're going to try a more verbose logging mechanism that points out when things are taking a long time.
This was causing analysis to fail when there was an import statement in a comment, such as when snippets add imports to their examples.
I narrowed the RegExp to match only those lines which aren't commented out, but it really should probably be using the analysis server to catch all cases (e.g. if someone put the doc comment into /** */ comments, it could still match). Since this is a Flutter-specific script, it's probably not worth doing that.
This adds some functions to the interface for RawKeyEventData and all subclasses that allow the recipient of an event to determine which modifier keys are currently being pressed without needing to know the specific modifier bitmasks for the platform.
Also adds constants for the modifier bitmasks for each platform, for completeness (and because I needed them anyhow to implement the above).
Added tests for the RawKeyEventData subclasses, and modified the raw_keyboard manual test app to show modifier keys being pressed. I also separated the different platform-specific subclasses into separate files.
Fixes#26155.
