**Changes**
- Add `WidgetStateInputBorder` class, with `.resolveWith()` and `.fromMap()` constructors
- Deprecate `MaterialStateOutlineInputBorder` and `MaterialStateUnderlineInputBorder` and provide data-driven fixes
<br>
**Other changes** based on https://github.com/flutter/flutter/pull/154972#pullrequestreview-2344092821
- Fix documentation copy-paste typo ("OutlinedBorder" â "InputBorder")
- Add test to ensure borders are painted correctly
- Add DartPad sample & relevant test
This PR introduces a basic example of how to use the `showDatePicker` function. The purpose of this PR is to simplify the onboarding process for new Flutter developers by providing a straightforward demonstration of handling the asynchronous Future returned by the showDatePicker. This will help users unfamiliar with the intricacies of asynchronous operations in Flutter.
Fixes#156157
Fixes#33799
Allows for a route to inform the route below it in the navigation stack how to animate when the topmost route enters are leaves the stack.
It does this by making a `DelegatedTransition` available for the previous route to look up and use. If available, the route lower in the stack will wrap it's transition builders with that delegated transition and use it instead of it's default secondary transition.
This is what the sample code in this PR shows an app that is able to use both a Material zoom transition and a Cupertino slide transition in one app. It also includes a custom vertical transition. Every page animates off the screen in a way to match up with the incoming page's transition. When popped, the correct transitions play in reverse.
https://github.com/user-attachments/assets/1fc910fa-8cde-4e05-898e-daad8ff4a697
The below video shows this logic making a pseudo iOS styled sheet transition.
https://github.com/flutter/flutter/assets/58190796/207163d8-d87f-48b1-aad9-7e770d1d96c5
All existing page transitions in Flutter will be overwritten by the incoming route if a `delegatedTransition` is provided. This can be opted out of through `canTransitionTo` for a new route widget. Of Flutter's existing page transitions, this PR only adds a `DelegatedTransition` for the Zoom and Cupertino transitions. The other transitions possible in Material will get delegated transitions in a later PR.
Fixes https://github.com/flutter/flutter/issues/155551
### Description
- Adds example for `WidgetStateMouseCursor`
- Adds tests for `examples/api/lib/widgets/widget_state/widget_state_mouse_cursor.0.dart`
Fixes https://github.com/flutter/flutter/issues/155557
### Description
- Adds example for `WidgetStateBorderSide`
- Adds tests for `examples/api/lib/widgets/widget_state/widget_state_border_side.0.dart`
This PR contributes to https://github.com/flutter/flutter/issues/155313
### Description
- Adds example for `WidgetStateProperty`
- Adds tests for `examples/api/lib/widgets/widget_state/widget_state_property.0.dart`
This PR is to update the token version to v6.1.
* This version fixes https://github.com/flutter/flutter/issues/153271
* Change the chip default border color from `ColorScheme.outline` to `ColorScheme.outlineVariant`. The Chips' border color is softened to improve visual hierarchy between chips and buttons
Contributes to https://github.com/flutter/flutter/issues/130459
It adds a test for
- `examples/api/lib/rendering/sliver_grid/sliver_grid_delegate_with_fixed_cross_axis_count.0.dart`
- `examples/api/lib/rendering/sliver_grid/sliver_grid_delegate_with_fixed_cross_axis_count.1.dart`
I also fixed a mistake in the documentation
This PR adds a new constructor to the RefreshIndicator's class, which is `noSpinner`.
The purpose of this new constructor is to create a RefreshIndicator that doesn't show a spinner when the user arms it by pulling.
The work is based on a partial that is here: https://github.com/flutter/flutter/pull/133507
I addressed the following issues reported in the PR above:
- in the example for `noSpinner`, arming the RefreshIndicator now shows a CircularProgressIndicator, instead of just printing text to the console;
- added a test for the new example;
- added a doc comment on the new constructor;
Fixes https://github.com/flutter/flutter/issues/132775
CustomScrollViewExampleApp
Part of https://github.com/flutter/flutter/issues/130459
The test is checking:
- if all crucial Widgets are initially visible
- if IconButton click will expand existing SliverList
- if IconButton click and mouse scroll will reveal additional SliverList
I've updated these two examples to support state restoration of the navigation stack and verified that they work with predictive back in the tests. This was motivated by a worry that users are not properly setting up their navigation and that our examples are misleading them in the name of simplicity.
Contributes to https://github.com/flutter/flutter/issues/130459
It adds a test for
- `examples/api/lib/widgets/single_child_scroll_view/single_child_scroll_view.0.dart`
- `examples/api/lib/widgets/single_child_scroll_view/single_child_scroll_view.1.dart`
I also fixed a mistake in the documentation
Move `scroll_direction.0_test.dart` & `growth_direction.0_test.dart` to same directory structure as the example files.
Tests were already present, only had to move them & remove the entries from the missing tests.
Part of #130459
This PR is aimed at (1) reducing the private API surface of _MenuAnchorState to make migration into RawMenuAnchor simpler, and (2) fixing focus-related bugs.
Directional focus handling was moved from MenuAnchor (_MenuDirectionalFocusAction, _MenuNextFocusAction, and _MenuPreviousFocusAction) into SubmenuButton (_SubmenuDirectionalFocusAction). MenuAnchor now behaves similarly to a flat FocusScope, which makes it easier to customize. A future PR will ideally expose or remove the remaining internals (_lastItemFocusNode, _firstItemFocusNode, _isRoot, etc). All previous framework tests are passing, and additional tests were added for fixes (MenuAnchor tab traversal, reopened menus not being focusable), and to test MenuAnchor focus behavior separately from MenuBar.
However, [one example test](https://github.com/flutter/flutter/pull/150950/files#diff-a33fa01b59d280784e7c8ed6b704bd005cde95b7d3b649dc82fd58530061a09d) had to be changed. I'm not sure why the previous example test was working to begin with, as submenu buttons are supposed to open on focus, but this behavior was not observed in the original test.
Fixes https://github.com/flutter/flutter/issues/144381, https://github.com/flutter/flutter/issues/150334.
One added feature is the ability to move between top-level horizontal submenus if a horizontal movement is made on a vertical menu item that has no children in the movement direction. This behavior was observed on Google Docs, MacOS, and various other menu systems I encountered.
https://github.com/flutter/flutter/assets/59215665/04a42b8a-cc9e-4a50-9d0c-6f2d784cfc78
Contributes to https://github.com/flutter/flutter/issues/130459
It adds a test for
- `examples/api/lib/material/scaffold/scaffold_messenger_state.show_snack_bar.0.dart`
- `examples/api/lib/material/scaffold/scaffold_messenger_state.show_material_banner.0.dart`
Contributes to https://github.com/flutter/flutter/issues/130459
It adds a test for
- `examples/api/lib/material/search_anchor/search_anchor.1.dart`
- `examples/api/lib/material/search_anchor/search_anchor.2.dart`
Contributes to https://github.com/flutter/flutter/issues/130459
It adds a test for
- `examples/api/lib/material/scaffold/scaffold_messenger.0.dart`
- `examples/api/lib/material/scaffold/scaffold_messenger.of.0.dart`
- `examples/api/lib/material/scaffold/scaffold_messenger.of.1.dart`
A relatively elaborate PinnedSliverHeader example which creates an app bar that's similar to the one that appears in the iOS Settings app. In this example the pinned header starts out transparent and the first item in the list serves as the app's "Settings" title. When the title item has been scrolled completely behind the pinned header, the header animates its opacity from 0 to 1 and its (centered) "Settings" title appears. The fact that the header's opacity depends on the height of the title item - which is unknown until the list has been laid out - necessitates monitoring its SliverConstraints.scrollExtent from a scroll NotificationListener.
https://github.com/flutter/flutter/assets/1377460/539e2591-d0d7-4508-8ce8-4b8f587d7648
A sliver that shows its [child] when the user scrolls forward and hides it when the user scrolls backwards. Similar headers can be found in Google Photos and Facebook.
This sliver is preferable to the general purpose SliverPersistentHeader for its relatively narrow use case because there's no need to create a SliverPersistentHeaderDelegate or to predict the header's size.
https://github.com/flutter/flutter/assets/1377460/82b67dfb-5d38-4adf-9415-fc8527d0eb9f
Adds a new ScrollNotificationEnd example that demonstrates how to trigger an auto-scroll based on an individual sliver's `SliverConstraints` and `SliverGeometry`.
Then new example auto-scrolls one special "aligned item" sliver to the top or bottom of the viewport, whenever it's partially visible (because it overlaps the top or bottom of the viewport). This example differs from the existing ScrollEndNotification example because the layout of the to-be aligned sliver is retrieved from its `RenderSliver` via a
GlobalKey. The new example does not rely on all of the list items having the same extent.
Reverts: flutter/flutter#150481
Initiated by: cbracken
Reason for reverting: Surprisingly, the following test seems to be consistently failing on Windows after the addition of this test:
```
flutter/packages/flutter/test/widgets/sliver_tree_test.dart: .toggleNodeWith, onNodeToggle
```
Original PR Author: ValentinVignal
Reviewed By: {TahaTesser, bleroux}
This change reverts the following previous change:
Contributes to https://github.com/flutter/flutter/issues/130459
It adds a test for
- `examples/api/lib/material/text_form_field/text_form_field.1.dart`
Add tests for `InputDecoration` API example as part of #130459. Updates examples that use the deprecated MaterialState to use WidgetState. Tests files: `input_decoration.0.dart`, `input_decoration.1.dart`, `input_decoration.2.dart`, `input_decoration.3.dart`, `input_decoration.widget_state.0.dart`, `input_decoration.widget_state.1.dart`, `input_decoration.prefix_icon_constraints.0.dart`, `input_decoration.suffix_icon_constraints.0.dart`, and `input_decoration.label.0.dart`
Introducing the `forceErrorText` property to both `FormField` and `TextFormField`. With this addition, we gain the capability to trigger an error state and provide an error message without invoking the `validator` method.
While the idea of making the `Validator` method work asynchronously may be appealing, it could introduce significant complexity to our current form field implementation. Additionally, this approach might not be suitable for all developers, as discussed by @justinmc in this [comment](https://github.com/flutter/flutter/issues/56414#issuecomment-624960263).
This PR try to address this issue by adding `forceErrorText` property allowing us to force the error to the `FormField` or `TextFormField` at our own base making it possible to preform some async operations without the need for any hacks while keep the ability to check for errors if we call `formKey.currentState!.validate()`.
Here is an example:
<details> <summary>Code Example</summary>
```dart
import 'package:flutter/material.dart';
void main() {
runApp(
const MaterialApp(home: MyHomePage()),
);
}
class MyHomePage extends StatefulWidget {
const MyHomePage({
super.key,
});
@override
State<MyHomePage> createState() => _MyHomePageState();
}
class _MyHomePageState extends State<MyHomePage> {
final key = GlobalKey<FormState>();
String? forcedErrorText;
Future<void> handleValidation() async {
// simulate some async work..
await Future.delayed(const Duration(seconds: 3));
setState(() {
forcedErrorText = 'this username is not available.';
});
// wait for build to run and then check.
//
// this is not required though, as the error would already be showing.
WidgetsBinding.instance.addPostFrameCallback((_) {
print(key.currentState!.validate());
});
}
@override
Widget build(BuildContext context) {
print('build');
return Scaffold(
floatingActionButton: FloatingActionButton(onPressed: handleValidation),
body: Form(
key: key,
child: Center(
child: Column(
mainAxisAlignment: MainAxisAlignment.center,
children: [
Padding(
padding: const EdgeInsets.symmetric(horizontal: 30),
child: TextFormField(
forceErrorText: forcedErrorText,
),
),
],
),
),
),
);
}
}
```
</details>
Related to #9688 & #56414.
Happy to hear your thoughts on this.
The widget under test already contains a MaterialApp, so there's no need to wrap it again with one in the test. In fact, the additional MaterialApp could hide problems in the widget under test.
## Description
This fixes the `ColorScheme` example to actually work. The test had wrapped the app in an additional `MaterialApp`, which allowed the tests to work, but the real problem was using a `context` that was outside the `MaterialApp` to open the bottom sheet, which caused an exception when you actually try to run it interactively.
This fixes the example and the test.
## Tests
- Fixed the test to not artificially add a second `MaterialApp`.
Contributes to https://github.com/flutter/flutter/issues/130459
It adds a test for
- `examples/api/lib/material/scaffold/scaffold.drawer.0.dart`
- `examples/api/lib/material/scaffold/scaffold.end_drawer.0.dart`
A sliver that is pinned to the start of its `CustomScrollView` and reacts to scrolling by resizing between the intrinsic sizes of its min and max extent prototypes.
The minimum and maximum sizes of this sliver are defined by `minExtentPrototype` and `maxExtentPrototype`, a pair of widgets that are laid out once. You can use `SizedBox` widgets to define the size limits.
This sliver is preferable to the general purpose `SliverPersistentHeader` for its relatively narrow use case because there's no need to create a `SliverPersistentHeaderDelegate` or to predict the header's minimum or maximum size.
The sample shows how this sliver's two extent prototype properties can be used to create a resizing header whose minimum and maximum sizes match small and large configurations of the same header widget.
https://github.com/flutter/flutter/assets/1377460/fa7ced98-9d92-4d13-b093-50392118c213
Related sliver utility PRs: https://github.com/flutter/flutter/pull/143538, https://github.com/flutter/flutter/pull/143196, https://github.com/flutter/flutter/pull/127340.
This PR adds `AnimatedList.separated`. A widget like an AnimatedList with animated separators. `animated_list_separated.0.dart` extends `animated_list.0.dart` to work with `AnimatedList.separated`
Related issue: https://github.com/flutter/flutter/issues/48226
The scroll notification events reported for a press-drag-release gesture within a scrollable on a touch screen device begin with a `ScrollStartNotification`, followed by a series of `ScrollUpdateNotifications`, and conclude with a `ScrollEndNotification`. This protocol can be used to defer work until an interactive scroll gesture ends. For example, you might defer updating a scrollable's contents via network requests until the scroll has ended, or you might want to automatically auto-scroll at that time.
In the example that follows the CustomScrollView automatically scrolls so that the last partially visible fixed-height item is completely visible when the scroll gesture ends. Many iOS applications do this kind of thing. It only makes sense to auto-scroll when the user isn't actively dragging the scrollable around.
It's easy enough to do this by reacting to a ScrollEndNotifcation by auto-scrolling to align the last fixed-height list item ([source code](https://gist.github.com/HansMuller/13e2a7adadc9afb3803ba7848b20c410)).
https://github.com/flutter/flutter/assets/1377460/a6e6fc77-6742-4f98-81ba-446536535f73
Dragging the scrollbar thumb in a desktop application is a similar user gesture. Currently it's not possible to defer work or auto-scroll (or whatever) while the scrollable is actively being dragged via the scrollbar thumb because each scrollbar thumb motion is mapped to a scroll start - scroll update - scroll end series of notifications. On a desktop platform, the same code behaves quite differently when the scrollbar thumb is dragged.
https://github.com/flutter/flutter/assets/1377460/2593d8a3-639c-407f-80c1-6e6f67fb8c5f
The stream of scroll-end events triggers auto-scrolling every time the thumb moves. From the user's perspective this feels like a losing struggle.
One can also detect the beginning and end of a touch-drag by listening to the value of a ScrollPosition's `isScrollingNotifier`. This approach suffers from a similar problem: during a scrollbar thumb-drag, the `isScrollingNotifier` value isn't updated at all.
This PR refactors the RawScrollbar implementation to effectively use a ScrollDragController to manage scrolls caused by dragging the scrollbar's thumb. Doing so means that dragging the thumb will produce the same notifications as dragging the scrollable on a touch device.
Now desktop applications can choose to respond to scrollbar thumb drags in the same that they respond to drag scrolling on a touch screen. With the changes included here, the desktop or web version of the app works as expected, whether you're listing to scroll notifications or the scroll position's `isScrollingNotifier`.
https://github.com/flutter/flutter/assets/1377460/67435c40-a866-4735-a19b-e3d68eac8139
This PR also makes the second [ScrollPosition API doc example](https://api.flutter.dev/flutter/widgets/ScrollPosition-class.html#cupertino.ScrollPosition.2) work as expected when used with the DartPad that's part of API doc page.
Desktop applications also see scroll start-update-end notifications due to the mouse wheel. There is no touch screen analog for the mouse wheel, so an application that wanted to enable this kind of auto-scrolling alignment would have to include a heuristic that dealt with the sequence of small scrolls triggered by the mouse wheel. Here's an example of that: [source code](https://gist.github.com/HansMuller/ce5c474a458f5f4bcc07b0d621843165). This version of the app does not auto-align in response to small changes, wether they're triggered by dragging the scrollbar thumb of the mouse wheel.
Related sliver utility PRs: https://github.com/flutter/flutter/pull/143538, https://github.com/flutter/flutter/pull/143196, https://github.com/flutter/flutter/pull/143325.
The current MenuAnchor example in the API Docs is comprehensive and complicated for beginners. I have added a simple bare bone example without shortcuts, enums, etc in examples/api/lib/material/menu_anchor/ as `menu_anchor.3.dart`. The example is contributed by @mafreud
Fixes https://github.com/flutter/flutter/issues/148104
