Make it possible for named routes to be generated on the fly.
To demonstrate this, you can now long-press a stock to open it.
Next steps:
- transitions between (named) states that follow full material logic,
e.g. in the case of the stock row to stock page transition, expanding
the row into a raised sheet of material and expanding it to fit the
screen, leaving the toolbar in place but cross-fading the old
contents to the new contents.
- more information in the stock view.
While I was here I also made Material have an opinion about default text
style, so if you forget to set one, it just uses body1.
Also, fixed bugs introduced recently that made RouteState and MenuRoute
not work properly.
Introduce a Draggable class that wraps all the logic of dragging
something and dropping it on a DragTarget.
Update examples/widgets/drag_and_drop.dart accordingly.
Make the performance/transition part of routes optional.
Initial snap offset support for ScrollableWidgetList (and ScrollableList<T>) and ScrollableMixedWidgetList. If a ```toSnapOffset(scrollOffset)``` function is provided, fling Scrolls will coast to the returned value. If ```alignmentOffset``` is specified then fling scrolls conclude when toSnapOffset's value lines up with the Scrollable widget's origin + alignmentOffset. For example if the Scrollable widget's height was 200.0, and alignmentOffset:100.0 was specified, then fling scrolls would end with the value returned by toSnapOffset() lined up with the center of the Scrollable.
This approach to Scrollable snapping assumes that the layout of whatever the Scrollable contains is known at the outset. This is often true however a ScrollableMixedWidgetList may not know its items' sizes until they've been reached by scrolling.
This is a first cut at snapping support. Among the things that remain to be done:
- Scrolling limits trump snapping. Snapping should probably trump scrolling limits.
- Drag scrolls aren't snapped. This may be desirable so perhaps the feature should be controlled with a flag.
- Specifying alignmentOffset as a percentage would probably be more convenient.
- It would be nice if one could wrap items in a SnapOffset value like: ```new SnapOffset(0.5, child: myItem)``` to snap to the center of the item.
Updated the CardCollection example: snapping and fixed size items can be turned on/off with Drawer checkboxes.
Tapping on the menu item didn't animate the checkbox because the menu
takes 300ms to animate entirely away while the checkbox takes 200ms to
animate checked, and since the item with the checkbox was at the bottom,
we were only seeing about 60ms of the entire checkbox animation, which
isn't enough to notice it. So I moved it to the top of the menu.
Tapping on the checkbox didn't animate because nothing caused the menu
to rebuild when the callback was invoked. To trigger a rebuild, I now
call navigator.setState() explicitly, after changing out local state.
To make tapping the checkbox remove the menu, I also explicitly call
navigator.pop() in the code that handles the check. (I still explicitly
change the checkbox to show that that's possible. In principle one could
just treat the checkbox as an inert widget that happens to trigger pop,
and do all the checking/unchecking in the switch statement.)
I also made some minor style tweaks to files I was looking at while
dealing with this issue.
This changes how SnackBar works so you can use it anywhere, not just on
the bottom edge of the screen (it used to rely on overflowing its bounds
and having negative offsets... I'm not really sure how hit testing
worked on it before!).
To do this I introduced a new RenderBox, RenderOverflowBox, that lets
you set your child's size independent of your own. I needed this so that
the snack bar could use a SquashTransition to change its size, while not
affecting the layout of its child. This is exposed as OverflowBox in
fn3. I'm not sure if it's the best API. It doesn't let you position the
child (which is an issue if the size you give is smaller), it doesn't
let you give a loose constraint (which maybe you might want?). But it
handles this use case, so for now it's probably ok.
Making the FAB get repositioned out of the way of the Snack Bar is now
done in the Scaffold, which is in charge of positioning both of those
and is the place that knows that both exist.
This updates to mojo 4e4d51ce28a and mojo sdk 711a0bcfb141b4 and updates the sky
package's pubspec.yaml dependency to '>=0.1.0 <0.2.0' to be compatible with
the current mojo package. This includes an update to the Mojo Dart generator to
produce real classes for enums and the corresponding updates for users of the
KeyboardType enum in Sky as well as one scoped_ptr->std::unique_ptr in shell
corresponding to a change in the Mojo EDK.
When a new version of the sky and sky_services package are pushed this will fix
domokit/mojo#440.
Instead of having to manage the popup menu from your app's build
function, you now just call showPopupMenu() with the menu's position and
it takes care of everything for you.
This solves the problem that the popup menu was trying to mutate the
state of the navigator from within its own initState() function.
Also, remove the "route" argument to RouteBase.build() since it equals
"this" by definition...
Also, remove ModalOverlay, and instead put that logic in the navigator.
Importing the public libraries caused a name conflict with dart:sky because we
assume people will import dart:sky into a namespace, so I've also changed
skysprites to import dart:sky into a namespace.
Also, introduce Colors and Typography to hold the material colors and the
typography declarations. Previously we expected clients of these libraries to
import them into a namespace, but that doesn't play nice with re-exporting them
from material.dart.
