Note that this will only work on stable as there are other transistive dependency breakages on beta channel and higher, eg this one in svg.

@rodydavis if you are interested, I can do further PR that gets things working on beta and earlier channels.

Fixes: #21

When using Storyboard() in a MaterialApp as a widget, like in example "complete_custom_lanes_builder.dart", it does not pick up the size set for the screens in storyboard, they get the size of the host app.

Tested in version: 0.1.2+1

Wild idea for a new feature, add an option to show/select different device frames around the presented screens.

Maybe code for the device frames could be borrowed from DevicePreview.(https://pub.dev/packages/device_preview)

If you wrap your Material app in a DevicePreview (https://pub.dev/packages/device_preview) and then in a StoryBoard, the screens presented in the story board do not get the correct media size.

This happens also if the DevicePreview enabled property is set to false and StoryBoard is set true.

It would be great if DevicePreview and StoryBoard could play nicely together, at least when they are not enabled at the same time.

When using StoryBoard() and the customLanes, the children in a CustomLane cannot have a label! Consider possibility to add a custom label text for each child.

When using StoryBoard.material() and wrapping a material app in it, each screen automatically get a nice label corresponding to the route by default. In customLanes there is no way to add a similar label even manually when defining the custom content of the lanes, by e.g. providing one for selected/all children in a CustomLane. Would be nice if this was possible.

When using StoryBoard() as a widget in a MaterialApp app with customLanes: [...] you often want children: [] to be empty as they are set via the customLanes: [...]. However, if children is empty, a lane is still drawn for it and it lane heading text "children" is written out, and actually on top of the first customLane.

Tested in version: 0.1.2+1

When using Storyboard() in a MaterialApp as a widget, like in example "complete_custom_lanes_builder.dart", it does not pick up the theme of the MaterialApp it is used in.

Tested in version: 0.1.2+1

This is just a suggestion for a new feature, but it would be useful to be able to group presented screens into different groups and lanes.

Basically a way to decided when to start a new row and also to show lane headers, maybe even headers within a lane, if you want to divide stuff on the same row in some cases too. Here is a quick mockup example:

The group and lane headers could have some default design, optionally a custom template widget could be provided for it.

Maybe this kind of layout could be done by providing some kind of heading and break "widgets" in desired order the customScreens lists. An option to hide initialRoute/home is then also needed so we do not get it shown first on a row of its own all the time. Naturally there are many ways of doing this, this was just an idea to build upon some already existing features that might be easy to extend to encompass the feature as well.

When you use the reset button to reset the view port settings, it resets to the "hard coded" defaults. It would be nice if it would reset to value(s) that were provided in the widget constructor first, for scaling and offset, and only if such values where not provided in the constructor, would it reset to hard coded defaults.

In light theme mode the elevation of the screens works well on the presentation canvas:

However, in dark mode the screens may become a bit too "embedded" with the canvas background:

Especially in a "true black" mode:

SOLUTION PROPOSAL 1:

Add optional separate border styles for the light/dark theme that can be provided/turned on, if so desired.

SOLUTION PROPOSAL 2:

Provide color properties where user can specify background colors for the light and and dark theme modes, for the background canvas that presents the screens. This would allow users to specify a background color for the presentation canvas in light and/or dark modes, that are different from the canvas background color used in the theme for the application itself. It then becomes possible to use light/dark background colors that are slightly different from light/dark colors used in the presented application. It of course also allows for totally custom silly background colors of course, which could also be useful in some cases.

Options 1 and 2 are of course not mutually exclusive, they could both be useful alternatives individually or together.

The customAppBar property:

/// Override the default app bar of the storyboard
final AppBar customAppBar;

Should probably be a PreferredSizeWidget like in Scaffold:

/// An app bar to display at the top of the scaffold.
final PreferredSizeWidget customAppBar;

So that you can provide a totally custom app bar, instead of just an AppBar(). You can still give it an AppBar() when using PreferredSizeWidget, but also a totally custom version that implements PreferredSizeWidget itself.

Sometimes you need to compare two mobile phones (model comparison, interactive comparison, page comparison) to check the effect of the widget, so can you make the page moveable, mobile viewing, convenient for discussion and intuitiveness.

___Personally think this storyboard is very powerful.Come on and improve

Rendering consumes resources, is there a way to manage resources? This way, the use of page interaction is very stuck and the experience is very poor! ! ! !

Let's make one great flutter dev-tool instead of many!

Hi! first of all, I want to say that I really appreciate the works in this open-source project, I installed it and all other similar packages, and I think it can be great if the work is unified into a single tool which can become popular and a standard for flutter development.

I will list all the projects that I found here:

• https://github.com/erickzanardo/dashbook
• https://github.com/ookami-kb/storybook_flutter
• https://github.com/ilikerobots/storyboard

These 3 have the same goal, a storybookjs inspired package to showcase flutter widgets.

But there are also these projects that if combined with a flutter storybook, can really become a standard tool for every flutter developer:

• https://github.com/jamesblasco/flutter_preview (preview any widget in vs code)
• https://github.com/aloisdeniel/flutter_device_preview (emulate any device size)
• https://github.com/rodydavis/storyboard (see all routes at once)

I am pasting this same issue to all of these projects, if you don't want it, feel free to close it :D

Tell me what you think!

See https://github.com/flutter/flutter/pull/61366

I was not sure if you prefer to add the old Overflow enum to custom_stack.dart or to move everything to using clipBehaviour like in that change so I did not open a PR.

This results in build errors like this:

[+2140 ms] [+2138 ms] ../../../.pub-cache/hosted/pub.dartlang.org/flutter_storyboard-0.1.6/lib/src/custom_stack.dart:293:9: Error: Type 'Overflow' not found.
[        ] [   +1 ms]   final Overflow overflow;
[        ] [        ]         ^^^^^^^^
[        ] [        ] ../../../.pub-cache/hosted/pub.dartlang.org/flutter_storyboard-0.1.6/lib/src/custom_stack.dart:344:5: Error: Type 'Overflow' not found.
[        ] [        ]     Overflow overflow = Overflow.clip,
[        ] [        ]     ^^^^^^^^

To reduce the need to frequently be forced to build an entirely new custom app bar, when using the Storyboard() within a material app as a widget, also consider exposing some of properties for the built in app bar, like:

Widget title double elevation Color backgroundColor

To allow for complete custom themeing of the built in appbar also consider exposing:

IconThemeData iconTheme IconThemeData actionsIconTheme TextTheme textTheme Brightness brightness

Alternatively, for using a custom app bar, consider showing an example that implements a custom app bar, with re-implementation of the controls on the built in one. I had a quick look at this as an alternative to get it themed the way I wanted that way. While I could get it themed the way I wanted it to look, by making a completely custom one, I could not figure out how to re-implement the controls of the built-in appbar, so that they would actually work in the custom appbar as well. Is this supported? How?

When an app screen in a story board show a dialog, it shows up in the story boards "host" canvas and is not constrained to the "screen" it originated from. This might or might not be a desirable feature, mostly it is probably not desired if you are presenting a mobile app UI: