ResponsiveMenuLayout and demo app

[mikaelho]

ResponsiveMenuLayout has enough features that it could almost be a control, and the demo app would be just using it. But now still in one file, and nothing prevents taking the file as-is and just importing the ResponsiveMenuLayout from it.

Basic landscape layout, menu shown by default

Landscape layout, menu thinner

This is a parameter and a toggle in the demo app.

Landscape layout, menu hidden (completely by default)

Landscape layout, menu shown as icons only instead of hidden

This is a parameter of ResponsiveMenu, and a toggle in the demo app.

Basic portrait layout, menu hidden by default

Portrait layout, menu when shown is on top of the main content

Menu can be dismissed also by clicking outside the menu panel.

Portrait layout, menu can also be minimized to icons instead of being hidden

With the minimize_to_icons parameter, controlled by a toggle in the demo app. Minimizing behavior can also be controlled separately in each orientation by the landscape_minimize_to_icons and portrait_minimize_to_icons parameters.

Route support

Routes are supported by default in the web (selected page slug is part of the url, page can be opened directly with the right url).

Fine-tuning the NavigationRail

NavigationRail can be accessed to make changes directly, although there are some parameters that should be avoided.

[FeodorFitsner]

Fantastic work! Works like a charm on Windows and in browser with the upcoming build (built with dev channel of Flutter).

I'd love to use it for "Flet Gallery" app I'm about to start.

Some quick thoughts:

1. Routing support - it would be nice to add named routes to menu items, so selected page could be opened with a URL address, for example http://localhost:8550/menu-width would open the last page from your example.
2. As an array of pages is passed into the component would it be more sense to call it ResponsiveLayout?
3. As you mentioned this is a good candidate for a component. Where do we put such "highlevel" components (remember your Form component and I also have an idea for Wizard) built from Flet controls only? Separate "out-of-band" repo with Python package (flet-contrib) to iterate faster or main repo to have everything under flet namespace?

[mikaelho]

Good comments!

1. Added the routing support, see the last item in the description above.
2. Changed the name back to ResponsiveMenuLayout, as it controls the layout of the menu only, not the AppBar or really the content area.
3. The question of placement is hard. So far everything has been iterated so fast that it has not been a concern, and having something just be available without additional installations would be more valuable to me. One more factor to consider could be whether you want to make some component "officially part of Flet", and whether that implies that Flet in some other language than Python would be expected to have a component with the exact same functionality. For ResponsiveMenuLayout this could be feasible, but for something like the Form maybe not, due to the central role of data classes and pydantic there.

[mikaelho]

Added the leading control example to the demo, as discussed in Discord (see last image in the description).

[FeodorFitsner]

What if we put community examples/apps/components to python/community directory? Would you mind changing your PR? We could figure out later how to package/demo them.

[FeodorFitsner]

I meant putting your control inside a directory under python/community/responsive_menu_layout/main.py directory, so you can additionally put README.md in the root there with a description from this PR and images for readme could be put into python/community/responsive_menu_layout/images. Sorry about the hassle!

[FeodorFitsner]

Here is an example: https://github.com/flet-dev/examples/pull/14/files

[mikaelho]

Done -- except I left the images where they are on Github, because I am lazy.