* Update stepper.dart
Added 'physics' prop which allows the developer to assign the Stepper's scroll view's 'ScrollPhysics' which can solve with unwanted scrolling behaviour if the parent is also a scroll view. Defaults to 'AlwaysScrollableScrollPhysics' if null.
* Update stepper.dart
Removed unnecessary import and defaulting to 'AlwaysScrollableScrollPhysics' if physics prop is null.
* Update stepper.dart
Ran through format to remove unwanted whitespace which Analysis isn't happy about.
* Update stepper.dart
Tried reformatting again.
* Update stepper.dart
Tried reformatting again.
* Update stepper.dart
Formatting again why do you hate me github editor.
* Update stepper.dart
* Update stepper.dart
if this format doesn't work i'll cry
* Update stepper_test.dart
Added Stepper scroll tests. One that fails to find Text after Stepper if physics left as null and one that succeeds if physics set to `ClampingScrollPhysics()`
* Update stepper_test.dart
Added const constructors
* Update stepper_test.dart
trying to get rid of whitespace again
* Update stepper_test.dart
* Update stepper_test.dart
why whitespace why
* Update stepper_test.dart
* Update stepper_test.dart
* Update stepper_test.dart
* Update stepper_test.dart
Swapped to `findsNothing` because I'm an idiot.
* Update stepper_test.dart
* Update stepper.dart
Currently, in pubspec.yaml, semver.org is referred to for more about versioning.
However, the versionCode/versionName could differ on different platforms (iOS, Android, Dart).
This adds more clear and complete information that could help users to understand it better.
See: #27251
* Fix for #26261. Changes CupertinoTextField's cursorColor to read from CupertinoTheme instead of prior default of activeBlue. CursorColor will still default to activeBlue for light theme and activeOrange for dark theme if a primary color has not been specified for the CupertinoTheme.
* Reverted unnecessary changes in XCode file.
* Updated text_field.dart per suggestions from @gspencergoog
* Updated comments for cursorColor to reflect appropriate hyperlinks per @Hixie
* Simplified cursorColor assignment per @xster
* Added test in cupertino/text_field_test.dart to check for correct cursorColor based on CupertinoTheme per @Hixie & @xster.
* Provide a simmplified API for skipping over slider thumb, overlay, and tick mark painting
* doc fixes
* comments
* comments
* comments
* comments
* comments
* analyzer
* comments
This change was dropped out of #26227 because it seems to inexplicably result in timeouts talking to the VM service on Windows Cirrus. After 1 month of periodically debugging it, it just started passing 🤷♂️.
In Dart 2, it is a compile-time error if a superinitializer
appears in an initializer list at any other position than at the end so this
rule is made redundant by the Dart analyzer's basic checks and is no longer
necessary.
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.
Try to detect Gradle error messages that hint at AndroidX problems, and
warn in the logs about the potential problem and point to documentation
on how to fix the issue.
Unfortunately the Gradle errors based on this root issue are varied and
project dependent. It's probably better to still leave the message
intact in case the problem is unrelated.
Also filters out the plugin warning message pending in
flutter/plugins#1138. It's still valuable to add that for people on
previous versions of Flutter, but this link should override that message
for anyone on an up to date version of Flutter.
#27106
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.
For `fuchsia_compat.dart` Instead of using `runSync`, use `run` to avoid
deadlock when attempting to access specific resources like the Hub in Fuchsia.
The specific example is that in Fuchsia, the `find` command is
attempting to explore `out` which hasn't yet been serviced, as `find` is
blocking on it, causing a deadlock.
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.
