WIP: Multiwindow Preview based on FFI #165072

knopp · 2025-03-12T18:28:36Z

This is initial prototype for multi-window implementation based on FFI. Contains basic implementation for macOS, Windows and Linux platforms.

The purpose of this PR is to gather feedback on the approach and design. It definitely needs polish and work.

The PR is a bit noisy right now since it contains code from other PRs that are not yet merged.

Interesting bits are inside
packages/flutter/lib/src/widgets/window.dart
packages/flutter/lib/src/widgets/window_win32.dart
packages/flutter/lib/src/widgets/window_macos.dart
packages/flutter/lib/src/widgets/window_linux.dart
engine/src/flutter/shell/platform/darwin/macos/framework/Source/FlutterWindowController.mm
engine/src/flutter/shell/platform/linux/fl_windowing.cc
engine/src/flutter/shell/platform/windows/flutter_host_window_controller.cc

Basic usage

Creating a Window

  final RegularWindowController controller = RegularWindowController(
    size: const Size(800, 600),
    sizeConstraints: const BoxConstraints(minWidth: 640, minHeight: 480),
    title: "Multi-Window Reference Application",
  );

This will synchronously create new platform window and the corresponding FlutterView. When the controller constructor returns the FlutterView can immediately be placed to widget hierarchy:

  runWidget(
    RegularWindow(
      controller: controller,
      child: MaterialApp(home: MainWindow(mainController: controller)),
    ),
  );

RegularWindowController is a factory and returned instance is a platform specific subclass, so it can be casted to access platform specific features.

for example

final macOSController = controller as RegularWindowControllerMacOS;
macOSController.setWindowCollectionBehavior(...);

or

final windowsController = controller as RegularWindowControllerWin32;
// Register a custom WIN32 message handler for this window.
windowsController.registerMessageHandler(handler);

(This being synchronous and FFI based we are actually able to route windows messages to Dart where they can be handled if needed, allowing for example for a custom NC_HITTEST implementation that can do actual Flutter hittesting to determine draggable window area).

Out of tree embedders

This approach scales to out of tree embedders as well. Out of tree embedder would subclass WidgetBinding and override the createWindowingOwner method. That is entry point for windowing implementation responsible for creating platform specific window controllers.

The out of tree embedders can then provide RegularWindowControllerHarmony for example, which must implement the common functionality required by RegularWindowController, but can also provide custom, platform specific functionality.

One benefit of this approach is that the platform interface is defined in Dart, rather than being an informal platform channel protocol, so when changes are made to common interface (RegularWindowController) that out of tree embedder does not expect, it will fail at compile time rather than runtime.

The out of tree embedder code can be provided as package.

Pre-launch Checklist

I read the Contributor Guide and followed the process outlined there for submitting PRs.
I read the Tree Hygiene wiki page, which explains my responsibilities.
I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
I signed the CLA.
I listed at least one issue that this PR fixes in the description above.
I updated/added relevant documentation (doc comments with ///).
I added new tests to check the change I am making, or this PR is test-exempt.
I followed the breaking change policy and added Data Driven Fixes where supported.
All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

justinmc

It's tricky to review this because of the older PRs that this is branched off of, but it looks great from what I see.

Easiest case for app developers: I'm writing a cross-platform desktop app and I don't care about the details and just want to create a couple of windows and control their size/title/state.
- Use RegularWindowController and its .modify method.
Still doable: I'm writing say a Linux-only app, and I want to use something that's only available in the Linux windowing API.
- Use LinuxWindowController.

And it seems like we as framework/engine developers are able to modify Linux/Windows/MacOSWindowControllers independently if we want to add some new platform API.

Those were the main things I was looking for and they all seem to work the way I hoped they would 👍

justinmc · 2025-03-12T20:52:22Z

packages/flutter/lib/src/widgets/window_linux.dart

+
+  @Native<Void Function(Pointer<Void>, Int64)>(symbol: 'flutter_set_window_state')
+  external static void _setWindowState(Pointer<Void> windowHandle, int state);
+}


So if in the future Linux adds some new window method that we want to support, we can just add it here without messing with RegularWindowController, WindowController, etc. right?

Yes, that's exactly right. We can add platform specific functionality independently, and then when if we later decide that something is generic enough to support on all platform add it to RegularWindowController.

loic-sharma · 2025-03-13T00:09:37Z

engine/src/flutter/shell/platform/windows/flutter_host_window_controller.cc

+}
+
+FLUTTER_EXPORT
+void flutter_set_window_state(HWND hwnd, int64_t state) {


Is there a reason to implement this in C++ instead of Dart? Did you consider FFI'ing straight to win32? Something like this: https://github.com/halildurmus/win32/blob/27496b847b9ce831db798203238e4aa847e87d54/packages/win32/lib/src/win32/user32.g.dart#L9200-L9214

For trivial things I already call win32 API directly, for example _setWindowTitle calls SetWindowTextW, _destroyWindow calls DestroyWindow. Here i went this way because it seemed simpler (needs less declarations and constants), in reality there is nothing preventing us from calling win32 api directly.

That's a completely reasonable answer, but I suspect that more lines of code is a good trade-off for moving more of the logic to Dart.

Customers know how to debug Dart code. However, they might be significantly less comfortable debugging C++ code. The more logic is in the Dart layer, the more accessible that logic is to our customers.

Of course, this is a balancing act. If there are areas where Dart FFI to win32 is significantly less readable/maintainable, we should stick to C++.

loic-sharma · 2025-03-13T00:46:05Z

packages/flutter/lib/src/widgets/binding.dart

+
+  /// Creates the [WindowingOwner] instance available via [windowingOwner].
+  /// Can be overriden in subclasses to create embedder-specific [WindowingOwner]
+  /// implementation.


Is it hard to switch an app to a WidgetsBinding subclass? What would an app entrypoint look like if I need to support a third-party embedder? I imagine you won't be able to use runApp anymore?

Spitballing: should we instead have a model where you set your desired windowing owner if you have a third-party embedder?

In today's world, something like:

void main() { if (onPlatformFoo) { WidgetsBinding.instance.defaultWindowingOwner = WindowingOwnerFoo(); } runApp(...); }

Of course the third-party platform could provide a helper to do all the necessary registration.

If the "custom platforms set stuff" model works, we could extend this to allow embedders to inject Dart code that's invoked at Isolate start up, before main executes. For example, today we allow embedders to inject a Dart plugin registrant which the engine invokes before invoking main. This would allow embedders to register their custom Dart implementations automatically without the user needing to add code to their main function.

FYI, WidgetsBinding.platformMenuDelegate appears to be useful prior art. It's a member on the widgets binding that a third-party platform can override to implement their own functionality. See: https://api.flutter.dev/flutter/widgets/PlatformMenuDelegate-class.html

This was honestly only a first draft. If widget binding subclass is too much friction we can just make the owner field non-final.

This was honestly only a first draft.

Yup, and it's a great first draft! Sorry for nitpicking so early in the process haha

If widget binding subclass is too much friction we can just make the owner field non-final.

That sounds good to me.

knopp added 11 commits March 11, 2025 13:31

Add multiwindow example app (windows)

5d9eca2

Add multiwindow switch

436e790

Windows implementation

ecfdfe9

Disable platform channel tests

264a485

Multiwindow example (macOS)

3571e1e

Merge macos_merged_ui_thread

910187c

Keep engine reference

6f04c33

Add macOS implementation

633b82f

Linux windowing

0058664

temporarily disable resize syncrhonization on linux

9574b37

Use Gtk methods

6317529

justinmc reviewed Mar 12, 2025

View reviewed changes

loic-sharma reviewed Mar 13, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

WIP: Multiwindow Preview based on FFI #165072

WIP: Multiwindow Preview based on FFI #165072

knopp commented Mar 12, 2025 •

edited

Loading

justinmc left a comment

justinmc Mar 12, 2025

knopp Mar 12, 2025

loic-sharma Mar 13, 2025

knopp Mar 13, 2025

loic-sharma Mar 13, 2025

loic-sharma Mar 13, 2025 •

edited

Loading

loic-sharma Mar 13, 2025

knopp Mar 13, 2025

loic-sharma Mar 13, 2025

WIP: Multiwindow Preview based on FFI #165072

Are you sure you want to change the base?

WIP: Multiwindow Preview based on FFI #165072

Conversation

knopp commented Mar 12, 2025 • edited Loading

Basic usage

Creating a Window

Out of tree embedders

Pre-launch Checklist

justinmc left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

loic-sharma Mar 13, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

knopp commented Mar 12, 2025 •

edited

Loading

loic-sharma Mar 13, 2025 •

edited

Loading