Repository navigation
Move WindowManager outside of WidgetsApp - #188866
Conversation
|
It looks like this pull request may not have tests. Please make sure to add tests or get an explicit test exemption before merging. If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix? Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing. If you believe this PR qualifies for a test exemption, contact "@test-exemption-reviewer" in the #hackers channel in Discord (don't just cc them here, they won't see it!). The test exemption team is a small volunteer group, so all reviewers should feel empowered to ask for tests, without delegating that responsibility entirely to the test exemption group. |
There was a problem hiding this comment.
Code Review
This pull request refactors the windowing system by updating WindowManager to accept a list of initialWindows instead of a single child widget, registering them during initialization, and removing the automatic wrapping of WindowManager in WidgetsApp. The example application is updated accordingly. Feedback on these changes recommends adding documentation for the new initialWindows property, asserting that the list is not empty to prevent widget tree disposal issues, and replacing the forEach loop with a for-in loop for registering windows to adhere to Dart style guidelines.
| /// {@macro flutter.widgets.windowing.experimental} | ||
| @internal | ||
| const WindowManager({super.key, required this.child}); | ||
| const WindowManager({super.key, required this.initialWindows}); |
There was a problem hiding this comment.
It is recommended to assert that initialWindows is not empty to prevent creating an empty ViewCollection, which would artificially dispose the widget tree.
| const WindowManager({super.key, required this.initialWindows}); | |
| const WindowManager({ | |
| super.key, | |
| required this.initialWindows, | |
| }) : assert(initialWindows.isNotEmpty, 'initialWindows must not be empty.'); |
mattkae
left a comment
There was a problem hiding this comment.
This seems sensible to me.
Another thing to think about: should the WindowManager just be provided by runWidget long term? That way, it is guaranteed to only show up once at the entry point of the app.
cc: @loic-sharma
| // Disable this for now. This is cursed and only works by accident because | ||
| // the WindowManager was planted in a particular place of WidgetApp hierarchy, | ||
| // which unfortunately caused a host of other issue. | ||
|
|
||
| // final WindowRegistry? windowRegistry = WindowRegistry.maybeOf(context); | ||
| // if (windowRegistry != null && isWindowingEnabled) { | ||
| // try { | ||
| // final Size? parentSize = WindowScope.maybeContentSizeOf(context); | ||
| // return navigator.push<T>( | ||
| // _DialogWindowRoute<T>( | ||
| // builder: builder, | ||
| // parentController: WindowScope.maybeOf(context), | ||
| // context: context, | ||
| // settings: routeSettings, | ||
| // preferredSize: fullscreenDialog ? parentSize : null, | ||
| // ), | ||
| // ); | ||
| // } on UnsupportedError catch (error, stacktrace) { | ||
| // // Fallback to normal dialog route if windowing is not supported. | ||
| // FlutterError.reportError( | ||
| // FlutterErrorDetails(exception: error, library: 'widgets library', stack: stacktrace), | ||
| // ); | ||
| // } | ||
| // } |
There was a problem hiding this comment.
Do we need to disable this for now? Can we just check if the user is manually providing a WindowManager and create the dialog then? I see no harm in that and then we don't need to update the core dialog code at all. It will just mostly do the non-windowy way.
There was a problem hiding this comment.
The dialog will not be sized to content when it contains entire MaterialApp because the Overlay inside navigator will always size to cosntriants.biggest. So no matter what you do the dialog will cover entire screen. And we have no way to force size using the route.
Possible but hacky solution would be to set the alwaysSizeToContent in navigator overlay if there is WindowManager present. But it's seems really hacky.
There was a problem hiding this comment.
I am tempted to keep this code since it still works as good as it did before, but we can also re-add it later if we feel that that is more appropriate 👍
There was a problem hiding this comment.
Unfortunately I have to disagree. For the route to work interchangeably with and window windowing enabled the widget would need to be planted at the same place in window hierarchy, but we don't currently have a straightforward way to do that.
bcf20cb to
4560628
Compare
There was a problem hiding this comment.
Code Review
This pull request refactors window management in Flutter by updating WindowManager to accept a list of initialWindows instead of a single child widget, registering them in initState, and removing windowing-specific dialog routing and WidgetsApp integration. Feedback on these changes suggests adding an assertion to ensure initialWindows is not empty, refactoring Iterable.forEach to a standard for-in loop in _WindowManagerState.initState for better performance and readability, and wrapping the independent widget trees in PopupButton and TooltipButton with MaterialApp or Directionality to prevent runtime errors from missing inherited contexts.
| ? View( | ||
| view: _popupWindowEntry!.controller.rootView, | ||
| child: Builder(builder: _popupWindowEntry!.builder), | ||
| ) |
There was a problem hiding this comment.
Since View bootstraps a completely independent widget tree, its child (PopupWindowContent) will not inherit any InheritedWidgets (such as Theme, MediaQuery, or Directionality) from the parent window's context. If PopupWindowContent contains widgets like Text or Material components that rely on these inherited contexts, it will throw runtime errors. Consider wrapping the child in a MaterialApp or at least Directionality and Material to ensure it has the necessary context, similar to how DialogWindowContent and RegularWindowContent were updated.
There was a problem hiding this comment.
That is completely incorrect. It's all part of single element tree.
| ? View( | ||
| view: _tooltipEntry!.controller.rootView, | ||
| child: Builder(builder: _tooltipEntry!.builder), | ||
| ) |
There was a problem hiding this comment.
Since View bootstraps a completely independent widget tree, its child (TooltipWindowContent) will not inherit any InheritedWidgets (such as Theme, MediaQuery, or Directionality) from the parent window's context. If TooltipWindowContent contains widgets like Text or Material components that rely on these inherited contexts, it will throw runtime errors. Consider wrapping the child in a MaterialApp or at least Directionality and Material to ensure it has the necessary context, similar to how DialogWindowContent and RegularWindowContent were updated.
| } | ||
| void initState() { | ||
| super.initState(); | ||
| widget.initialWindows.forEach(_registry.register); |
There was a problem hiding this comment.
In Flutter framework code, using a standard for loop is preferred over Iterable.forEach for better readability and to avoid the overhead of function closures. Consider refactoring this to a standard for-in loop.
for (final WindowEntry entry in widget.initialWindows) {
_registry.register(entry);
}References
- Effective Dart recommends avoiding
Iterable.forEachwith function literals or when a standardforloop is more readable and performant. (link)
There was a problem hiding this comment.
No. Using normal for loop actually triggers analyzer warning.
flutter/flutter@2a2a79d...b65f4d9 2026-07-24 jason-simmons@users.noreply.github.com Add dart_runtime_service_vm_aot.dart.snapshot to the snapshot list in the macOS code signing configuration (flutter/flutter#189981) 2026-07-24 engine-flutter-autoroll@skia.org Roll Fuchsia Test Scripts from wLST_A-xfOeGT_5mj... to E8hJ1AfK8CtGtaES0... (flutter/flutter#189956) 2026-07-23 chingjun@google.com Consolidate AndroidArch and DarwinArch into CpuArch (flutter/flutter#189315) 2026-07-23 engine-flutter-autoroll@skia.org Roll Dart SDK from 9258584f98b8 to e3fc57eae9eb (7 revisions) (flutter/flutter#189949) 2026-07-23 jason-simmons@users.noreply.github.com [flutter_tools] Do not always wait for the full timeout when running Spotlight to locate Android Studio on macOS (flutter/flutter#189952) 2026-07-23 engine-flutter-autoroll@skia.org Roll Skia from 1d8bf9270d8c to 6e9c4687c001 (15 revisions) (flutter/flutter#189954) 2026-07-23 jason-simmons@users.noreply.github.com [flutter_tools] Initialize Cache.flutterRoot at the start of the upgrade_test suite (flutter/flutter#189937) 2026-07-23 faheemabbas766@gmail.com Parse AndroidX property in gradle.properties (flutter/flutter#188372) 2026-07-23 60122246+xiaowei-guan@users.noreply.github.com [Impeller]Use the IO context for OpenGL program setup (flutter/flutter#185723) 2026-07-23 43089218+chika3742@users.noreply.github.com Allow building projects lacking Runner.xcworkspace (flutter/flutter#186239) 2026-07-23 bkonyi@google.com [flutter_tools] Invalidate WebEntrypointTarget when plugin set changes (flutter/flutter#189460) 2026-07-23 srawlins@google.com Bump devtools_shared to 13.1.0 (flutter/flutter#189507) 2026-07-23 matt.boetger@gmail.com forceNdkDownload should skip configuring cmake when ndk-build is used (flutter/flutter#187201) 2026-07-23 jason-simmons@users.noreply.github.com Disable execution order shuffling for the flutter_tools upgrade_test suite (flutter/flutter#189920) 2026-07-23 matej.knopp@gmail.com Move WindowManager outside of WidgetsApp (flutter/flutter#188866) 2026-07-23 engine-flutter-autoroll@skia.org Roll Skia from 3424966b8a2b to 1d8bf9270d8c (3 revisions) (flutter/flutter#189901) 2026-07-23 engine-flutter-autoroll@skia.org Roll Fuchsia Linux SDK from GswhlPRO-D1qSNclx... to 9org0yL3yZkp80x5S... (flutter/flutter#189898) 2026-07-23 116356835+AbdeMohlbi@users.noreply.github.com Remove outdated logs that were added to track #172636 (flutter/flutter#189282) 2026-07-23 engine-flutter-autoroll@skia.org Roll Skia from 5e183e5aeac5 to 3424966b8a2b (33 revisions) (flutter/flutter#189890) 2026-07-23 srawlins@google.com [examples] Use super parameters in missed spots (flutter/flutter#186194) 2026-07-23 bkonyi@google.com [flutter_tools] Bound Spotlight mdfind execution with timeout on macOS (flutter/flutter#189461) 2026-07-23 codedoctor@linwood.dev Fix non primary buttons not being captured on windows (flutter/flutter#188394) 2026-07-22 matt.boetger@gmail.com Listen to log reader before VM Service and make delay configurable (flutter/flutter#187202) 2026-07-22 engine-flutter-autoroll@skia.org Roll Dart SDK from 1e65011ee004 to 9258584f98b8 (7 revisions) (flutter/flutter#189883) 2026-07-22 30870216+gaaclarke@users.noreply.github.com Adds skill for generating engine diffs for new releases. (flutter/flutter#189869) 2026-07-22 chris@bracken.jp [ios,macos] Add Swift Sourcekit LSP support (flutter/flutter#189761) 2026-07-22 chris@bracken.jp [iOS] Mark DisplayLinkManager.shared and init() @mainactor (flutter/flutter#189815) 2026-07-22 97480502+b-luk@users.noreply.github.com Fix `Rect::ExpandToMinTransformedSize` to return the input rectangle when no expansion is needed, and remove 1-pixel roundrect to rect simplification (flutter/flutter#189808) 2026-07-22 15619084+vashworth@users.noreply.github.com Skip emulator.getEmulators test (flutter/flutter#189879) 2026-07-22 codedoctor@linwood.dev Fix null terminator in input truncates clipboard (flutter/flutter#188652) If this roll has caused a breakage, revert this CL and stop the roller using the controls here: https://autoroll.skia.org/r/flutter-packages Please CC bmparr@google.com,stuartmorgan@google.com on the revert to ensure that a human is aware of the problem. To file a bug in Packages: https://github.com/flutter/flutter/issues/new/choose To report a problem with the AutoRoller itself, please file a bug: https://issues.skia.org/issues/new?component=1389291&template=1850622 Documentation for the AutoRoller is here: https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md
Fixes doc comment references that the analyzer can't resolve, found by
temporarily enabling the `comment_references` lint.
Most are renames — the reference named a member that had been renamed,
made private, or removed. Four are judgement calls rather than renames,
so flagging them - happy to change any:
- `widgets/_window.dart` — removed a sentence describing the `if
(!isWindowingEnabled) { return widget.child; }` path deleted in
[flutter#188866](flutter#188866). The `{@macro
flutter.widgets.windowing.experimental}` later in the same comment
already documents the windowing-disabled case.
- `widgets/_window.dart` — constructor doc repointed from the removed
`child` to `initialWindows`.
- `widgets/_window_win32.dart` — removed "This can be overridden via the
`[WindowingOwnerWin32.test]` constructor.". `git log -S
"WindowingOwnerWin32.test("` finds no commit that added that
constructor.
- `rendering/viewport.dart` — `[Viewport.slivers]` isn't a member;
`slivers` is a constructor parameter forwarded to `super(children:
slivers)`. We cannot reference another class's constructor parameter, so
this became `[Viewport]`'s `slivers`.
Towards flutter#192870
This is a prototype branch for moving
WindowManageroutside ofWidgetsApp.Our current approach where first window is "blessed" and other windows are anchored inside first window hierarchy is causing multiple issues:
In general there is no reason for one window to be special. Normally for a desktop application all windows should be equal. The closest we can get to this is to give each top level window its own Widgets/MaterialApp. While this duplicates some elements that should normally be shared, arguably it behaves better than doing what we do right now.
Ideally we'd want to split the App widget into shared and per window parts, but that will be a much bigger change.
With this branch the top level Dialog/Regular window have each their own MaterialApp widget and separate focus trees, solving the issues above.
PopupandTooltipwindow work and are anchored at proper place in window hierarchy (they should not be top level window). However we might want to consider a convenience Widget to anchoring these instead of usingViewAnchor+View.Screenshot of example app running in this mode - notice the Debug banner and widget inspector buttons in each window.