It's confusing to send two key press events. Instead, just send the
lower-level, non-char event.
The real fix will be to define a sensible key event protocol for Mozart, but
this patch unblocks people who are experimenting at higher layers of the stack.
This patch cleans up the way we expose Mojo services into Dart. It also adds a
service provider for "view services," which will evetually contain the raw
keyboard service.
Also cleans up the messages when errors occur in both modes. I have also made the API a lot simpler and moved more of the extraneous stuff out of public. Only FlutterViewController and the Dart project configuration are publically available.
It is called each time the embedder initializes a Flutter view controller. The Mac shell (which does not have a view controller), calls it before NSApplicationMain.
Common items like the base::AtExitManager and the platform message loop are stored in `EmbedderState`
* Remove engine code from SkySurface into the controller.
* The public API exposed by Flutter.framework for third-party embedders is present ios/public.
* Public view controller API uses idiomatic Objective-C and is subclassable by consumers.
* Paves way for moving the embedder into a framework.
Each view gets its own Dart isolate. Unfortunately, the ShellPtr is a unique
resource, which means we need to proxy an implementation of Shell to each view.
In the future, we should probably switch dart to expect an ApplicationConnector
rather than a Shell.
* Use Node::Combinator::PRUNE, which stops the Mozart launcher from showing red
when we're loading child views. Instead of blocking the whole app, we'll now
just prune away the children that aren't ready. Eventually we'll want
to let authors control these operations.
* Grab the service registry in AcceptConnection rather than CreateView. The
CreateView comes from the Mozart launcher, which isn't where we want to get
the service registry. Now we get the service registry from the first app to
connect, which isn't right either but at least works while we sort out what
we really want.
- Correctly enable accessibility on startup if it's already enabled.
- Avoid using deprecated APIs.
- Map FORWARD/BACKWARD scrolling actions to up/down even when left/right
is also possible.
- Clear the accessibility focus when removing a focused semantics node.
- Unregister listeners when view goes away.
- Call setWillNotDraw(false) if accessibility is enabled.
- Clean the handling of hover events.
- Work around an Android bug where the system focus rect isn't drawn
the first time.
* The embedder depends on dynamic:embedder
* The dylib depends on dynamic:dylib
* The embedder calls OnLoad and OnUnload callbacks that setup and teardown the dylib environment
* The dylib contains a thin library that services OnLoad, OnUnload and OnInvoke so that vendors dont have to do it themselves (and potentially mess it up)
* The vendor only has to implement the `FlutterServicePerform` method that takes a fully scoped handle
* This patch is a WIP till we get a stable Flutter ABI. The stuff in mojo/public is *NOT* stable
This lets you focus and unfocus a node.
Still doesn't seem to be enough to actually have the node exposed in
TalkBack. We probably need hover for that (that's next).
(Also fixes a leak for when a subtree has been disconnected; previously
we were only forgetting the top node of the subtree, not the
descendants. Thanks @krisgiesing for catching that.)
This is another step towards enabling accessibility for Flutter on
Android. It exposes the semantics tree to Android's accessibility API
when accessibility is enabled.
It does not yet:
- allow one to actually interact with the application via the
accessibility API
- expose the accessibility tree to touch exploration
- implement the accessibility focus API
However, you can see the tree if you run uiautomatorviewer. It is there,
and it matches the UI. At least in Stocks. I didn't test anything else.
