9 Commits

Author SHA1 Message Date
James Clarke
3295bebabd
Windows: Add UWP target stub [Flutter#14697] (#21754) 2020-12-06 11:03:02 -08:00
George Wright
62d50af37e
Add plumbing for command line arguments on Windows (#22094) 2020-10-28 18:07:03 -07:00
stuartmorgan
6eacdce880
[windows] Allow engine flags via environment vars (#21161)
Replaces the (temporary) compile-time option to pass engine switches
with the ability to pass them temporarily at runtime via environment
variables.

This is enabled only for debug/profile to avoid potential issues with
tampering with released applicaitons, but if there is a need for that in
the future it could be added (potentially with a whitelist, as is
currently used for Dart VM flags).

Windows portion of:
https://github.com/flutter/flutter/issues/38569
https://github.com/flutter/flutter/issues/60393
2020-09-22 12:34:24 -07:00
stuartmorgan
efe7683311
Add an explicit API for font change notification (#21164)
Originally font change notification was handled by forwarding
WM_FONTCHANGE to the Flutter HWND, to avoid adding new API surface, but
that's not a good solution in a multi-window scenario, and it would
require a completely different solution for UWP. It also requires
non-obvious plumbing in the runner.

This replaces that with an explicit API, so that there's a clean and
obvious way for the runner to trigger this event.
2020-09-16 09:47:21 -07:00
stuartmorgan
32b1b70e27
[windows] Expose the binary messenger from FlutterEngine (#20551)
Relands https://github.com/flutter/engine/pull/20399

Makes BinaryMessenger available from FlutterEngine, rather than just the plugin registrar. This allows for method channels directly in applications without building them as plugins, and matches the other platforms.

Requires some restructuring of code and GN targets in the client wrappers to make the internals in the shared section usable by the implementations of platform-specific parts of the wrappers. Also fixes a latent issue with EnableInputBlocking symbols being declared but not defined for Windows that came up during testing of the restructing.

Fixes https://github.com/flutter/flutter/issues/62871
2020-08-17 05:44:48 -07:00
stuartmorgan
3ebcde6a17
Revert "[windows] Expose the binary messenger from FlutterEngine (#20399)" (#20550)
This reverts commit 7fa21a45a64b1a4a642c57bb81d7f3bd67cd5f5e.
2020-08-16 14:49:19 -07:00
stuartmorgan
7fa21a45a6
[windows] Expose the binary messenger from FlutterEngine (#20399)
Makes BinaryMessenger available from FlutterEngine, rather than just the plugin registrar. This allows for method channels directly in applications without building them as plugins, and matches the other platforms.

Requires some restructuring of code and GN targets in the client wrappers to make the internals in the shared section usable by the implementations of platform-specific parts of the wrappers. Also fixes a latent issue with EnableInputBlocking symbols being declared but not defined for Windows that came up during testing of the restructuring.

Fixes https://github.com/flutter/flutter/issues/62871
2020-08-16 14:28:57 -07:00
stuartmorgan
cd4192d4ee
[windows] Rework controller/engine interaction in the API (#20266)
Changes the interaction between the view controller and engine in both the C API and
the engine API, so that there's always an engine (as on other platforms) rather than
the engine APIs being specific to headless mode.

While adjusting the C API, this does a large cleanup:
- Renames all methods to follow a `FlutterDesktop` (prefix) + "class" name + method-style name.
  E.g., `FlutterDestkopViewControllerCreate` rather than `FlutterDesktopCreateViewController`.
  This makes it easier to see what functions operate on which conceptual "object" in the API.
- Reorders and groups them by the object they operate on.

Fixes https://github.com/flutter/flutter/issues/61966
2020-08-10 09:41:18 -07:00
stuartmorgan
9178074e9a
[windows] Separate the engine from the view (#19896)
Refactors the Windows embedding internals to make an engine object that
owns things associated with the engine rather than the view, and updates
the API surface to allow using the engine directly.

This is an incremental step toward both a cleaner, non-struct-based
internal structure and a finalized API surface.
2020-08-05 08:09:13 -07:00