-
Notifications
You must be signed in to change notification settings - Fork 26.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Define durations/barrier colors on PageTransitionsBuilder
s, and remove transitions for web/non-mobile platforms
#104380
Conversation
@@ -1428,8 +1428,7 @@ abstract class ModalRoute<T> extends TransitionRoute<T> with LocalHistoryRoute<T | |||
} | |||
_ignorePointerNotifier.value = !isCurrent || | |||
(navigator?.userGestureInProgress ?? false) || | |||
(ignorePointerDuringTransitions && | |||
(isTransitioning(animation) || isTransitioning(secondaryAnimation))); | |||
((isTransitioning(animation) || isTransitioning(secondaryAnimation)) && ignorePointerDuringTransitions); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reordering this so that ignorePointerDuringTransitions
can be last, to avoid issues looking up the theme with a context at the wrong time (like, after the route has been explicitly removed from the navigator, like for dropdown routes). In those cases, the isTransitioning
methods should always prevent ignorePointerDuringTransitions
from being evaluated, since the transitions are set explicitly to kAlwaysDismissed
, and will in turn fail this first condition
e988b15
to
16b4d19
Compare
}) : assert(builder != null), | ||
assert(maintainState != null), | ||
assert(fullscreenDialog != null) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Figured I might as well delete these on files that I'm touching to make the code cleaner (all of the assertion deletions are for null-checks on non-nullable parameters). I'm just assuming that there's nothing wrong with that, but lemme know if you'd like me to put these back to make the diff easier to read through
final TargetPlatform platform = CupertinoRouteTransitionMixin.isPopGestureInProgress(route) | ||
? TargetPlatform.iOS | ||
: Theme.of(route.navigator!.context).platform; | ||
return builders[platform] ?? _defaultBuilder; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's worth calling out that this public method has been deleted. I did this so that the responsibility of this class could be simpler—rather than delegating the building of transitions to this class, which then delegates it to the builder, the MaterialRouteTransitionMixin
just gets the builder (which is now the new primary function of this class) and then delegates implementation details directly to it. This also makes it easier to be sure that we're perfectly duplicating the logic for this iOS platform override, which we should do not only for building transitions, but also for barrier colors and durations
That said, I don't know if the deletion of this public member is contributing to any of the failing checks; I'll check that out
@@ -72,7 +73,7 @@ void main() { | |||
|
|||
expect(find.text('Page 1'), isOnstage); | |||
expect(find.text('Page 2'), findsNothing); | |||
}, variant: TargetPlatformVariant.only(TargetPlatform.android)); | |||
}, variant: TargetPlatformVariant.only(TargetPlatform.android), skip: kIsWeb); // [intended] Transitions disabled on web |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I took all of these skips from the diff that was accepted in #82596 (cc @darrenaustin as an FYI)
Tried rebasing to see if there were just testing problems on master, but now I just have even more failing checks. Gonna try figuring out how to work through some of those after work today. Looking at the linux ones now, it seems like at least some of these failures are showing up as flakes in other places as well, but I'll keep taking a look. At any rate, the implementation is where I wanted to put it, so I think this PR should be ready for at least some level of feedback? cc @HansMuller in case you'd like to check it out, in particular since you were the original author of this stuff surrounding the transitions builders and transitions theme, that this PR is modifying |
…ransitionsTheme for no web builders, update MaterialRouteTransitionMixin to reference the builders
…ion is unchanged)
9d5b22a
to
f058140
Compare
Gotta fix this approach, so moving this back to a draft. It's not always going to be safe to lookup If anyone has any thoughts about how I can work around this, lemme know; otherwise I'll keep looking into if there are ways we can maybe have some cached value of the builder or something like that. I think if we were to go this direction, we'd want to be able to reference it as much as we want |
This pull request has been changed to a draft. The currently pending flutter-gold status will not be able to resolve until a new commit is pushed or the change is marked ready for review again. For more guidance, visit Writing a golden file test for Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing. |
PageTransitionsBuilder
s, and remove transitions for web/non-mobile platformsPageTransitionsBuilder
s, and remove transitions for web/non-mobile platforms
I'm gonna reopen this in smaller pieces. Can't merge all parts of the current approach anyway now that #95757 has been reverted |
Once the smaller pieces are created, please mention them here so that i can follow them. |
This PR:
Problems/requirements:
ZoomPageTransitionsBuilder
should not define the default animation for any non-mobile platforms. Non-mobile platforms should also have no default transition animations, and transitions should be immediate.MaterialPageRoute
s should have the same exact transitions asCupertinoPageRoute
s when using theCupertinoPageTransitionsBuilder
(currently, thebarrierColor
,transitionDuration
,reverseTransitionDuration
, andignorePointerDuringTransitions
are all inconsistent between the two implementations)Solution
The goal of this PR is to make material route transitions as visible on all platforms (plus web): easier to understand and configure, and to have higher fidelity to the platform-specific native transitions behavior.
This approach does that by taking the responsibility of defining platform-specific transition animation behavior largely within the
PageTransitionsBuilder
classes that currently only own the building of the transitions themselves. So before, these classes would only be used for building transitions, but now they are the main place that configuration for platform-specific transition animations would happen.This means that now, the
PageTransitionsTheme
can own only the mapping of target platforms to platform-specific transition classes (thebuildTransitions
method on the theme has been deleted).Similarly, now, the
MaterialRouteTransitionMixin
can just use thePageTransitionsTheme
to get the rightPageTransitionsBuilder
, and delegate most of the visual configuration to the builder class. For Cupertino transitions, rather than duplicating the behavior for durations/barrier colors across theCupertinoPageRoute
andCupertinoPageTransitionsBuilder
implementations, that has remained consolidated under theCupertinoRouteTransitionsMixin
, which is consulted by the builder soCupertinoPageRoute
s andMaterialPageRoute
s on iOS can share the same exact implementation (fixing #95764).This ability to further configure more of the animations for specific platforms was the main thing blocking us from fixing #99052, so I've included fixes to those as well. Now, there is a new
NoAnimationPageTransitionsBuilder
for web and non-mobile platforms, so animations will only happen by default on android, iOS, and fuchsia (when not also on web).Alternatives considered:
Recordings:
Web
Before:
Screen.Recording.2022-05-22.at.2.43.26.PM.mov
After:
Screen.Recording.2022-05-22.at.2.41.33.PM.mov
Mobile
Before:
Screen.Recording.2022-05-22.at.10.05.54.PM.mov
After:
Screen.Recording.2022-05-22.at.10.07.32.PM.mov