This file doesn't belong in the SDK because it is an implementation detail of
the Sky engine. Instead, this CL moves the code for dart:sky.internals into the
snapshot. This CL is a step towards merging dart:sky.internals with dart:sky,
which also resides in the snapshot.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/1200953007.
ServiceRegistry enables a chain of Mojo applications to accumulate
services without wrapping and forwarding the incoming ServiceProvider
request.
Sky's DocumentView adds ViewManagerClient to the ServiceRegistry (if any)
that's provided to it via ConnectToApplication(). Sky applications can add
additional services with embedder.serviceRegistry.addServices().
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/958673002
These now appear on internals as takeServicesProvidedToEmbedder and
takeServicesProvidedByEmbedder. When you call these functions, you get back the
raw int that represents the handle. We'll need to wrap them up inside the Dart
VM with the appropriate types. We can create a nice wrapper for that in a
future CL.
R=hansmuller@google.com, hansmuller@chromium.org
Review URL: https://codereview.chromium.org/944733002
Instead of mojo.Shell and mojo.Application being clients of each other
they are now separate interfaces. An implementation of mojo.Application
receives a handle to the shell in its Initialize call, as described in
this doc:
https://docs.google.com/document/d/1xjt_TPjTu0elix8fNdBgWmnjJdJAtqSr1XDS_C-Ct8E/edit?usp=sharing
An analogous change is made to the content handler definition.
In C++, this is handled by the mojo::ApplicationImpl class which stores
shell handle in its implementation of Initialize. Thus the only change
for most C++ applications is the meaning of the handle in MojoMain is
different, although mains that use the ApplicationRunners do the same
thing with it. Connecting to other apps is largely the same although
instead of grabbing the ApplicationImpl's client() to talk to the shell
code must now use the ApplicationImpl::shell() getter.
In JavaScript, the initialization sequence is a bit different although
this is hidden mostly in the Application class which calls initialize()
on its subclass with the same set of parameters. Connecting to another
application looks different, especially for sky code using the shell
proxy handle exposed via internals. Hans has some ideas about how to
make this a bit nicer.
Python apps similarly need to change their startup sequence a bit. I
didn't find a common library to take care of this dance, although it's
possible I just missed it.
Other languages probably a bit of reworking - I fixed everything here
that is covered by mojob.py test but some might be missing.
This patch also uses typed handles (i.e. InterfacePtr<> or
InterfaceRequest<> or their type aliases) wherever possible instead of
ScopedMessagePipeHandle for clarity.
R=davemoore@chromium.org
Review URL: https://codereview.chromium.org/868463008
This removes the symmetrical nature of ServiceProvider and consistently
passes and uses a ServiceProvider + ServiceProvider& pair in places that
wish to bidirectionally expose services, such as the view manager.
The
view manager library now deals with InterfaceRequest<ServiceProvider>
and ServiceProviderPtr objects (i.e. c++ wrappers for handles) instead
of a concrete implementation of ServiceProvider to make it easier for
callers.
A number of places that were assuming a particular
ServiceProvider would always exist are updated to reflect the nullability
of the parameters in mojom and places that do not wish to ever look up
or provide services now pass nullptr instead of doomed pipe handles.
The JS application startup classes are reworked a bit to accomodate
exposing services on the third ConnectToApplication/AcceptConnection
parameter.
BUG=449432
R=abarth@chromium.org, sky@chromium.org
Review URL: https://codereview.chromium.org/858103002
In preperation for removing the Client annotation from ServiceProvider
this passes a second parameter of type ServiceProvider in the shell and
application Connect calls. In this patch the type signatures are updated
but the second parameter is basically unused. The intention is that the
first parameter |services| will be used for the connecting application to
request services from the connected application (as it does currently)
and the second parameter |exported_services| be used for the connecting
application to provide services to the connected application. We have
very few services exported in the second direction today - I'll update
them to use the second parameter in a follow-up patch.
R=darin@chromium.org
Review URL: https://codereview.chromium.org/845593003
Enable Sky applications to be written in terms of the Application,
Shell, ServiceProvider classes.
Add a shellProxyHandle() method to the Sky Internals class. It returns
a message pipe handle that the JS Shell class will assume ownership of.
BUG=
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/837283002
This is a proof of concept for replacing ui/views
code with Sky instead. erg says this will allow him
to delete 10s of thousands of LOC from mojo.
Mojo does not yet expose the current binary's URL:
https://docs.google.com/a/chromium.org/document/d/1AQ2y6ekzvbdaMF5WrUQmneyXJnke-MnYYL4Gz1AKDos
So I've worked around that by passing the url
of the binary via the helper script.
I discovered several bugs in the wm_flow code
including that it doesn't handle view resizes
(during embiggen). Related, I discovered that
every time a new window is made it drops the
connections to the embedded.cc app from the
previous window, since the ViewManagerDelegate
is incorrectly implemented as part of the
ApplicationDelegate on both app.cc and embedded.cc.
We'd need to split out a separate per-view object
in both of those apps to handle the
ViewManagerDelegate calls.
There are some changes to logging during loading
as well as the CopyToFile helper to have better
error reporting. I hit several issues early on trying
to get mojo to load the http: urls correctly, including
eventually running out of disk space on my /tmp
and mojo then silently failing to launch the app
(due to mojo never clearing its caches crbug.com/446302).
I had to re-write the mojo_demo.sh script in python
as well as split the sky_server handling code out of
skydb into a separate python module in order to cleanly
launch sky_server. We could use a separate server
if we wanted to but the primary benefit of sky_server
is that it sets up the proper url->disk mappings into
the generated file directories, etc.
BUG=443439
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/817573003
-Add a --testing flag to sky_viewer and cause it to paint into an
SkBitmap instead of a ganesh surface so we can get the pixels out.
-Add GetPixelsForTesting to layer.cc to actually grab out the pixels.
-Add a reftest and a mismatch reftest. They need a setTimeout after
the load event. Unclear why or what the right fix is. Maybe we should
give internals some way to force the paint? If we don't have the
setTimeout, we paint a white page (so we do a paint, but with no
content).
-Add a DisplayDelegate to Layer so that Viewer can decide whether
to use the real ganesh backend or the SkBitmap one without littering
the whole code-base with is_testing bools and logic.
R=esprehn@chromium.org
Review URL: https://codereview.chromium.org/797063002
This patch remove the Web Animations & CSS Animation runtime flags (and enables both). Removes prefixed Aninamations & Transitions and adds some basic tests & test support API.
R=ojan@chromium.org
Review URL: https://codereview.chromium.org/760183003
Move mojo/bindings/js to mojo/edk/js.
Move mojo/bindings/js/tests/run_js_tests.cc into the test directory.
Move mojo/apps/js/test/handle_unittest.cc to mojo/edk/js
BUG=430520
R=jamesr@chromium.org
Review URL: https://codereview.chromium.org/690743003
