Adds a flag to create non-resizeable windows.
Since the number of parameters is getting awkward, extracts
window-related parameters and engine-related parameters into structs for
clarity. This also removes some duplication in method signatures.
The window parameters struct change is also made to the C++ wrapper,
making this a breaking change for the runners.
Fixes https://github.com/flutter/flutter/issues/37623
Rather than running the runloop forever, have the API expose an incremental runloop. This allows clients to do other processing if they need it.
This allows for removing the odd construction of having knowledge of GTK event handling built into the library even though nothing in the library uses it; instead runner applications that use GTK plugins (such as FDE's testbed) can do that processing at the application level instead.
Start work on flutter/flutter#30726 by adding an alternative win32 shell platform implementation for Windows that is not based on GLFW and that uses LIBANGLE for rendering and native win32 windowing and input. This change does not replace the GLFW implementation but rather runs side by side with it producing a secondary flutter_windows_win32.dll artifact. The following items must be added to attain parity with the GLFW implementation:
- Custom task scheduling
- Support for keyboard modifier keys
- Async texture uploads
- Correct high DPI handling on Windows versions < 1703
and will be added in subsequent changes.
embedder.h is a C API, so has no namespace, and only uses 'Flutter' as a
prefix for most symbol names. This creates potential collisions with
other code; for instance, FlutterEngine is the name of a type in
embedder.h, but also an ObjC class in the iOS Flutter API.
This adds a macro that can be set to prefix symbol names, allowing
clients (notably, the macOS embedding) to adjust the names used by the
embedding API internally without breaking ABI or API compatibility for
the standard engine build.
Currently the macro is only applied to FlutterEngine, since that's the
symbol that is currently at issue, but it can be expanded to other
symbols in the future.
In some cases, the window needs to be redrawn without a resize. This
adds a callback for that case to trigger a repaint.
Since there's no embedding API for repainting, trigger it with a window
metrics event using the current window size.
Fixes https://github.com/flutter/flutter/issues/30731
* Allow specifying both Dart and non-Dart fixtures in engine unittests.
This fixes numerous issues in the way in which fixtures were managed
in the engine unit-tests.
* Instead of only being able to specify Dart fixtures, unit-tests may specify
non-Dart fixtures as well. These are simply copied over to the fixtures
directory known to the unit-test at runtime.
* An issue where numerous Dart files could be given to the kernel snapshotter
has been addressed. It was anticipated that such a (legal) invocation to the
kernel snapshotter would produce a snapshot with the contents of all the Dart
files added to the root library. This is incorrect and the behavior in this
case is undefined.
* Dart files referenced by the main Dart file are correctly tracked via a
depfile.
* The snapshotter arguments have been cleaned up to get rid of unused
arguments (`—strong`) and the use of the VM product mode argument has been
corrected to no longer depend on the Flutter product mode.
- Makes json_method_codec.cc compatible with the last stable RapidJSON release.
- Allows removing the GTK dependency with a compile flag.
- Fixes a missing break in a switch flagged by some toolchains.
Adds methods to get and set the window size, as well as to query the
window's scale factor. This is useful both for custom clients, and for
building a window resize plugin to prototype what will eventually likely
be a system channel.
Plugins may need to be able to access functions affecting the GLFW
window (e.g., a plugin to resize the window). This restructures the API
to create a distinction at both the C and C++ level between the window
controller, which provides access to high-level behaviors driving the
Flutter application, and the window, which provides access to functions
to affect the UI state of the window (i.e., wrapped GLFWwindow
functions).
Also provides a PluginRegistrar extension for plugins that need access
to GLFW-specific functionality.
Since the GLFW shell is likely to continue to exist in at least the
medium term, it is useful for maintenance to be able to build and use it
on any desktop platform.
Includes a buildroot roll to pick up the macOS build suppport for
third_party/glfw.
Simplifies the build and runtime requirements for the Linux shell.
Since the engine does GL extension lookup manually anway, an extension
loader library isn't necessary.
Changes include:
- File structure
- Header guards
- Include paths
- Namespaces
- Integration with the engine's GN build
- Conversion from jsoncpp to rapidjson
- Style and clang-format adjustment to match engine repository
