As preparation for #125945.
The PR improves tests itself which allows the `arc` method to be available to check whether corresponding rects are drawn during tests.
*Replace this paragraph with a description of what this PR is changing or adding, and why. Consider including before/after screenshots.*
*List which issues are fixed by this PR. You must list at least one issue.*
*If you had to change anything in the [flutter/tests] repo, include a link to the migration guide as per the [breaking change policy].*
This PR adds a month and year mode to the CupertinoDatePicker. The monthYear mode is the date mode without the day of the month.
This feature was added at the request of:
[Proposal] CupertinoDatePicker with month and year. #93508
One thing that I was unsure of was the use of the DatePickerDateOrder to determine the monthYear order. It could be considered a workaround since the DatePickerDateOrder is intended to order day, month, and year. This means that a developer could use the DatePickerDateOrder.dmy (day, month, year) or DatePickerDateOrder.mdy (month, day, year) to get the same result.
At first I intended to add a DatePickerMonthYearOrder enum to the localizations, in addition to a new parameter for the CupertinoDatePicker for monthYearOrder, but I ended up reverting these changes (1c61f1084e) because I had not considered the effects of adding values to the localizations.
I decided it may be better to not add an additional parameter (monthYearOrder) that would go mostly unused. I am very open to feedback or ideas on this matter.
This PR removed the non-necessary required Koltin dependency. This is because the Kotlin Gradle adds the dependency on the standard library automatically.
Fixes#98212
*If you had to change anything in the [flutter/tests] repo, include a link to the migration guide as per the [breaking change policy]. *
This PR contains a series of minor changes to address issues that I happened to run into:
- Pretty-print errors triggered when handling events that are pending because of having locked event handling. Previously these were just dumped to the console.
- Add more documentation for `debugPaintPadding`.
- Add documentation to `Tween` saying how to implement it.
- Slight formatting changes in the scrollbar code to align some expressions.
- Since we convert ScrollMetricsNotifications to ScrollNotifications in various places, provide an explicit API to do this. This will make the behaviour consistent throughout, and makes the code easier to understand. Added a test for this.
- Clarifications to some of the BindingBase and SchedulerBinding documentation.
- Clarified some documentation in `flutter_test`'s `Finder` class.
The property was typed as nullable, but the code assumed its always non-null. This makes the property non-nullable as well.
Also refactors CupertinoListSection, which was flagged by the analyzer when borderRadius became non-nullable (no functional change, just cleaning up existing code to avoid the warning).
Move imports of API available in `hooks.dart` or `scaffolding.dart` to use those more narrow libraries.
Move imports of APIs from `package:matcher` to import directly. The next major version of `test_api` will remove the exports of `matcher` APIs.
I'd like to find out the `fontSize` of a `PlaceholderSpan`, and currently there doesn't seem to be a way to do `TextStyle` cascading in the framework:
`InlineSpan.visitChildren` traverses the entire `InlineSpan` tree using a preorder traversal, and nodes that don't have "content" will be skipped (https://master-api.flutter.dev/flutter/painting/InlineSpan/visitChildren.html):
> Walks this [InlineSpan](https://master-api.flutter.dev/flutter/painting/InlineSpan-class.html) and any descendants in pre-order and calls visitor for each span that has content.
which makes it impossible to do `TextStyle` cascading in the framework:
- `InlineSpan`s with a non-null `TextStyle` but has no content will be skipped
- `visitChildren` doesn't directly expose the hierarchy, it only gives information about the flattened tree.
This doesn't look like a breaking change, most internal customers are extending `WidgetSpan` which has a concrete implementation of the new method.
Alternatively I could create a fake `ui.ParagraphBuilder` and record the `ui.TextStyle` at the top of the stack when `addPlaceholder` is called. But `ui.TextStyle` properties are not exposed to the framework.
Close#125385 - please see explanations there :)
If you think this PR looks OK, I will polish it (e.g. copy-and-paste-and-modify the tests shown in #125385 into here and make CI pass)
Adds the ability to rename Runner.xcodeproj and Runner.xcworkspace - fixes https://github.com/flutter/flutter/issues/9767.
To rename a project:
1. Open Runner.xcodeproj in Xcode
2. In the left panel, left click "Show File Inspector"
<img width="441" alt="Screenshot 2023-04-17 at 11 41 07 PM" src="https://user-images.githubusercontent.com/36148254/232692957-8743742d-c3ef-42e5-833f-dff31aeb2b6a.png">
3. In the right panel, the name of the project, "Runner", should be visible under "Identity and Type". Change the name and press enter.
<img width="299" alt="Screenshot 2023-04-17 at 11 40 43 PM" src="https://user-images.githubusercontent.com/36148254/232693315-b6a71165-f5e3-4a0f-8954-2f3eee5b67cf.png">
4. A wizard should pop up. Click Rename.
<img width="573" alt="Screenshot 2023-04-17 at 11 44 01 PM" src="https://user-images.githubusercontent.com/36148254/232693381-bb9cf026-2a75-4844-b42d-ae0036ae9fdd.png">
To rename the workspace:
1. Make sure Xcode is closed.
2. Rename the .xcworkspace to your new name.
If you also renamed the project
3. Reopen the .xcworkspace in Xcode. If the selected project is the old name and in red, update it to match the new project name.
Tests for schemeFor were changed as with Xcode 14, in some cases the scheme will be renamed along with the project. Thus we will get the best match scheme for either the project name, or the default name Runner. However if a flavor is present, the scheme should always match the flavor.
Update `flutter doctor` to clarify that Visual Studio is needed only if creating Windows apps. Windows users targeting Android do not need to install Visual Studio.
Engine PR: https://github.com/flutter/engine/pull/41593
This must land first
We should remove these, as they've been deprecated for a while. On the engine side of things, the physical model layer is the only one which requires the device pixel ratio, so deleting it will allow us to simplify the layer tree code in https://github.com/flutter/engine/pull/41559
## Description
This PR adds a new debug flag named `debugPrintKeyboardEvents` to help debugging keyboard issues.
Keyboard code has some useful asserts but sometimes an assertion failure is related to the handling of previous key events. This debug flag will help understanding the flow of key events which leads to an assertion failure.
## Related Issue
Fixes https://github.com/flutter/flutter/issues/125627
## Tests
Adds 1 test.
cc'ing existing conversation participants: @domesticmouse @srawlins
cc'ing to request review: @goderbauer
This PR makes the following constructor arguments required:
1. `FutureBuilder.future`
2. `StreamBuilderBase.stream`
3. `StreamBuilder.stream`
This fixes:
https://github.com/flutter/flutter/issues/83081https://github.com/flutter/flutter/issues/125188 (dupe of 83081)
This obviates:
https://github.com/dart-lang/linter/issues/4309
(I suggest we skip straight to merging this PR as this should be a low impact breaking change-assuming few to no devs are intentionally using the builders without their relevant arguments, however we could always merge 4309 first and then this)
https://github.com/flutter/flutter/pull/83101
(The above PR required that at least one of future and initial data be non-null, this is undesirable as there are plenty of valid reasons to have both arguments be null)
See above issues for a deeper dive, but here is a summary:
It is very easy for a developer to forget to specify `future` or `stream` when using the respective `*Builder` widgets. This produces a non-obvious failure where the UI sits in a "no data yet received" state. It is easy for a dev to misinterpret this as the async work backing the future/stream hanging and they thus waste a lot of time trying to debug the async work.
As such, we should require these two constructor arguments to make it impossible/much harder for devs to make this time-wasting mistake.
This is a breaking change. However, it should break only a small number of active projects given that using a builder without specifying `future` or `stream` seems highly niche.
The only place I've found non-accidental examples of this is in widget tests where you're calling `pumpWidget` with and without these arguments to test `*Builder.didUpdateWidget`'s behavior. In this and similar cases, it is a trivial fix to add `future: null`/`stream: null`.
*If you had to change anything in the [flutter/tests] repo, include a link to the migration guide as per the [breaking change policy].*
1. Add iOS and macOS migration to mark "last upgraded" Xcode version to 14.3 to prevent `Update to recommended settings` warning.
2. Update iOS and macOS templates to same.
3. Update iOS template to set `BuildIndependentTargetsInParallel` to YES as suggested. I didn't add a migration for this since it seems like a minor optimization and I don't think it's worth a potentially botched/corrupted migration.
4. Run all example/integration test project to see migrator work.
5. Add some missing test projects to the build shard since I noticed they were missing and I had to build those manually outside `SHARD=build_tests`.
Fixes https://github.com/flutter/flutter/issues/125817
See https://github.com/flutter/flutter/pull/90304 for Xcode 13 example.
Fixes#121468 (when considered along with https://github.com/flutter/flutter/pull/125247).
This applies the pre-existing Android Studio version detection logic to the install configured with `flutter config android-studio-dir`.
We were failing to dispose of animation controllers created by `animateTo` when `didUpdateWidget` happens and we null out the `_attachedController`. This would cause the listener added here to fail on a null assertion:
fef41cfce0/packages/flutter/lib/src/widgets/draggable_scrollable_sheet.dart (L135)
Without the code change, the test ends up throwing exceptions related to that line. I don't have a great way to verify what this does visually though, hoping for help on that from internal customer.
b/279930163
See cl/527868355 as well.
Fixes https://github.com/flutter/flutter/issues/125709
`package` template should not create platform folders. This happen cause by default all platforms are supported and tools didn't distinguish between package and other template, which makes all platforms are true for below code,
d186792c00/packages/flutter_tools/lib/src/project.dart (L374-L380)fixes: #119844 which make #116320 makes invalid. As for why tools created deprecated `Android Embedding`, `appManifestFile` does not exist for `package` template, which make below code to trigger,
https://github.com/flutter/flutter/blob/master/packages/flutter_tools/lib/src/project.dart#L768-L770
This does not happen with `module` and `plugin` as it have specific condition check for them. I try to reproduce it with `app` template but didn't succeed
