R=abarth@chromium.org

Review URL: https://codereview.chromium.org/1182563002.

R=abarth@chromium.org

Review URL: https://codereview.chromium.org/1175403002.

This moves input.dart to editing2/, since that way we can define the layering as strictly unidirectional.
It also reorders a bunch of imports to fit the style guide.
I removed the old remnants of the widgets example, and put the fn2 examples into the examples/widgets/ directory, to parallel the framework directory names.

R=abarth@chromium.org

Review URL: https://codereview.chromium.org/1177243002.

R=abarth@chromium.org

Review URL: https://codereview.chromium.org/1179913002.

R=abarth@chromium.org

Review URL: https://codereview.chromium.org/1180873003.

This CL wires up the opacity of the popup menu items and teaches the popup menu
how to draw its background at the right size.

R=ianh@google.com

Review URL: https://codereview.chromium.org/1175353002.

Sprite nodes use Point instead of Vector2

Updates sprite test app

Refactors accounting for pivot points in sprites

Adds abstract NodeWithSize class in Sprites.

Refactors SpriteNode to Sprite

Refactors TransformNode to Node (may need to find another name as it conflicts with Sky's Node).

Sprite system now uses and caches transformation matrices.

R=abarth@chromium.org

Review URL: https://codereview.chromium.org/1180703002.

R=abarth@chromium.org

Review URL: https://codereview.chromium.org/1178783002.

Separate out the raw (directly manipulating sky.view) examples from the rendering (using RenderObject et al) examples.

R=abarth@chromium.org

Review URL: https://codereview.chromium.org/1173233002

R=eseidel@chromium.org, eseidel

Review URL: https://codereview.chromium.org/1180623003

This lays the groundwork for using fn widgets in static environments.

R=abarth@chromium.org

Review URL: https://codereview.chromium.org/1178703002

These are now called Block, Stack, and Flex, respectively. Less verbose.

R=jackson@google.com, ianh@google.com

Review URL: https://codereview.chromium.org/1181533002.

R=abarth@chromium.org

Review URL: https://codereview.chromium.org/1181453003

R=ianh@google.com

Review URL: https://codereview.chromium.org/1174153002.

Previously, they always started at the center of the RenderInkWell. Now we
remember the local coordinates we computed during the hit test and provide that
information when handling the event.

R=ianh@google.com

Review URL: https://codereview.chromium.org/1180553002.

This also removes one bit of magic to make it more obvious what on is
going on during a sync, which should hopefully help.

Components have to decide if they support being stateful or not. If
they do, then they must implement syncFields() and have mutable
fields; if they don't, then they must have final fields. This isn't
particularly enforced, though.

This also renames _willSync() to _retainStatefulNodeIfPossible(), for
clarity, and fixes some minor style issues and one typo that was
breaking the drawer.

R=abarth@chromium.org

Review URL: https://codereview.chromium.org/1174023003

Renders interactive_flex and stocks demos fine. Could use more testing,
so I'm going to work on that after I land this.

R=abarth@chromium.org, abarth

Review URL: https://codereview.chromium.org/1173493003

R=abarth@chromium.org

Review URL: https://codereview.chromium.org/1175763002.

R=eseidel@chromium.org

Review URL: https://codereview.chromium.org/1177563004.

This CL replaces the (non-working) components2 InkWell with some code based on
the ink_well example. There are at least two issues with the implementation:

1) The ink splash always starts at the center of the well because we don't have
   a facility for converting from global to local coordinates, which means we
   can't tell where the tap occurred in the local coordinates we need to use
   for painting.

2) When used inside a MenuItem, the in splash disappears shortly after
   starting, presumably because the button starts highlighting, which causes a
   component rebuild and somehow we lose the RenderInkWell instance.

I plan to address these issues in subsequent CLs.

R=ianh@google.com

Review URL: https://codereview.chromium.org/1172033003.

StockRows are now a relatively simple application of flex layout.

The up/down arrows are now rendered within a circle, like
the original version. The arrows are a little bigger,
because.

R=ianh@google.com

Review URL: https://codereview.chromium.org/1165223005.

This would cause them to forget what the most recent child they'd been given was, with disastrous effects later.

R=abarth@chromium.org

Review URL: https://codereview.chromium.org/1173683003

R=eseidel@chromium.org

Review URL: https://codereview.chromium.org/1166223004.

We already know how to talk to the network_service from Dart
via fetch.dart.  Might as well use that for Image loading
as well insetad of having ImageLoader do it.

As part of this I've renamed *ImageLoader to *ImageDecoder
and moved all the image loading logic into Dart.  This required
me to teach the idl system about mojo handles so that I could
pass the resulting MojoHandle from fetch.dart up through to
ImageDecoder.

R=abarth@chromium.org, jackson@google.com, hansmuller@google.com

Review URL: https://codereview.chromium.org/1173703002.

more ColorFilter types.

R=eseidel@chromium.org

Review URL: https://codereview.chromium.org/1163373007.

The FlexExpandingChild flex parameter is now a keyword as
well, which adds a small readability benefit.

R=ianh@google.com

Review URL: https://codereview.chromium.org/1172503004.

R=eseidel@chromium.org

Review URL: https://codereview.chromium.org/1172723002.

R=abarth@chromium.org

Review URL: https://codereview.chromium.org/1169863002.

This CL pulled an implementation of position: absolute in RenderStackContainer.

R=eseidel@chromium.org, ianh@google.com

Review URL: https://codereview.chromium.org/1166363002.

This version doesn't add any visual punch.

R=abarth@chromium.org

Review URL: https://codereview.chromium.org/1172513002.

This CL splits getIntrinsicDimensions into getMinIntrinsicWidth,
getMaxIntrinsicWidth, getMinIntrinsicHeight, and getMaxIntrinsicHeight so that
we can properly shrink-wrap the stocks app menu. This CL just contains the
refactoring. The use in stocks app will come in a later CL.

R=ianh@google.com

Review URL: https://codereview.chromium.org/1167293003

Radians are the one true angle unit.

R=abarth@chromium.org

Review URL: https://codereview.chromium.org/1164393002

Also change SizedBox.

This makes the code that uses Container() and SizedBox() much more readable.

The underlying RenderSizedBox is not affected by this change.

R=abarth@chromium.org, eseidel@chromium.org

Review URL: https://codereview.chromium.org/1166203002

R=abarth@chromium.org, abarth

Review URL: https://codereview.chromium.org/1164363002

R=eseidel@chromium.org, ianh@google.com

Review URL: https://codereview.chromium.org/1166183002

The popup menu is displayed in the wrong location with the wrong width, but it
does draw. I've also removed the checkbox because the flex container was
causing me trouble.  I'll add it back in a later CL.

R=ianh@google.com

Review URL: https://codereview.chromium.org/1166153002

This includes making SizedBox default to infinite size, and making
Container default to containing one infinite-sized SizedBox. That way,
you can use an empty Container as a spacer in a flex box.

The rendering doesn't quite work, because of a bug in flex whereby it
doesn't shrink-wrap its contents in the cross-direction, it fills the
parent. Collin is on that.

R=jackson@google.com

Review URL: https://codereview.chromium.org/1163633003

I had to complicate the IDL bindings generation to allow passing an array of
colors. Without these changes, we'd try to convert the dart object to
Vector<SkColor>, which C++ thinks is Vector<unsigned>, and we'd use the wrong
converter. So I added some template grease to force it to use a
Vector<CanvasColor> converter.

R=eseidel@chromium.org

Review URL: https://codereview.chromium.org/1152963009

And deploy it in a few places.

R=ianh@google.com

Review URL: https://codereview.chromium.org/1164303002

R=abarth@chromium.org, abarth

Review URL: https://codereview.chromium.org/1161813005