Tweaked the layout in Scaffold a little: the Scaffold
accounts for the (Android) notification bar's height,
instead of the ToolBar. I think it would be best if
moving the app below the notification area were handled
at a lower level. Doing it in Scaffold seemed OK for the
moment, since one could put a ToolBar component anywhere
in an app.
Closes#208R=ianh@google.com
Review URL: https://codereview.chromium.org/1171173003.
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
Previously, the ink splashes would disappear immediately because the button
highlight would change the structure of the component hierarchy and we weren't
smart enough to retain the underlying RenderInkSplash. This CL is a point fix
for that issue by avoiding changing the structure of the component hierarchy. A
more complete fix would be to make Container smarter about how it syncs its
subcomponents.
R=eseidel@chromium.org, ianh@google.com
Review URL: https://codereview.chromium.org/1168323003.
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.
- constructors first
- have either a blank line at the top and bottom of each class, or no blank line in either place (it's still inconsistent about which we should do)
- hide clamp()
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/1172173002
This CL implements a basic version of screen rotation where we just relayout at
the new size. In the future, we'll want a fancy version where we transition
between the two layouts.
R=ianh@google.com
BUG=
Review URL: https://codereview.chromium.org/1177563002.
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.
The popup menu in the stocks app is supposed to size its width to the max
intrinsic width of the menu. This CL teaches it how to do that.
It's a shame that we need to ceilToDouble the output of RenderParagraph. If we
don't do that, we run into floating point layout trouble and the menu triggers
a line break. The correct fix is to do layout in fixed point.
R=ianh@google.com
Review URL: https://codereview.chromium.org/1168113005
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
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 CL is the first step towards getting PopupMenuItem working in fn2. We
introduce the ability to add a minWidth to a Container by creating a
RenderConstrainedBox class to apply the new constraints.
R=ianh@google.com
Review URL: https://codereview.chromium.org/1155683011
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
Changes:
- Remove all the old tracing logic since that was a lot of code for
just random printf debugging and nobody seems to use it
- Convert "defunct", a permanent state transition, to "mounted", a
state that can be entered and exitted arbitrarily
- Coallesce mount/unmount notifications so there's only one per frame
- Remove handleRemoved() since we don't use it
- Rename a local variable 'parent' to 'ancestor' to avoid shadowing
the field
- Replace uses of forEach() with for-in
Effects:
- Reusing a node provided to a constructor in a new place in a tree
(especially at a different depth) no longer fails (it used to fail
because the node would be marked defunct then remounted later, at
which point it would fail)
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/1169673002
