We're currently in a transition between using main.sky and main.dart
files as our main() entry point for Sky applications.
This CL makes this runtime controlable by path name. If it finds
a .dart in the path name it will use SkyView, otherwise it will
fall back to the existing WebView codepath.
SkyView does not expose a window object and much of the existing
Sky Engine is not initialized when main() is run. Clients should
be transitioning away from main.sky towards main.dart in the near
future, however main.dart is probably not ready for general
consumption at this point.
R=ianh@google.com
Review URL: https://codereview.chromium.org/1152313002
- New chromium clang rules require explicit external destructors so
system/lib added for MessagePipe, DataPipe and SharedBuffer
- New chromium clang rules require override and no virtual in
declarations, so many files updated.
- cc_strip_video patch updated.
BUG=
R=jamesr@chromium.org
Review URL: https://codereview.chromium.org/988693005
This patch makes it so that querystrings are no longer considered part of a mojo application's identity.
So if you connect to http://a?foo, then http://a?bar, you'll end up talking to the same application, just two different connections.
The URL of each connection is sent to the app via a new param in AcceptConnection().
This patch also adds some app tests that exercise http app loading, which wasn't tested before.
R=qsr@chromium.org
Review URL: https://codereview.chromium.org/943053003
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
This switches to using StrongBinding<>s in sky's ContentHandlerImpl
and TestHarnessImpl implementations.
These are the last uses of the deprecated InterfaceImpl<> helper in
the mojo repo (more uses exist in other repos).
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/934403002
Previously, the WebFrame need to be created with a data pipe consumer handle.
This CL makes it possible to create a WebFrame with a URL and have the engine
issue the network request.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/940703002
This CL causes sky/shell to create a blink::WebView to show that sky/shell
links with sky/engine. In the process, I've made it easier to be a trivial
embedder of sky/engine by removing the requirement to implement
blink::ServiceProvider.
This CL also causes sky/shell to link with mojo/edk/system to resolve link
errors with Mojo fabric (e.g., MojoClose, MojoWriteMessage, etc). To make this
work properly, we'll need to initialize the EDK in a future CL.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/873923003
The tracing service logically provides one service, TraceCoordinator, which can
start and stop tracing sessions. It also can connect to any number of
TraceControllers each of which can supply tracing information on demand.
Whenever an app connects to the tracing service, the tracing service attempts to
connect to that app's TraceController interface. If the app provides this
interface then tracing data will be requested whenever tracing starts. If the
app doesn't, then the pipe just closes. Thus apps that want to be traced can do
so by creating however many connections to the tracing service they want and
registering a TraceController implementation on each outgoing connection.
The shell connects in a similar fashion by connecting to the tracing service and
providing a TraceController implementation. The code looks a bit different since
the shell is special.
BUG=451319
R=viettrungluu@chromium.org
Review URL: https://codereview.chromium.org/791493006
Normal trace events already go directly to base. This CL removes the remaining
trace events that were still indirected through blink::Platform. These were
just the half-finished inspector timeline trace events, which currently aren't
actually hooked up to anything.
This CL also removes the redunant "convertable to trace format" wrappers and
moves their one remaining use over to just using the version in base directly.
R=eseidel@google.com, ojan@chromium.org
Review URL: https://codereview.chromium.org/889823002
After this CL, we first convert from mojo::Event to blink::WebInputEvent before
feeding the event to the gesture recognizer. That means we process touch and
mouse events in the same way (because they are both represented as pointer
events). As a result, we now recognize scroll and fling gestures from mice.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/888773002
In order to have a high-quality gesture system, we need to know many details
about the fine-grained structure of applications. For example, different parts
of the view might be interested in recognizing different gestures and when you
recognize a certain gesture depends on the set of possible gestures.
This CL is a first step towards implementing
https://github.com/domokit/mojo/blob/master/sky/specs/gestures.md by moving the
gesture recognition into Sky where finer-grained information will be available.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/868463010
This fixes the race which is seen where mojo_shell will sometimes
launch with the wrong viewport metrics since the DisplayManager
will happily respond to GetViewportMetrics with default values
before the NativeViewport has fully booted and told it what the
actual values are.
I considered making DisplayManager hang until the NativeViewport
was ready, but I decided that it does make sense for the
ViewportMetrics (device pixel ratio, mostly) to change for a
view if it were to move between displays (as exists on desktop
OSes today).
R=abarth@chromium.org, sky@chromium.org
Review URL: https://codereview.chromium.org/880743002
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 CL uses the aura fling curve to ease flings. Also, I've made Event#timeStamp
use consistent units and timebase with the requestAnimationFrame timestamp. Now
both are doubles of milliseconds since the epoch.
R=esprehn@chromium.org
Review URL: https://codereview.chromium.org/880473003
It causes a full screen raster right now, lets name it for what it does.
This also matches the name used in PageAnimator.
Merge WebWidgetClient into WebViewClient.
They're always the same thing in sky. I also removed all the methods that
don't do anything in sky.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/880713003
