✒ Spell Check All .md Files Related to Flutter 💙 (#61564)
* 🐛 Fix Spelling Issues in Main README.md * 🐛 Fix spelling issues in dev README.md * 🐛 Fix spelling issues in complex_layout README.md * 🐛 Fix spelling issues in macrobenchmarks README.md * 🐛 Fix spelling issues in platform_views_layout README.md * 🐛 Fix spelling issues in test_Apps/stocks README.md * 🐛 Fix spelling issues in bots README.md * ✒ Spell Check dev/ci README.md * ✒ Spell Check dev/ci/docker_linux README.md * ✒ Spell Check dev/devicelab README.md * ✒ Spell Check dev/docs README.md * ✒ Spell Check dev/snippets README.md * ✒ Spell Check dev/snippets/config/templates README.md * ✒ Spell Check dev/tools/gen_keycodes README.md * ✒ Spell Check dev/tools/vitool README.md * ✒ Spell Check examples/catalog README.md * ✒ Spell Check examples/flutter_view README.md * ✒ Spell Check examples/image_list README.md * ✒ Spell Check examples/layers README.md * ✒ Spell Check examples/platform_channel README.md * ✒ Spell Check examples/platform_channel_swift README.md * ✒ Spell Check examples/platform_view README.md * ✒ Spell Check packages/_flutter_web_build_script README.md * ✒ Spell Check packages/flutter_localizations README.md * ✒ Spell Check packages/flutter_tools README.md * ✒ Spell Check CODE_OF_CONDUCT.md * ✒ Spell Check dev/integration_test/android_splash_screens/splash_Screen_load_rotate README.md * ✒ Spell Check dev/integration_test/android_views README.md * ✒ Spell Check dev/integration_tests/flutter_driver_screenshot_test README.md * ✒ Spell Check dev/integration_tests/flutter_gallery README.md * ✒ Spell Check dev/integration_tests/gradle_deprecated_settings README.md * ✒ Spell Check dev/integration_tests/ios_add2app_life_cycle README.md * ✒ Spell Check dev/integration_tests/ios_host_app README.md * ✒ Spell Check dev/integration_tests/ios_platform_view_tests README.md * ✒ Spell Check dev/automated_tests/flutter_test README.md * ✒ Spell Check .github/PULL_REQUEST_TEMPLATE.md * ✒ Spell Check .hithub/ISSUE_TEMPLATE/ACTIVATION.md * ✒ Spell Check .github/ISSUE_TEMPLATE/BUG.md * ✒ Spell Check .github/ISSUE_TEMPLATE/feature_request.md * ✒ Spell Check .github/ISSUE_TEMPLATE/performance_others.md * ✒ Spell Check .github/ISSUE_TEMPLATE/performance_speed.md * ✒ Spell Check packages/flutter_tools/doc/daemon.md * ✒ Spell Check packages/flutter_tools/fuchsia_enrtypoint_shim/README.md * ✒ Minimize line to 80 columns * ✒ Minimize line to 80 columns * ✒ Fix Typo * ✒ Chnaged numbers to 1 for testing purposes * ✒ Changed numbers to 1 for testing purposes * ❌ Remove 'a' which is a typo * ✒ Change a sentence to be better * ✒ Remove 'a' which is a typo * ✒ Fix small issue * ✒ Fix small typo * ✒ Fix some typos * ❌ Remove trailing space * ❌ Remove trailing space * 🐛 Fix small typo * ✒ Fix Typo * 🐛 Fix small bug
This commit is contained in:
Yazeed Al-Khalaf
@@ -1,7 +1,7 @@
|
||||
This directory contains tools and resources that the Flutter team uses
|
||||
during development of the framework. The tools in this directory
|
||||
during the development of the framework. The tools in this directory
|
||||
should not be necessary for developing Flutter applications, though of
|
||||
course they may be interesting if you are curious.
|
||||
course, they may be interesting if you are curious.
|
||||
|
||||
The tests in this directory are run in the `framework_tests_misc-*`
|
||||
shards.
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
The files in this directory are used as part of tests in the
|
||||
The files in this directory are used as part of the tests in the
|
||||
`flutter_tools` package. Some are here because here these tests need a
|
||||
`pubspec.yaml` that references the flutter framework (which is
|
||||
intentionally not true of the `flutter_tools` package). Others are
|
||||
here mostly out of peer pressure.
|
||||
here mostly out of peer pressure.
|
||||
@@ -21,6 +21,6 @@ To measure startup time on a device:
|
||||
flutter run --profile --trace-startup
|
||||
```
|
||||
|
||||
Results should be in the logs.
|
||||
The results should be in the logs.
|
||||
|
||||
Additional results should be in the file `build/start_up_info.json`.
|
||||
|
||||
@@ -4,6 +4,33 @@ Performance benchmarks use either flutter drive or the web benchmark harness.
|
||||
|
||||
## Mobile benchmarks
|
||||
|
||||
### Cull opacity benchmark
|
||||
|
||||
To run the cull opacity benchmark on a device:
|
||||
|
||||
```
|
||||
flutter drive --profile test_driver/cull_opacity_perf.dart
|
||||
```
|
||||
|
||||
Results should be in the file `build/cull_opacity_perf.timeline_summary.json`.
|
||||
|
||||
More detailed logs should be in `build/cull_opacity_perf.timeline.json`.
|
||||
|
||||
### Cubic bezier benchmark
|
||||
|
||||
To run the cubic-bezier benchmark on a device:
|
||||
|
||||
```
|
||||
flutter drive --profile test_driver/cubic_bezier_perf.dart
|
||||
```
|
||||
|
||||
Results should be in the file `build/cubic_bezier_perf.timeline_summary.json`.
|
||||
|
||||
More detailed logs should be in `build/cubic_bezier_perf.timeline.json`.
|
||||
|
||||
### Backdrop filter benchmark
|
||||
|
||||
To run the backdrop filter benchmark on a device:
|
||||
To run a mobile benchmark on a device:
|
||||
|
||||
```
|
||||
@@ -30,7 +57,7 @@ The key `[test_name]` can be:
|
||||
|
||||
## Web benchmarks
|
||||
|
||||
Web benchmarks are compiled from the same entrypoint in `lib/web_benchmarks.dart`.
|
||||
Web benchmarks are compiled from the same entry point in `lib/web_benchmarks.dart`.
|
||||
|
||||
### How to write a web benchmark
|
||||
|
||||
@@ -39,13 +66,13 @@ as an example.
|
||||
|
||||
Choose one of the two benchmark types:
|
||||
|
||||
* A "raw benchmark" records performance metrics from direct interactions with
|
||||
- A "raw benchmark" records performance metrics from direct interactions with
|
||||
`dart:ui` with no framework. This kind of benchmark is good for benchmarking
|
||||
low-level engine primitives, such as layer, picture, and semantics performance.
|
||||
* A "widget benchmark" records performance metrics using a widget. This kind of
|
||||
- A "widget benchmark" records performance metrics using a widget. This kind of
|
||||
benchmark is good for measuring the performance of widgets, often together with
|
||||
engine work that widget-under-test incurs.
|
||||
* A "widget build benchmark" records the cost of building a widget from nothing.
|
||||
- A "widget build benchmark" records the cost of building a widget from nothing.
|
||||
This is different from the "widget benchmark" because typically the latter
|
||||
only performs incremental UI updates, such as an animation. In contrast, this
|
||||
benchmark pumps an empty frame to clear all previously built widgets and
|
||||
@@ -83,7 +110,7 @@ flutter run --profile -d web-server lib/web_benchmarks.dart
|
||||
flutter run --dart-define=FLUTTER_WEB_USE_SKIA=true --profile -d web-server lib/web_benchmarks.dart
|
||||
```
|
||||
|
||||
You can also run all benchmarks exactly like the devicelab runs them:
|
||||
You can also run all benchmarks exactly as the devicelab runs them:
|
||||
|
||||
```
|
||||
cd dev/devicelab
|
||||
|
||||
@@ -21,6 +21,6 @@ To measure startup time on a device:
|
||||
flutter run --profile --trace-startup
|
||||
```
|
||||
|
||||
Results should be in the logs.
|
||||
The results should be in the logs.
|
||||
|
||||
Additional results should be in the file `build/start_up_info.json`.
|
||||
|
||||
@@ -30,9 +30,9 @@ the tool is used to generate localizations for this app.
|
||||
|
||||
## Icon
|
||||
|
||||
Icon was created using Android Asset Studio:
|
||||
The icon was created using Android Asset Studio:
|
||||
https://romannurik.github.io/AndroidAssetStudio/icons-launcher.html#foreground.type=image&foreground.space.trim=0&foreground.space.pad=0&foreColor=607d8b%2C0&crop=0&backgroundShape=square&backColor=fff%2C100&effects=none
|
||||
|
||||
From this clipart:
|
||||
https://openclipart.org/detail/30403/tango-go-up
|
||||
Which is public domain.
|
||||
Which is in the public domain.
|
||||
|
||||
@@ -4,9 +4,9 @@ This directory exists to support building Flutter on our build infrastructure.
|
||||
|
||||
The results of such builds are viewable at:
|
||||
* https://cirrus-ci.com/github/flutter/flutter/master
|
||||
- Testing done on PRs and submitted changes on GitHub.
|
||||
- Testing is done on PRs and submitted changes on GitHub.
|
||||
* https://ci.chromium.org/p/flutter/
|
||||
- Additional testing and processing done after changes are submitted.
|
||||
- Additional testing and processing are done after changes are submitted.
|
||||
|
||||
The LUCI infra requires permissions to retrigger or schedule builds. Contact
|
||||
@kf6gpe or another Google member of the Flutter team if you need to do that.
|
||||
@@ -29,7 +29,7 @@ machines and what kind are managed internally by Google. Contact @kf6gpe or
|
||||
another Google member of the Flutter team if you suspect changes are needed
|
||||
there. Both of these technologies are highly specific to the [LUCI](https://github.com/luci)
|
||||
project, which is the successor to Chromium's infra. We're just borrowing some
|
||||
of their infrastructure.
|
||||
of their infrastructures.
|
||||
|
||||
### Prerequisites
|
||||
|
||||
@@ -39,17 +39,17 @@ To work on this infrastructure you will need:
|
||||
- Python package installer: `sudo apt-get install python-pip`
|
||||
- Python coverage package (only needed for `training_simulation`): `sudo pip install coverage`
|
||||
|
||||
To run prepare_package.dart locally:
|
||||
To run `prepare_package.dart` locally:
|
||||
|
||||
- Make sure the depot_tools is in your PATH. If you're on Windows, you also need
|
||||
an environment variable called DEPOT_TOOLS with the path to depot_tools as value.
|
||||
- Make sure the `depot_tools` is in your `PATH`. If you're on Windows, you also need
|
||||
an environment variable called `DEPOT_TOOLS` with the path to `depot_tools` as value.
|
||||
- Run `gsutil.py config` (or `python %DEPOT_TOOLS%\gsutil.py` on Windows) to
|
||||
authenticate with your auth token.
|
||||
- Create a local temp directory. `cd` into it.
|
||||
- Run `dart [path to your normal Flutter repo]/dev/bots/prepare_package.dart
|
||||
--temp_dir=. --revision=[revision to package] --branch=[branch to deploy to]
|
||||
--publish`.
|
||||
- If you're running into gsutil permission issues, check with @Hixie to make sure
|
||||
- If you're running into `gsutil` permission issues, check with @Hixie to make sure
|
||||
you have the right push permissions.
|
||||
|
||||
### Getting the code
|
||||
@@ -81,22 +81,22 @@ and
|
||||
|
||||
Recipes are just Python with some limitations on what can be imported. They are
|
||||
[documented](https://github.com/luci/recipes-py/blob/master/doc/user_guide.md)
|
||||
by the [luci/recipes-py github project](https://github.com/luci/recipes-py).
|
||||
by the [luci/recipes-py GitHub project](https://github.com/luci/recipes-py).
|
||||
|
||||
The typical cycle for editing a recipe is:
|
||||
|
||||
1. Checkout the recipes project using `git clone https://flutter.googlesource.com/recipes`.
|
||||
1. Check out the recipes project using `git clone https://flutter.googlesource.com/recipes`.
|
||||
2. Make your edits (probably to files in
|
||||
`//recipes/recipes`).
|
||||
3. Update the tests. Run `recipes.py test train` to update
|
||||
existing expected output to match the new output. Verify completely new test
|
||||
the existing expected output to match the new output. Verify completely new test
|
||||
cases by altering the `GenTests` method of the recipe. The recipe is required
|
||||
to have 100% test coverage.
|
||||
4. Run `led get-builder 'luci.flutter.prod:BUILDER_NAME' | led edit -p 'revision="GIT_HASH"' | led edit-recipe-bundle | led launch`, where `BUILDER_NAME` is the builder name (e.g. `Linux Engine`), and
|
||||
`GIT_HASH` is the hash to build (which is important for the engine but not
|
||||
for the framework).
|
||||
5. To submit a CL, you need a local branch first (`git checkout -b [some branch name]`).
|
||||
6. Upload the patch (`git commit`, `git cl upload`) and send it to someone in
|
||||
6. Upload the patch (`git commit`, `git cl upload`), and send it to someone in
|
||||
the `OWNERS` file for review.
|
||||
|
||||
### The infra config repository
|
||||
@@ -112,7 +112,7 @@ schema that describes available properties.
|
||||
|
||||
### Future Directions
|
||||
|
||||
We would like to host our own recipes instead of storing them in
|
||||
We would like to host our recipes instead of storing them in
|
||||
[build](https://chromium.googlesource.com/chromium/tools/build.git/+/master/scripts/slave/recipes/flutter).
|
||||
Support for [cross-repository
|
||||
recipes](https://github.com/luci/recipes-py/blob/master/doc/cross_repo.md) is
|
||||
@@ -123,7 +123,7 @@ tried, but it's not quite ready.
|
||||
### Android Tools
|
||||
|
||||
The Android SDK and NDK used by Flutter's Chrome infra bots are stored in Google
|
||||
Cloud. During the build a bot runs the `download_android_tools.py` script that
|
||||
Cloud. During the build, a bot runs the `download_android_tools.py` script that
|
||||
downloads the required version of the Android SDK into `dev/bots/android_tools`.
|
||||
|
||||
To check which components are currently installed, download the current SDK
|
||||
@@ -216,8 +216,8 @@ want to do, run:
|
||||
$ dart ./unpublish_package.dart --confirm --temp_dir=/tmp/foo --revision d444a455de87a2e40b7f576dc12ffd9ab82fd491
|
||||
```
|
||||
|
||||
and it will actually perform the actions. You will of course need to have access
|
||||
to the cloud storage server and have gsutil installed in order to perform this
|
||||
and it will perform the actions. You will of course need to have access
|
||||
to the cloud storage server and have `gsutil` installed to perform this
|
||||
operation. Only runs on Linux or macOS systems.
|
||||
|
||||
See `dart ./unpublish_package.dart --help` for more details.
|
||||
|
||||
@@ -11,6 +11,6 @@ to manually build and push the Docker image locally.
|
||||
|
||||
NOTE: there are some factors external to the actual `Dockerfile` that would
|
||||
necessitate rebuilding the Docker image, such as upstream code changes, (Linux
|
||||
distribution) repository updates, or a file that gets `COPY`ied into the image
|
||||
distribution) repository updates or a file that gets `COPY`ied into the image
|
||||
changing. In this case, a trivial `Dockerfile` change (such as a comment)
|
||||
would invalidate the cache and trigger a rebuild.
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
This directory includes scripts to build the docker container image used for
|
||||
building flutter/flutter in our CI system (currently [Cirrus](cirrus-ci.org)).
|
||||
|
||||
In order to run the scripts, you have to setup `docker` and `gcloud`. Please
|
||||
refer to the [internal flutter team doc](go/flutter-team) for how to setup in a
|
||||
To run the scripts, you have to set up `docker` and `gcloud`. Please
|
||||
refer to the [internal flutter team doc](go/flutter-team) for how to set up in a
|
||||
Google internal environment.
|
||||
|
||||
To debug the image locally:
|
||||
|
||||
@@ -3,7 +3,7 @@
|
||||
"Devicelab" (a.k.a. [Cocoon](https://github.com/flutter/cocoon)) is a physical
|
||||
lab that tests Flutter on real Android and iOS devices.
|
||||
|
||||
This package contains the code for test framework and the tests. More generally
|
||||
This package contains the code for the test framework and the tests. More generally
|
||||
the tests are referred to as "tasks" in the API, but since we primarily use it
|
||||
for testing, this document refers to them as "tests".
|
||||
|
||||
@@ -26,7 +26,7 @@ start the build.
|
||||
|
||||
**Task is running** (blue with clock): an agent is currently building the task.
|
||||
|
||||
**Task succeeded** (green): an agent reported a successful completion of the
|
||||
**Task succeeded** (green): an agent reported the successful completion of the
|
||||
task.
|
||||
|
||||
**Task is flaky** (yellow): the task was attempted multiple time, but only the
|
||||
@@ -37,10 +37,10 @@ latest attempt succeeded (we currently only try twice).
|
||||
**Task is rerunning** (orange): the task is being rerun.
|
||||
|
||||
**Task was skipped** (transparent): the task is not scheduled for a build. This
|
||||
usually happens when a task is removed from `manifest.yaml` file.
|
||||
usually happens when a task is removed from the `manifest.yaml` file.
|
||||
|
||||
In addition to color-coding, a task may display a question mark. This means
|
||||
that the task was marked as flaky manually. The status of such task is ignored
|
||||
that the task was marked as flaky manually. The status of such a task is ignored
|
||||
when considering whether the build is broken or not. For example, if a flaky
|
||||
task fails, GitHub will not prevent PR submissions. However, if the latest
|
||||
status of a non-flaky task is red, all pending PRs will contain a warning about
|
||||
@@ -83,7 +83,7 @@ If the task fails, the agent reports the failure to the server, the server
|
||||
increments the counter counting the number of attempts it took to run the task
|
||||
and puts the task back in the pool of available tasks. If a task does not
|
||||
succeed after a certain number of attempts (as of this writing the limit is 2),
|
||||
the task is marked as failed and is displayed using red color on the dashboard.
|
||||
the task is marked as failed and is displayed using a red color on the dashboard.
|
||||
|
||||
# Running tests locally
|
||||
|
||||
@@ -94,7 +94,7 @@ reproduce a CI test failure locally.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
You must set `ANDROID_SDK_ROOT` environment variable to run
|
||||
You must set the `ANDROID_SDK_ROOT` environment variable to run
|
||||
tests on Android. If you have a local build of the Flutter engine, then you have
|
||||
a copy of the Android SDK at `.../engine/src/third_party/android_tools/sdk`.
|
||||
|
||||
@@ -102,9 +102,9 @@ You can find where your Android SDK is using `flutter doctor`.
|
||||
|
||||
## Warnings
|
||||
|
||||
Running devicelab will do things to your environment.
|
||||
Running the devicelab will do things to your environment.
|
||||
|
||||
Notably, it will start and stop gradle, for instance.
|
||||
Notably, it will start and stop Gradle, for instance.
|
||||
|
||||
## Running all tests
|
||||
|
||||
@@ -141,10 +141,9 @@ To run multiple tests, repeat option `-t` (`--task`) multiple times:
|
||||
```
|
||||
|
||||
To run tests from a specific stage, use option `-s` (`--stage`).
|
||||
Currently there are only three stages defined, `devicelab`,
|
||||
Currently, there are only three stages defined, `devicelab`,
|
||||
`devicelab_ios` and `devicelab_win`.
|
||||
|
||||
|
||||
```sh
|
||||
../../bin/cache/dart-sdk/bin/dart bin/run.dart -s {NAME_OF_STAGE}
|
||||
```
|
||||
@@ -169,7 +168,7 @@ against a local engine build. The test runs the same benchmark a specified
|
||||
number of times against both engines, then outputs a tab-separated spreadsheet
|
||||
with the results and stores them in a JSON file for future reference. The
|
||||
results can be copied to a Google Spreadsheet for further inspection and the
|
||||
JSON file can be reprocessed with the summarize.dart command for more detailed
|
||||
JSON file can be reprocessed with the `summarize.dart` command for more detailed
|
||||
output.
|
||||
|
||||
Example:
|
||||
@@ -188,7 +187,7 @@ engine build. `--local-engine` is required for A/B test.
|
||||
`--ab-result-file=filename` can be used to provide an alternate location to output
|
||||
the JSON results file (defaults to `ABresults#.json`). A single `#` character can be
|
||||
used to indicate where to insert a serial number if a file with that name already
|
||||
exists, otherwise the file will be overwritten.
|
||||
exists, otherwise, the file will be overwritten.
|
||||
|
||||
A/B can run exactly one task. Multiple tasks are not supported.
|
||||
|
||||
@@ -286,17 +285,17 @@ your test edit `manifest.yaml` and add the following in the "tasks" dictionary:
|
||||
|
||||
Where:
|
||||
|
||||
- `{NAME_OF_TEST}` is the name of your test that also matches the name of the
|
||||
file in `bin/tasks` without the `.dart` extension.
|
||||
- `{DESCRIPTION}` is the plain English description of your test that helps
|
||||
others understand what this test is testing.
|
||||
- `{STAGE}` is `devicelab` if you want to run on Android, or `devicelab_ios` if
|
||||
you want to run on iOS.
|
||||
- `{CAPABILITIES}` is an array that lists the capabilities required of
|
||||
the test agent (the computer that runs the test) to run your test. As of writing,
|
||||
the available capabilities are: `linux`, `linux/android`, `linux-vm`,
|
||||
`mac`, `mac/ios`, `mac/iphonexs`, `mac/ios32`, `mac-catalina/ios`,
|
||||
`mac-catalina/android`, `ios/gl-render-image`, `windows`, `windows/android`.
|
||||
- `{NAME_OF_TEST}` is the name of your test that also matches the name of the
|
||||
file in `bin/tasks` without the `.dart` extension.
|
||||
- `{DESCRIPTION}` is the plain English description of your test that helps
|
||||
others understand what this test is testing.
|
||||
- `{STAGE}` is `devicelab` if you want to run on Android, or `devicelab_ios` if
|
||||
you want to run on iOS.
|
||||
- `{CAPABILITIES}` is an array that lists the capabilities required of
|
||||
the test agent (the computer that runs the test) to run your test. As of writing,
|
||||
the available capabilities are: `linux`, `linux/android`, `linux-vm`,
|
||||
`mac`, `mac/ios`, `mac/iphonexs`, `mac/ios32`, `mac-catalina/ios`,
|
||||
`mac-catalina/android`, `ios/gl-render-image`, `windows`, `windows/android`.
|
||||
|
||||
If your test needs to run on multiple operating systems, create a separate test
|
||||
for each operating system.
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
**Welcome to the Flutter API reference documentation!**
|
||||
|
||||
Flutter is Google's SDK for crafting beautiful, fast user experiences for
|
||||
mobile, web and desktop from a single codebase. Flutter works with existing
|
||||
mobile, web, and desktop from a single codebase. Flutter works with existing
|
||||
code, is used by developers and organizations around the world, and is free
|
||||
and open source.
|
||||
|
||||
@@ -58,7 +58,7 @@ import 'package:file/local.dart';
|
||||
|
||||
Flutter has a rich ecosystem of packages that have been contributed by the
|
||||
Flutter team and the broader open source community to a central repository.
|
||||
Among the thousands of packages you'll find support for Firebase, Google
|
||||
Among the thousands of packages, you'll find support for Firebase, Google
|
||||
Fonts, hardware services like Bluetooth and camera, new widgets and
|
||||
animations, and integration with other popular web services. You can browse
|
||||
those packages at [pub.dev](https://pub.dev).
|
||||
|
||||
@@ -2,6 +2,6 @@
|
||||
|
||||
This project is an example of a splash screen that displays an animation indefinitely.
|
||||
|
||||
A never ending animation is provided as a demo so that developers can manually verify that
|
||||
A never-ending animation is provided as a demo so that developers can manually verify that
|
||||
orientation changes and other UI destruction processes do not cause issues with Flutter's splash
|
||||
system for Android.
|
||||
|
||||
@@ -11,7 +11,7 @@ This is what the app looks like:
|
||||
|
||||
|
||||
|
||||
The blue part is the embedded Android view, because it is positioned at the top
|
||||
The blue part is the embedded Android view because it is positioned at the top
|
||||
left corner, the coordinate systems for FlutterView and for the embedded view's
|
||||
virtual display has the same origin (this makes the MotionEvent comparison
|
||||
easier as we don't need to translate the coordinates).
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
# Summary
|
||||
|
||||
This tests contains an app with a main page and sub pages.
|
||||
The main page contains a list of buttons; each button leads to a designated sub page when tapped on.
|
||||
Each sub page should displays some simple UIs to screenshot tested.
|
||||
This test contains an app with a main page and subpages.
|
||||
The main page contains a list of buttons; each button leads to a designated subpage when tapped on.
|
||||
Each subpage should display some simple UIs to the screenshot tested.
|
||||
|
||||
The flutter driver test runs the app and opens each page to take a screenshot.
|
||||
|
||||
@@ -12,7 +12,7 @@ Note that new binaries can't be checked in the Flutter repo, so use [Flutter Gol
|
||||
|
||||
# Add a new page to test
|
||||
|
||||
1. Create a new class which extends `Page` and implement the UI to be tested in the `build` method.
|
||||
1. Create a new class that extends `Page` and implement the UI to be tested in the `build` method.
|
||||
2. The new class should set a static `title` and `key`
|
||||
3. Add an instance of the new class to the `_allPages` list in the `main.dart`
|
||||
4. Create a new test case similar to `"'A page with an image screenshot"` in `test_driver/main_test.dart` to run the screenshot test.
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
An older copy of the Flutter gallery demo application used for integration testing.
|
||||
|
||||
For the current Flutter gallery app sample, see this repo:
|
||||
For the current Flutter Gallery app sample, see this repo:
|
||||
https://github.com/flutter/gallery
|
||||
|
||||
## Icon
|
||||
|
||||
@@ -4,4 +4,4 @@ This project is meant to test that apps using the current `android/settings.grad
|
||||
can still be built. This project can be removed once apps have been migrated to
|
||||
this new file.
|
||||
|
||||
Issue: https://github.com/flutter/flutter/issues/54566
|
||||
Issue: https://github.com/flutter/flutter/issues/54566
|
||||
|
||||
@@ -8,7 +8,7 @@ The following functionality is currently implemented:
|
||||
|
||||
1. A regular iOS view controller (UIViewController), similar to the default
|
||||
`flutter create` template (NativeViewController.m).
|
||||
1. A FlutterViewController subclass that takes over full screen. Demos showing
|
||||
1. A FlutterViewController subclass that takes over the full screen. Demos showing
|
||||
this both from a cold/fresh engine state and a warm engine state
|
||||
(FullScreenViewController.m).
|
||||
1. A demo of pushing a FlutterViewController on as a child view.
|
||||
@@ -19,7 +19,7 @@ The following functionality is currently implemented:
|
||||
|
||||
A few key things are tested here (IntegrationTests.m):
|
||||
|
||||
1. The ability to pre-warm the engine and attach/detatch a ViewController from
|
||||
1. The ability to pre-warm the engine and attach/detach a ViewController from
|
||||
it.
|
||||
1. The ability to use platform channels to communicate between views.
|
||||
1. The ability to simultaneously run two instances of the engine.
|
||||
|
||||
@@ -17,7 +17,7 @@ interaction.
|
||||
|
||||
1. A regular iOS view controller (UIViewController), similar to the default
|
||||
`flutter create` template (NativeViewController.m).
|
||||
1. A FlutterViewController subclass that takes over full screen. Demos showing
|
||||
1. A FlutterViewController subclass that takes over the full screen. Demos showing
|
||||
this both from a cold/fresh engine state and a warm engine state
|
||||
(FullScreenViewController.m).
|
||||
1. A demo of pushing a FlutterViewController on as a child view.
|
||||
@@ -28,7 +28,7 @@ interaction.
|
||||
|
||||
A few key things are tested here (FlutterUITests.m):
|
||||
|
||||
1. The ability to pre-warm the engine and attach/detatch a ViewController from
|
||||
1. The ability to pre-warm the engine and attach/detach a ViewController from
|
||||
it.
|
||||
1. The ability to use platform channels to communicate between views.
|
||||
1. The ability to simultaneously run two instances of the engine.
|
||||
|
||||
@@ -2,8 +2,8 @@
|
||||
|
||||
A simple app contains:
|
||||
|
||||
* A home with with a button that pushes a new page into the scene.
|
||||
* A page contains a platform view, a button and a text.
|
||||
* A home with a button that pushes a new page into the scene.
|
||||
* A page contains a platform view, a button, and a text.
|
||||
* Press the button will update the text.
|
||||
|
||||
We use this app to test platform views in general such as platform view creation, destruction and thread merging(iOS only).
|
||||
We use this app to test platform views in general such as platform view creation, destruction, and thread merging(iOS only).
|
||||
|
||||
@@ -22,15 +22,15 @@ There are three kinds of code blocks.
|
||||
magically determine how to analyze, and
|
||||
|
||||
* A `dartpad` sample, which gets placed into a full-fledged application, and can
|
||||
be actually executed inline in the documentation on the web page using
|
||||
be executed inline in the documentation on the web page using
|
||||
DartPad.
|
||||
|
||||
* A `sample`, which gets placed into a full-fledged application, but isn't
|
||||
placed into DartPad in the documentation because it doesn't make sense to do
|
||||
so.
|
||||
|
||||
Ideally every sample is a DartPad sample, but some samples don't have any visual
|
||||
representation, and some just don't make sense that way (for example, sample
|
||||
Ideally, every sample is a DartPad sample, but some samples don't have any visual
|
||||
representation and some just don't make sense that way (for example, sample
|
||||
code for setting the system UI's notification area color on Android won't do
|
||||
anything on the web).
|
||||
|
||||
@@ -70,7 +70,7 @@ There are several kinds of sample code you can specify:
|
||||
|
||||
* Constructor calls, typically showing what might exist in a build method. These
|
||||
will be inserted into an assignment expression assigning to a variable of type
|
||||
"dynamic" and followed by a semicolon, for the purposes of analysis.
|
||||
"dynamic" and followed by a semicolon, for analysis.
|
||||
|
||||
* Class definitions. These start with "class", and are analyzed verbatim.
|
||||
|
||||
@@ -79,7 +79,7 @@ There are several kinds of sample code you can specify:
|
||||
individually.
|
||||
|
||||
The above means that it's tricky to include verbatim imperative code (e.g. a
|
||||
call to a method), since it won't be valid to have such code at the top level.
|
||||
call to a method) since it won't be valid to have such code at the top level.
|
||||
Instead, wrap it in a function or even a whole class, or make it a valid
|
||||
variable declaration.
|
||||
|
||||
@@ -151,7 +151,7 @@ This command is displayed as part of the sample in the API docs.
|
||||
|
||||
#### Templates
|
||||
|
||||
In order to support showing an entire app when you click on the right tab of the
|
||||
To support showing an entire app when you click on the right tab of the
|
||||
code sample UI, we have to be able to insert the `sample` or `dartpad` block
|
||||
into the template and instantiate the right parts.
|
||||
|
||||
@@ -171,7 +171,7 @@ specified template.
|
||||
|
||||
## Skeletons
|
||||
|
||||
A skeleton (in relation to this tool) is an HTML template into which the Dart
|
||||
A skeleton (concerning this tool) is an HTML template into which the Dart
|
||||
code blocks and descriptions are interpolated.
|
||||
|
||||
There is currently one skeleton for
|
||||
@@ -180,11 +180,11 @@ There is currently one skeleton for
|
||||
[snippet](config/skeletons/snippet.html) code samples, but there could be more.
|
||||
|
||||
Skeletons use mustache notation (e.g. `{{code}}`) to mark where components will
|
||||
be interpolated into the template. It doesn't actually use the mustache
|
||||
package, since these are simple string substitutions, but it uses the same
|
||||
be interpolated into the template. It doesn't use the mustache
|
||||
package since these are simple string substitutions, but it uses the same
|
||||
syntax.
|
||||
|
||||
The code block generation tools process the source input and emit HTML for
|
||||
The code block generation tools that process the source input and emit HTML for
|
||||
output, which dartdoc places back into the documentation. Any options given to
|
||||
the `{@tool ...}` directive are passed on verbatim to the tool.
|
||||
|
||||
|
||||
@@ -58,13 +58,13 @@ additional burden, since all code will also be compiled to be sure it compiles).
|
||||
|
||||
## Available Templates
|
||||
|
||||
The templates available for using as an argument to the snippets tool are as
|
||||
The templates available for use as an argument to the snippets tool are as
|
||||
follows:
|
||||
|
||||
- [`freeform`](freeform.tmpl) :
|
||||
This is a simple template for which you provide everything. It has no code of
|
||||
its own, just the sections for `imports`, `main`, and `preamble`. You must
|
||||
provide the `main` section in order to have a `main()`.
|
||||
provide the `main` section to have a `main()`.
|
||||
|
||||
### WidgetsApp Templates
|
||||
|
||||
@@ -74,14 +74,14 @@ the widgets library.
|
||||
- [`stateful_widget`](stateful_widget.tmpl) :
|
||||
The default code block will be placed as the body of the `State` object of a
|
||||
`StatefulWidget` subclass. Because the default code block is placed as the body
|
||||
of a stateful widget, you will need to implement the `build()` method, and any
|
||||
of a stateful widget, you will need to implement the `build()` method and any
|
||||
state variables. It also has a `preamble` in addition to the default code
|
||||
block, which will be placed at the top level of the Dart file, so bare
|
||||
method calls are not allowed in the preamble. The default code block is
|
||||
placed as the body of a stateful widget, so you will need to implement the
|
||||
`build()` method, and any state variables. It also has an `imports`
|
||||
section to import additional packages. Please only import things that are part
|
||||
of flutter or part of default dependencies for a `flutter create` project.
|
||||
of Flutter or part of default dependencies for a `flutter create` project.
|
||||
|
||||
- [`stateful_widget_ticker`](stateful_widget_ticker.tmpl) : Identical to the
|
||||
`stateful_widget` template, with the addition of the `TickerProviderStateMixin`
|
||||
@@ -91,12 +91,12 @@ the widgets library.
|
||||
`stateful_widget` template, except that the default code block is
|
||||
inserted as a method (which should be the `build` method) in a
|
||||
`StatelessWidget`. The `@override` before the build method is added by
|
||||
the template, so must be omitted from the sample code.
|
||||
the template so must be omitted from the sample code.
|
||||
|
||||
### MaterialApp Templates
|
||||
|
||||
These templates follow the same conventions as the `WidgetsApp` templates above, but use a
|
||||
`MaterialApp` instead. These templates import the material library.
|
||||
These templates follow the same conventions as the `WidgetsApp` templates above but use a
|
||||
`MaterialApp` instead. These templates import the material library.
|
||||
|
||||
- [`stateful_widget_material`](stateful_widget_material.tmpl)
|
||||
|
||||
@@ -125,8 +125,8 @@ These templates follow the same conventions as the `WidgetsApp` templates above,
|
||||
|
||||
### CupertinoApp Templates
|
||||
|
||||
These templates follow the same conventions as the `WidgetsApp` templates above, but use a
|
||||
`CupertinoApp` instead. These templates import the cupertino library.
|
||||
These templates follow the same conventions as the `WidgetsApp` templates above but use a
|
||||
`CupertinoApp` instead. These templates import the Cupertino library.
|
||||
|
||||
- [`stateful_widget_cupertino`](stateful_widget_cupertino.tmpl)
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
This directory contains a keycode generator that can generate Dart code for
|
||||
the `LogicalKeyboardKey` and `PhysicalKeyboardKey` classes. It draws information
|
||||
from both the Chromium and Android source bases, and incorporates the
|
||||
from both the Chromium and Android source bases and incorporates the
|
||||
information it finds in those sources into a single key database in JSON form.
|
||||
|
||||
It then generates `keyboard_key.dart` (containing the `LogicalKeyboardKey` and
|
||||
@@ -11,27 +11,27 @@ platform-specific immutable maps for translating platform keycodes and
|
||||
information into the pre-defined key values in the `LogicalKeyboardKey` and
|
||||
`PhysicalKeyboardKey` classes.
|
||||
|
||||
The `data` subdirectory contains both some local data files, and the templates
|
||||
The `data` subdirectory contains both some local data files and the templates
|
||||
used to generate the source files.
|
||||
|
||||
- `data/key_data.json`: contains the merged data from all the other sources.
|
||||
This file will be regenerated if "--collect" is specified for the
|
||||
gen_keycodes script.
|
||||
- `data/key_name_to_android_name.json`: contains a mapping from Flutter key
|
||||
names to Android keycode names (with the "KEY_" prefix stripped off).
|
||||
- `data/keyboard_key.tmpl`: contains the template for the `keyboard_key.dart`
|
||||
file. Markers that begin and end with "@@@" denote the locations where
|
||||
generated data will be inserted.
|
||||
- `data/keyboard_maps.tmpl`: contains the template for the `keyboard_maps.dart`
|
||||
file. Markers that begin and end with "@@@" denote the locations where
|
||||
generated data will be inserted.
|
||||
- `data/printable.json`: contains a mapping between Flutter key name and its
|
||||
printable character. This character is used as the key label.
|
||||
- `data/synonyms.json`: contains a mapping between pseudo-keys that represent
|
||||
other keys, and the sets of keys they represent. For example, this contains
|
||||
the "shift" key that represents either a "shiftLeft" or "shiftRight" key.
|
||||
- `data/key_data.json`: contains the merged data from all the other sources.
|
||||
This file will be regenerated if "--collect" is specified for the
|
||||
gen_keycodes script.
|
||||
- `data/key_name_to_android_name.json`: contains a mapping from Flutter key
|
||||
names to Android keycode names (with the "KEY\_" prefix stripped off).
|
||||
- `data/keyboard_key.tmpl`: contains the template for the `keyboard_key.dart`
|
||||
file. Markers that begin and end with "@@@" denote the locations where
|
||||
generated data will be inserted.
|
||||
- `data/keyboard_maps.tmpl`: contains the template for the `keyboard_maps.dart`
|
||||
file. Markers that begin and end with "@@@" denote the locations where
|
||||
generated data will be inserted.
|
||||
- `data/printable.json`: contains a mapping between Flutter key name and its
|
||||
printable character. This character is used as the key label.
|
||||
- `data/synonyms.json`: contains a mapping between pseudo-keys that represent
|
||||
other keys and the sets of keys they represent. For example, this contains
|
||||
the "shift" key that represents either a "shiftLeft" or "shiftRight" key.
|
||||
|
||||
## Running the tool
|
||||
## Running the tool
|
||||
|
||||
To run the `gen_keycodes` tool using the checked in `key_data.json` file, run
|
||||
it like so:
|
||||
@@ -59,14 +59,14 @@ checked in.
|
||||
|
||||
## Key Code ID Scheme
|
||||
|
||||
In order to provide logical keys with unique ID codes, Flutter uses a scheme
|
||||
to assign logical key codes which keeps us out of the business of minting new
|
||||
To provide logical keys with unique ID codes, Flutter uses a scheme
|
||||
to assign logical keycodes which keeps us out of the business of minting new
|
||||
codes ourselves. This only applies to logical key codes: Flutter's
|
||||
physical key codes are just defined as USB HID codes.
|
||||
|
||||
The logical codes are meant to be opaque to the user, and should never be
|
||||
unpacked for meaning, since the code scheme could change at any time, and the
|
||||
meaning is likely to be retrievable in a more reliable and correct manner from
|
||||
unpacked for meaning, since the coding scheme could change at any time and the
|
||||
meaning is likely to be retrievable more reliably and correctly from
|
||||
the API.
|
||||
|
||||
However, if you are porting Flutter to a new platform, you should follow the
|
||||
@@ -75,74 +75,74 @@ following guidelines for specifying logical key codes.
|
||||
The logical key code is a 37-bit integer in a namespace that we control and
|
||||
define. It has values in the following ranges.
|
||||
|
||||
- **0x00 0000 0000 - 0x0 0010 FFFF**: For keys that generate Unicode
|
||||
characters when pressed (this includes dead keys, but not e.g. function keys
|
||||
or shift keys), the logical key code is the Unicode code point corresponding
|
||||
to the representation of the key in the current keyboard mapping. The
|
||||
Unicode code point might not actually match the string that is generated for
|
||||
an unshifted key press of that key, for example we would use U+0034 for the
|
||||
“4 $” key in the US layout, and also the “4 ;” key in the Russian layout,
|
||||
and also, maybe less intuitively, for the “' 4 {“ in French layout (where in
|
||||
the latter case, an unshifted press gets you a ', not a 4). Similarly, the Q
|
||||
key in the US layout outputs a q in normal usage, but its code would be 0x0
|
||||
0000 0051 (U+00051 being the code for the uppercase Q).
|
||||
- **0x00 0000 0000 - 0x0 0010 FFFF**: For keys that generate Unicode
|
||||
characters when pressed (this includes dead keys, but not e.g. function keys
|
||||
or shift keys), the logical key code is the Unicode code point corresponding
|
||||
to the representation of the key in the current keyboard mapping. The
|
||||
Unicode code point might not match the string that is generated for
|
||||
an unshifted keypress of that key, for example, we would use U+0034 for the
|
||||
“4 \$” key in the US layout, and also the “4 ;” key in the Russian layout,
|
||||
and also, maybe less intuitively, for the “' 4 {“ in French layout (wherein
|
||||
the latter case, an unshifted press gets you a ', not a 4). Similarly, the Q
|
||||
key in the US layout outputs a q in normal usage, but its code would be 0x0
|
||||
0000 0051 (U+00051 being the code for the uppercase Q).
|
||||
|
||||
- **0x01 0000 0000 - 0x01 FFFF FFFF**: For keys that are defined by the [USB HID
|
||||
standard](https://www.usb.org/sites/default/files/documents/hut1_12v2.pdf),
|
||||
the key code consists of the 32 bit USB extended usage code. For
|
||||
example, the Enter key would have code 0x01 0007 0028. Only keys that fall
|
||||
into collections "Keyboard", "Keypad", and "Tablet PC System Controls" are
|
||||
considered for this API; for example, a mixing desk with multiple
|
||||
collections of volume controls would not be exposed via DOWN and UP events,
|
||||
nor would a mouse, joystick, or golf simulator control.
|
||||
- **0x01 0000 0000 - 0x01 FFFF FFFF**: For keys that are defined by the [USB HID
|
||||
standard](https://www.usb.org/sites/default/files/documents/hut1_12v2.pdf),
|
||||
the key code consists of the 32 bit USB extended usage code. For
|
||||
example, the Enter key would have code 0x01 0007 0028. Only keys that fall
|
||||
into collections "Keyboard", "Keypad", and "Tablet PC System Controls" are
|
||||
considered for this API; for example, a mixing desk with multiple
|
||||
collections of volume controls would not be exposed via DOWN and UP events,
|
||||
nor would a mouse, joystick, or golf simulator control.
|
||||
|
||||
- **0x02 0000 0000 - 0xFF FFFF FFFF**: For keys that aren't defined in USB at the
|
||||
time of implementation, but that we need to support. For example, if Flutter
|
||||
were ever ported to the Symbolics LM-2, the "thumb up" key might be given
|
||||
the code 0x14 0000 0001, where 0x14 is defined as the “Symbolics” platform
|
||||
range. Where possible, we will use specific subranges of this space to reuse
|
||||
keys from other platforms. When this is not possible, the prefix 0xFF is
|
||||
reserved for “Custom” codes. Each platform from which we take codes will get
|
||||
a unique prefix in the range 0x2-0xFE. If multiple systems define keys with
|
||||
the same usage (not the same number), then the value with the lowest prefix
|
||||
is used as the defining code.
|
||||
- **0x02 0000 0000 - 0xFF FFFF FFFF**: For keys that aren't defined in USB at the
|
||||
time of implementation, but that we need to support. For example, if Flutter
|
||||
were ever ported to the Symbolics LM-2, the "thumb up" key might be given
|
||||
the code 0x14 0000 0001, where 0x14 is defined as the “Symbolics” platform
|
||||
range. Where possible, we will use specific subranges of this space to reuse
|
||||
keys from other platforms. When this is not possible, the prefix 0xFF is
|
||||
reserved for “Custom” codes. Each platform from which we take codes will get
|
||||
a unique prefix in the range 0x2-0xFE. If multiple systems define keys with
|
||||
the same usage (not the same number), then the value with the lowest prefix
|
||||
is used as the defining code.
|
||||
|
||||
Prefixes will be:
|
||||
Prefixes will be:
|
||||
|
||||
|Code|Platform|
|
||||
|----|--------|
|
||||
|0x02| Android|
|
||||
|0x03|Fuchsia |
|
||||
|0x04|iOS |
|
||||
|0x05|macOS |
|
||||
|0x06|Linux |
|
||||
|0x07|Windows |
|
||||
|0x08|Web |
|
||||
|0xFF|Custom |
|
||||
| Code | Platform |
|
||||
| ---- | -------- |
|
||||
| 0x02 | Android |
|
||||
| 0x03 | Fuchsia |
|
||||
| 0x04 | iOS |
|
||||
| 0x05 | macOS |
|
||||
| 0x06 | Linux |
|
||||
| 0x07 | Windows |
|
||||
| 0x08 | Web |
|
||||
| 0xFF | Custom |
|
||||
|
||||
Further ranges will be added as platforms are added. The platform prefix
|
||||
does not define the platform it is used on, it is just the platform that
|
||||
decides what the value is: the codes are mapped to the same value on all
|
||||
platforms.
|
||||
Further ranges will be added as platforms are added. The platform prefix
|
||||
does not define the platform it is used on, it is just the platform that
|
||||
decides what the value is: the codes are mapped to the same value on all
|
||||
platforms.
|
||||
|
||||
- **0x100 0000 0000 - 0x1FF FFFF FFFF**: For keys that have no definition yet in
|
||||
Flutter, but that are encountered in the field, this range is used to embed
|
||||
the platform-specific keycode in an ID that must be tested for in a platform
|
||||
specific way. For instance, if a platform generates a new USB HID code 0x07
|
||||
00E8 that a Flutter app wasn’t compiled with, then it would appear in the
|
||||
app as 0x100 0007 00E8, and the app could test against that code. Yes, this
|
||||
also means that once they recompile with a version of Flutter that supports
|
||||
this new HID code, apps looking for this code will break. This situation is
|
||||
only meant to provide a fallback ability for apps to handle esoteric codes
|
||||
that their version of Flutter doesn’t support yet. The prefix for this code
|
||||
is the platform prefix from the previous sections, plus 0x100.
|
||||
|
||||
- **0x200 0000 0000 - 0x2FF FFFF FFFF**: For pseudo-keys which represent
|
||||
combinations of other keys, and conceptual keys which don't have a physical
|
||||
representation. This is where things like key synonyms are defined (e.g.
|
||||
"shiftLeft" is a synonym for "shift": the "shift" key is a pseudo-key
|
||||
representing either the left or right shift key).
|
||||
- **0x100 0000 0000 - 0x1FF FFFF FFFF**: For keys that have no definition yet in
|
||||
Flutter, but that are encountered in the field, this range is used to embed
|
||||
the platform-specific keycode in an ID that must be tested for in a
|
||||
platform-specific way. For instance, if a platform generates a new USB
|
||||
HID code 0x07 00E8 that a Flutter app wasn’t compiled with, then it would
|
||||
appear in the app as 0x100 0007 00E8, and the app could test against that
|
||||
code. Yes, this also means that once they recompile with a version of
|
||||
Flutter that supports this new HID code, apps looking for this code will
|
||||
break. This situation is only meant to provide a fallback ability for apps
|
||||
to handle esoteric codes that their version of Flutter doesn’t support yet.
|
||||
The prefix for this code is the platform prefix from the previous sections,
|
||||
plus 0x100.
|
||||
|
||||
- **0x200 0000 0000 - 0x2FF FFFF FFFF**: For pseudo-keys which represent
|
||||
combinations of other keys, and conceptual keys which don't have a physical
|
||||
representation. This is where things like key synonyms are defined (e.g.
|
||||
"shiftLeft" is a synonym for "shift": the "shift" key is a pseudo-key
|
||||
representing either the left or right shift key).
|
||||
|
||||
**This is intended to get us out of the business of defining key codes where
|
||||
possible.** We still have to have mapping tables, but at least the actual minting
|
||||
@@ -164,7 +164,7 @@ UP, code 0x0000000059 (Y UP)<br>
|
||||
UP, code 0x01000700E1 (LEFT SHIFT UP)<br>
|
||||
|
||||
Here's another example. On a German keyboard layout, you press ^e (the ^ key is
|
||||
at the top left of the keyboard and is a dead key) to produce a “ê”:
|
||||
at the top left of the keyboard and is a dead key) to produce an “ê”:
|
||||
|
||||
DOWN, code 0x0000000302 (CIRCUMFLEX DOWN) It produces no string, because it's a dead
|
||||
key. The key code is for "Combining circumflex accent U+0302" in Unicode.<br>
|
||||
@@ -175,6 +175,6 @@ UP, code 0x0000000065. (E UP).<br>
|
||||
It is an important point that even though we’re representing many keys with USB
|
||||
HID codes, these are not necessarily the same HID codes produced by the hardware
|
||||
and presented to the driver, since on most platforms we have to map the platform
|
||||
representation back to a HID code because we don’t have access to the original
|
||||
representation back to an HID code because we don’t have access to the original
|
||||
HID code. USB HID is simply a conveniently well-defined standard that includes
|
||||
many of the keys we would want.
|
||||
|
||||
@@ -10,4 +10,4 @@ intended to be a general-purpose tool.
|
||||
- groups
|
||||
- group transforms
|
||||
- group opacities
|
||||
- paths (strokes are not supported, only fills, eliptical arc curve commands are not supported)
|
||||
- paths (strokes are not supported, only fills, elliptical arc curve commands are not supported)
|
||||
|
||||
Reference in New Issue
Block a user