1) Factors InkWell out of Material so that components can use an ink well
without needing the shadow/level machinery.
2) Makes the ink effect move at a different velocity once the tap has actually
occurred, converging with the spec. We don't have the right speeds yet, but
at least we're approaching the right shape.
3) To support (2), added a primaryPointer attribute to GestureEvents to let
authors coorelate gesturetapdown events with later gesturetap events.
4) To support (2), modernized SplashAnimation to used AnimatedValue and friends.
5) Added more constants to view-configuration.dart that match Android.
I've also removed the cancelling of the ink effect on scroll. The proper way to
do that is to notice that someone in the event chain is listening for
scrollstart and delay the beginning of the ink effect for some period of time.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/1019023003
This CL factors EditableString out of EditableText and implements more of the
InputConnection functions. As a result, EditableText now basically works.
This CL also paves the way to make EditableText stateless by using
EditableString as its state object. However, there's still a bit more work to
do to make that a reality (e.g., factoring out the cursor blink timer and the
connection to the keyboard).
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/995073002
This is not complete gesture support by far, but it's a start.
MojoShell and Chrome use a C++ GestureDetector, this code attempts
to use the Android (Java) GestureDetector instead.
We probably should not be sending gesturetap until we've decided
it's not a scroll, etc, but this implementation does not go that far.
I had to fix a bug whereby we were assuming the InputEvent.time_stamp
was in TimeDelta's internal format, which was wrong. When we get
time_stamp from Android its in ms since boot.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/969493002
However WebView::close() no longer crashes. close() is never called
in MojoShell since mojo can't shutdown yet.
I tried closing the existing WebView and replacing it
but somehow that caused it to only draw red. After a while
of looking at this with abarth we decided to just load into
the same WebView for now.
Eventually we should do something smarter where we start the
provisional load and only replace the webview once the new one is
ready, but that's a later CL.
R=abarth@chromium.org
BUG=
Review URL: https://codereview.chromium.org/952273003
This CL is the beginnings of an implementation of url_loader.mojom using the
OkHttp library. OkHttp is a relatively simple HTTP client library for Android
that implements HTTP/1.1 and HTTP/2.0. We might want to use OkHttp to bootstrap
into a more full-featured network_service implementation based on //net.
R=jamesr@chromium.org
Review URL: https://codereview.chromium.org/930673002
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
This CL introduces a new pattern for making services' public interfaces
flexible wrt location in the repo. A mojom target can now add import_dirs.
Each service target adds an import dir of the parent directory of
"<service>/public" and specifies its imports relative to that directory.
This CL covers the interfaces for geometry, gpu, input_events, and
native_viewport.
R=jamesr@chromium.org
Review URL: https://codereview.chromium.org/839903002
This removes the client relationship between the sky::InspectorFrontend
and sky::InspectorBackend mojo interfaces. Instead, the two are now
unrelated (in the mojom) and just happen to be often used together.
The inspector service provides the InspectorFrontend interface to
connecting applications and optimistically tries to connect to the
InspectorBackend interface of applications that connect, in case they
want to receive messages. The front and back end interfaces are both
broadcast APIs, so no attempt is made to keep track of which binding
is which. If they did need to be correlated this could be easily
accomplished by allocating a new object to keep a
mojo::Binding<sky::InspectorFrontend> and the corresponding
sky::InspectorBackendPtr.
R=abarth@chromium.org, eseidel@chromium.org
Review URL: https://codereview.chromium.org/835463003
-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 CL goes from this:
//mojo/services/public/interfaces/input_events
to this:
//mojo/services/input_events/public/interfaces
This CL also makes the Mojo-side changes necessary to roll this change into
Chromium.
TBR=beng
Review URL: https://codereview.chromium.org/788353002
Since we don't support using the component build to produce mojo apps,
we can simplify the build targets in a few ways:
*) every mojo_native_application must depend on the c system thunks,
so just make that part of the template instead of requiring the dep
*) there's no such thing as depending on gles2 headers from a component,
so delete the forwarding group.
Most targets that want to use the gles2 headers in a mojo context
want to depend on an implementation through the thunks, so
//mojo/public/c/gles2 does just that. A smaller number of targets (such
as the implementation of the thunks) want to just depend on the headers
but not an impl, so they can depend on //mojo/public/c/gles2:headers.
The //mojo/public/gles target isn't that useful since the only thing we
expose is a set of C entry points.
We can probably also simplify the c system targets, but that's trickier
due to more extensive use from the chromium side.
BUG=438701
R=viettrungluu@chromium.org
Review URL: https://codereview.chromium.org/780733002
The sky inspector service wants to implement a 1:N broadcast interface with whichever
frontends want to connect. This manages the pipes using a WeakBindingSet, which is a set of
bindings owned by the pipe combined with a list of weak pointers to those bindings allowing
sending messages to all connected clients without having to explicitly keep track of
which clients are connected at a particular point in time.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/711413005
This will make it possible to connect a c++
inspector backend in addition to the JS one.
We lose the feature of running multiple inspector
servers in this patch, but we weren't using that feature
and could easily add it back if we plan to use it.
This patch has a *ton* of boilerplate code due
to crbug.com/431911, hopefully that will be fixed
soon and we can delete all the Impl nonsense.
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/710043004
So, instead of:
import "bar.mojom";
module foo {
...
}
You'll do:
module foo;
import "bar.mojom";
...
(Note that the grammar in the parser doesn't capture the ordering
constraint. It's hard to do so while keeping the grammar LR(1) AFAICT.
So instead we enforce the ordering "manually".)
Also delete mojo/spy/PRESUBMIT.py since it's broken. We'll delete
mojo/spy separately.
R=jamesr@chromium.org
Review URL: https://codereview.chromium.org/687793004
