1. Instead of getting the `FULL_PRODUCT_NAME` Xcode build setting (`Runner.app`) instead use `PRODUCT_NAME` since most places really want the product name, and the extension stripping wasn't correct when the name contained periods.
2. Don't instruct the user to open the `xcarchive` in Xcode if it doesn't exist.
Fixes https://github.com/flutter/flutter/issues/140212
For the necessary background knowledge, see the flutter.dev content on [Resolution-aware image assets](https://docs.flutter.dev/ui/assets/assets-and-images#resolution-aware) and [Conditional bundling of assets based on app flavor](https://docs.flutter.dev/ui/assets/assets-and-images#conditional-bundling-of-assets-based-on-app-flavor) if you don't have a basic understanding of these features.
Fixes https://github.com/flutter/flutter/issues/151813 by using unique temporary directories, per asset file, for transformations. Currently, only a single directory is used and the name of the temporary files was based only on the basename of files. This means that `assets/image.png` and `assets/2x/image.png` would share an output path (`<temp dir path>/image.png`), causing a race. If this quick and rough explanation is a bit confusing, the original issueâ#151813âprovides a full repro and correct identification of the exact cause of the failure that can occur in the asset transformation process.
https://github.com/flutter/flutter/issues/150800. I skipped files that contain generated code because the script isn't smart enough, and I did not fix some dubious comment refs. Those will be addressed in a different PR.
Fixes a bug where WillPopScope no longer worked on the home route.
With this PR, Android's predictive back feature will be explicitly disabled when a WillPopScope widget is in the widget tree. To get the same behavior and still support predictive back, use PopScope.
This PR properly resets the drag state when losing the gesture arena or when the recognizer stops tracking the current pointer. The _dragState enum was reset properly, but I had forgotten to also reset the `_start`, this caused an issue when the recognizer won the gesture arena the next time, as it tries to detect a drag given the old `_start` in `acceptGesture`, but the `_dragState` has been reset causing an assertion to trigger.
This pull request implements [enhanced enum](https://dart.dev/language/enums#declaring-enhanced-enums) features for the new `WidgetState` enum, in order to improve the developer experience when creating and using `WidgetStateProperty` objects.
`WidgetState` now has a `.matchesSet()` method:
```dart
// identical to "states.contains(WidgetState.error)"
final bool hasError = WidgetState.error.isSatisfiedBy(states);
```
This addition allows for wide variety of `WidgetStateProperty` objects to be constructed in a simple manner.
<br><br>
```dart
// before
final style = MaterialStateTextStyle.resolveWith((states) {
if (states.contains(MaterialState.error)) {
return TextStyle(color: Colors.red);
} else if (states.contains(MaterialState.focused)) {
return TextStyle(color: Colors.blue);
}
return TextStyle(color: Colors.black);
});
// after
final style = WidgetStateTextStyle.fromMap({
WidgetState.error: TextStyle(color: Colors.red),
WidgetState.focused: TextStyle(color: Colors.blue),
WidgetState.any: TextStyle(color: Colors.black), // "any" is a static const member, not an enum value
});
```
```dart
// before
final color = MaterialStateProperty.resolveWith((states) {
if (states.contains(MaterialState.focused)) {
return Colors.blue;
} else if (!states.contains(MaterialState.disabled)) {
return Colors.black;
}
return null;
});
// after
final color = WidgetStateProperty<Color?>.fromMap({
WidgetState.focused: Colors.blue,
~WidgetState.disabled: Colors.black,
});
```
```dart
// before
const activeStates = [MaterialState.selected, MaterialState.focused, MaterialState.scrolledUnder];
final color = MaterialStateColor.resolveWith((states) {
if (activeStates.any(states.contains)) {
if (states.contains(MaterialState.hovered) {
return Colors.blueAccent;
}
return Colors.blue;
}
return Colors.black;
});
// after
final active = WidgetState.selected | WidgetState.focused | WidgetState.scrolledUnder;
final color = WidgetStateColor.fromMap({
active & WidgetState.hovered: Colors.blueAccent,
active: Colors.blue,
~active: Colors.black,
});
```
<br>
(fixes#146042, and also fixes#143488)
In particular, without this cross-reference it's easy for a reader
looking at [Image.frameBuilder] to think that the meanings of these
parameters just aren't properly documented. (I had that thought for
a minute, before thinking *surely* they're documented, and then
trying the link to the typedef.)
fixes https://github.com/flutter/flutter/issues/146414
---
I saw @abikko submitted a PR https://github.com/flutter/flutter/pull/146630, but it was not completed due to CLA and lack of test cases.
I am willing to complete this PR in combination with @abikko's code (I don't know if this is allowed)
This PR adds contorlAffinity to ListTileTheme so that [CheckboxListTile], [RadioListTile], [SwitchListTile], and [ExpansionTile] can read and use it
For example: If ListTileTheme in Theme sets contorlAffinity, then [CheckboxListTile] can directly use contorlAffinity in ListTileTheme. Of course, if contorlAffinity is also set in [CheckboxListTile], the property in [CheckboxListTile] will be used first.
[Wikipeidia](https://ko.wikipedia.org/wiki/%EC%9E%98%EB%9D%BC%EB%82%B4%EA%B8%B0,_%EB%B3%B5%EC%82%AC,_%EB%B6%99%EC%97%AC%EB%84%A3%EA%B8%B0)
In korea, we use '잘라내기', '복사', '붙여넣기', not '잘라냄', '복사', '붙여넣기'.
e.g.) korean translation site, papago
## Pre-launch Checklist
- [x] I read the [Contributor Guide] and followed the process outlined
there for submitting PRs.
- [x] I read the [Tree Hygiene] wiki page, which explains my
responsibilities.
- [x] I read and followed the [Flutter Style Guide], including [Features
we expect every widget to implement].
- [x] I signed the [CLA].
- [x] I listed at least one issue that this PR fixes in the description
above.
- [x] I updated/added relevant documentation (doc comments with `///`).
- [x] I added new tests to check the change I am making, or this PR is
[test-exempt].
- [x] I followed the [breaking change policy] and added [Data Driven
Fixes] where supported.
- [x] All existing and new tests are passing.
This PR allows for an optional argument [inverted[ to be passed to the [getOuterPath] method of a CircularNotchedRectangle object in order to invert the notch for situations where it is desired to draw the notch on the bottom of the path. This allows both of the below paths in the below screenshot to be drawn and changes no default behavior.
*List which issues are fixed by this PR. You must list at least one issue. An issue is not required if the PR fixes something trivial like a typo.*
This add a feature similar to the one discussed in #49973, original feature proposal #151381
*If you had to change anything in the [flutter/tests] repo, include a link to the migration guide as per the [breaking change policy].*
Reverts: flutter/flutter#146593
Initiated by: zanderso
Reason for reverting: Consistently failing `Windows_android native_assets_android` as in https://ci.chromium.org/ui/p/flutter/builders/prod/Windows_android%20native_assets_android/2533/overview
Original PR Author: bkonyi
Reviewed By: {christopherfujino, kenzieschmoll}
This change reverts the following previous change:
This change is a major step towards moving away from shipping DDS via Pub.
The first component of this PR is the move away from importing package:dds to launch DDS. Instead, DDS is launched out of process using the `dart development-service` command shipped with the Dart SDK. This makes Flutter's handling of DDS consistent with the standalone Dart VM.
The second component of this PR is the initial work to prepare for the removal of instances of DevTools being served manually by the flutter_tool, instead relying on DDS to serve DevTools. This will be consistent with how the standalone Dart VM serves DevTools, tying the DevTools lifecycle to a live DDS instance. This will allow for the removal of much of the logic needed to properly manage the lifecycle of the DevTools server in a future PR. Also, by serving DevTools from DDS, users will no longer need to forward a secondary port in remote workflows as DevTools will be available on the DDS port.
There's two remaining circumstances that will prevent us from removing DevtoolsRunner completely:
- The daemon's `devtools.serve` endpoint
- `flutter drive`'s `--profile-memory` flag used for recording memory profiles
This PR also includes some refactoring around `DebuggingOptions` to reduce the number of debugging related arguments being passed as parameters adjacent to a `DebuggingOptions` instance.
This change is a major step towards moving away from shipping DDS via
Pub.
The first component of this PR is the move away from importing
package:dds to launch DDS. Instead, DDS is launched out of process using
the `dart development-service` command shipped with the Dart SDK. This
makes Flutter's handling of DDS consistent with the standalone Dart VM.
The second component of this PR is the initial work to prepare for the
removal of instances of DevTools being served manually by the
flutter_tool, instead relying on DDS to serve DevTools. This will be
consistent with how the standalone Dart VM serves DevTools, tying the
DevTools lifecycle to a live DDS instance. This will allow for the
removal of much of the logic needed to properly manage the lifecycle of
the DevTools server in a future PR. Also, by serving DevTools from DDS,
users will no longer need to forward a secondary port in remote
workflows as DevTools will be available on the DDS port. This code is currently
commented out and will be enabled in a future PR.
There's two remaining circumstances that will prevent us from removing
DevtoolsRunner completely:
- The daemon's `devtools.serve` endpoint
- `flutter drive`'s `--profile-memory` flag used for recording memory
profiles
This PR also includes some refactoring around `DebuggingOptions` to
reduce the number of debugging related arguments being passed as
parameters adjacent to a `DebuggingOptions` instance.
This will make
* `flutter run` have source maps enabled by default
* `flutter build` have source maps disabled by default
which mirrors what happens already today with the js compilers.
For local development this works quite well - even better than with
dart2js (see dart2js issues in [0]).
We do have some follow-up items for source maps in dart2wasm compiler,
see [1]
[0]
[flutter/flutter/issues/151641](https://github.com/flutter/flutter/issues/151641)
[1]
[dart-lang/sdk/issues/56232](https://github.com/dart-lang/sdk/issues/56232)
Stop trying to roll the dependencies for native assets automatically.
They are under active development (pre 1.0.0), and have frequent breaking changes. I'll be rolling these manually.
(We have the same setup in the Dart SDK, not auto-rolling dart-lang/native via DEPS.)
Related comment:
* https://github.com/flutter/flutter/pull/151539#issuecomment-2221134824
