Converts the macOS embedding to use the new proc table version of the embedding API, and adds one example unit test using it to demonstrate and validate the approach.
The Flutter framework now has handling for arrow keys and backspace
in its editable text, so they no longer need to be handled in the
embedding. This not only avoids duplicate work, but improves the
handling of complex unicode (surrogate pairs, grapheme clusters) which
are currently correctly handled in the framework but not the macOS
embedding.
Fixes https://github.com/flutter/flutter/issues/68497
This re-lands #20496 and #21780 after fixing the semantics-enabling code that was causing the post-submit web_smoke_test to fail.
Below is the description from the original PR:
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.
This removes most of the remaining FLUTTER_NOLINT comments and opts
these files back into linter enforcement.
I've filed https://github.com/flutter/flutter/issues/68273 to require
that all FLUTTER_NOLINT comments be followed by a GitHub issue URL
describing the problem to be fixed.
* 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 embedder.h API layer is an implementation detail of the desktop
embeddings, not part of the public API surface, so should not be part of
the public symbol list for those libraries.
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.
This is a step toward aligning the API with macOS, and will make it easier to add the precompiled library later for release mode (since it can just be added to the project directory, without any code changes required for wrapper clients).
At the C API, uses a struct instead of individual arguments, mirroring a change that was already made on the Linux side to make the C API cleaner.
Functional changes in addition to the restructuring:
adds relative path support, as was recently added for GLFW
Uses wstring, rather than string, for paths; the conversion to UTF-8 is actually a potential problem on Windows, so pushing it into the embedding allows us the possibility of removing it later (if we can figure out a good solution at the embedder.h layer) without API breakage.
The old APIs used by the standard runner are left in place for now to avoid breaking the template on an engine roll. Once the framework template has been updated, the old API paths will be removed.
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 was only necessary when the Engine had to build in multiple buildroots
where the sources where checked out at different paths relative to the
buildroot. This is no longer the case and there are already cases GN rules
have been written that mix and match variable usage with the direct
specification of the path to the Flutter sources relative to the sole buildroot.
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
