Expose Flutter-hosted secondary window creation and lifecycle APIs

[Azzeccagarbugli]

Description

WindowManager.create(...) is referenced in the Window documentation, but it is not currently exposed by WindowManager. The underlying native API can create a native window, but that window is not connected to a Flutter engine/view and therefore cannot render Flutter widgets.

It would be useful to support secondary Flutter-rendered desktop windows entirely through the Dart API, without requiring applications to modify Swift, Objective-C, C++, or runner code.

Proposed capability

final toolbar = await WindowManager.instance.createFlutterWindow(
  entrypoint: 'toolbarMain',
  arguments: {'parentWindowId': mainWindow.id},
  configuration: const WindowConfiguration(
    titleBarStyle: TitleBarStyle.hidden,
    backgroundColor: Color(0x00000000),
    resizable: false,
    movable: false,
    focusable: true,
    hasShadow: false,
  ),
);

The API should:

• Create and attach a Flutter engine/view to the new native window.
• Support transparent, frameless windows.
• Accept a Dart entrypoint and serializable initial arguments.
• Return a stable Window instance and identifier.
• Expose explicit close() or destroy() functionality.
• Emit created, closed, moved, resized, focused, blurred, minimized, and restored events.
• Support communication between Flutter windows without application-owned native code.
• Allow an optional owner/parent window relationship where supported.
• Document plugin registration behavior for secondary Flutter engines.

Use case

A Flutter macOS application needs a small floating Flutter toolbar positioned above its main window, similar to the iOS Simulator toolbar. The toolbar must follow the main window while moving, resizing, minimizing, restoring, focusing, and closing.

Acceptance criteria

• A second window can render an independent Flutter widget tree.
• The example app demonstrates creating, configuring, communicating with, and closing it using Dart only.
• Transparent backgrounds work correctly on macOS.
• Window creation and closure events are delivered reliably.
• Existing single-window behavior remains unchanged.
• Unsupported platforms fail predictably or return a documented capability result.

This would also resolve the mismatch between the documented WindowManager.create(...) example and the currently available public API.

Thanks a lot, this would be perfection (and let me know if I can work on this) ✨