* Revert "Fix documentation build for window changes. (#21780)"
This reverts commit 931a04683d6eb49fc92059b2384ac5b1618d5422.
* Revert "Migration to PlatformDispatcher and multi-window (#20496)"
This reverts commit 85b0031f73544e448354047dc6a236c0b0808252.
This is a PR for converting the dart:ui code in the engine to use a multi-window API. The goal here is to convert from the window singleton to an API that has the concept of multiple windows. Also, I'm matching up the new PlatformDispatcher class to talk directly to the PlatformConfiguration class in the engine. I'm not attempting to actually enable creating multiple windows here, just migrate to an API that has a concept of multiple windows. The multi-window API in this PR currently only ever creates one window.
The design doc for this change is here.
The major changes in this PR:
Move the platfom-specific attributes out of Window, and into the new PlatformDispatcher class that holds all of the platform state, so that the platform code need only update the configuration on this class.
Create FlutterView, FlutterWindow, and SingletonFlutterWindow classes to separate out the concepts of a view (of which there may be multiple in a window), a window (of which there may be multiple on a screen, and they host views), and a window where there is only ever expected to be one (this hosts the entire API of the former Window class, and will eventually be the type of the window singleton).
Next step after this PR lands:
Remove the Window class entirely (it is replaced by SingletonFlutterWindow). Some minor changes in the Framework are needed to switch to using SingletonFlutterWindow directly first.
The Window class still exists in this PR, but will be removed as soon as the framework is converted to point to the SingletonFlutterWindow class instead. They share the same API, just have different names (Window is currently a subclass of SingletonFlutterWindow). The intention is that the Window name will be freed up to use as a widget class name in the framework for managing windows. The singleton called window will remain, and keep the same API it has now.
Replaces the (temporary) compile-time option to pass engine switches
with the ability to pass them temporarily at runtime via environment
variables. This moves the recently-added code for doing this on Windows
to a shared location for use by all desktop embeddings.
This is enabled only for debug/profile to avoid potential issues with
tampering with released applications, 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).
Temporarily adds a way to enable mirrors as a compile time option,
as is already provided in the Linux embedding, to provide a migration
path for the one remaining known need for compile-time options
that has been raised in flutter/flutter#38569.
This patch applies the following changes:
* Rename a stray .cc file to .mm (connection_collection.cc).
* Migrate Objective-C #includes to #import as per the style guide.
* #include/#import order updated to reflect the style guide order:
associated header, system/standard library headers, library headers,
platform-specific includes.
* Include cstring where we're using strlen.
* Add a missing copyright header in SemanticsObjectTest.mm.
Bugs: https://github.com/flutter/flutter/issues/60025
Queries the system list of user-preferred languages, and sends it to the
engine just after starting it up, as well as after any OS locale change.
macOS portion of https://github.com/flutter/flutter/issues/45152
It looks like half the code in this function was updated to use the
main bundle but this one line was still only using the _dartBundle. I am
pretty sure that is a mistake and instead we want to use the mainBundle
as a backup both to find the plist and to find the assets.
Started cleaning up the accessibility handler when the bridge is
deleted and made nilling out channels safer by making sure they don't
overwrite newly setup handlers.
The NSEvent->Flutter event conversion code for pointer events was
multiplying seconds by nanoseconds per milliseconds. While this does end
up giving the right number of microseconds, it's a very confusing way to
write it.
Fixes a bug where deleteBackward was checking for being at the start of
the text before checking for a non-empty selection, breaking deletion
when the entire text field was selected.
Also removes an (incorrect) post-deletion position update that was
redundant with code in insertText:replacementRange:, and thus having no
effect.
Fixes https://github.com/flutter/flutter/issues/46150
This fixes the selection and deletion during text editing on macOS so that it can handle selections that have a base (selection start) that is after the extent (selection end) in the string.
Apparently the insertText:replacementRange on macOS can supply an NSRange object that has negative values for the length (even though the length is an unsigned NSUInteger). This change checks for that case, and fixes the range of characters replaced in the text to have the right bounds.
Also, I added an additional updateEditState after the state is set from the framework, since there is a timing problem: when the delete key is pressed, it sends an insertText message, which updates the framework state after the framework has already sent its state update to delete the selected region. This additional updateEditState puts the engine and framework back in sync again. Ideally, we would just avoid sending the insertText message, but there's really no way for the engine to know if the pressed key is part of an edit sequence or not.
Also creates a new test harness for the desktop embedder framework target and adds a test that launches a headless engine in this new thread configuration.
Fixes https://github.com/flutter/flutter/issues/17579
The view was being accessed from a background thread so its OpenGL context could be accessed. This tripped thread safety assertions in Cocoa. Now the OpenGL context is stashed in the FlutterEngine instance itself.
Creates a starting point for an app delegate. For now it just
incorporates the menu and window renaming functionality that's currently
in the FDE example, but in the future this will also do forwarding of
application lifecycle events to plugins.
Fixes https://github.com/flutter/flutter/issues/32419
In generated text fixture location lookup code:
When the second argument to write_file() is a list, it is written one
item per line to the path specified by the first argument. This ensures
that we emit a trailing newline at EOF to comply with -Wnewline-eof.
Elsewhere:
Lack of a newline at EOF was undefined behaviour prior to C++11. The
Fuchsia tree sets -Wnewline-eof in its buildroot, so we plan to do the
same. This cleans up remaining first-party C++ sources that don't
include a trailing newline.
Adds initial use of App.framework in the macOS project configuration,
using that rather than the main bundle as the default Dart bundle, and
expecting flutter_resources to be located there.
This is an incremental step toward aligning with the behvaior of the iOS
version of this class.
Fixes https://github.com/flutter/flutter/issues/38363
Renames all FLE* classes in the macOS embedding to Flutter*. With the exception
of -[FlutterDartProject engineSwitches], which is very clearly called out in the
comment, the APIs should be stable at this point, so the marker prefix is no
longer needed.
This is a breaking change for macOS embedders, but going forward breaking
changes at the source level for the macOS API should now be rare.
Some of these classes will likely merge with the iOS versions in the future (e.g.,
FlutterDartProject), but that will be an implementation detail that will not affect
clients.
Fixesflutter/flutter#31735
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.
Updates the way FLEViewController and FLEEngine interact,
making their APIs much more closely aligned with the iOS versions
of the classes.
As part of the change, removes the need for an explicit launch
call on FLEViewController. Also adds entrypoint support when
running an engine directly, matching iOS.
Breaking change for macOS runners.
Part of https://github.com/flutter/flutter/issues/31735
Rather than clients needing to create an appropriate view in a XIB and
attach it to an FLEViewController, which is error-prone, have
FLEViewController create its own view programatically. The view is now
an internal detail, so calling setView: on an FLEViewController will no
longer work.
As a result of the view being internal, the public API surface is
simplified.
This is a breaking change for macOS Runners.
Adds an initial version of FLEDartProject, which contains the
configuration for running the engine. In the future this will align with
FlutterDartProject, and likely share a significant portion of the
implementation.
This is a breaking change for macOS runners.
Creates an initial, minimal FLEEngine that parallels the iOS
FlutterEngine, and moves engine launch, plugin registration, and binary
messenger functionality from FLEViewController to there. Uses the FLE
prefix since the current APIs will change to better match FlutterEngine;
the current APIs are intended to minimize conceptual changes relative to
the current FLEViewController APIs since it's already a substantial
change.
Further changes will move channels from FLEViewController to FLEEngine,
and further align the APIs and functionality with the iOS version.
Part of #32421
Made the engine and the view controllers have BinaryMessengers, not be
BinaryMessengers. This allows us to break retain cycles and makes the
leaking channels we have not less dire.
When the macOS framework was initially landed, it included some iOS code
using a localized hack. This reorganizes the code structure to clearly
indicate which files are shared between iOS and macOS, vs. those that
are platform-specific.
