Implement command bars and dynamic overflow layout #232
Conversation
* Need to be able to control whether TreeView uses the primary ScrollController or uses a custom scroll controller * If TreeView has shrinkWrap set, then do not use the primary scroll controller These changes are needed so that if a parent ListView contains a TreeView and the ListView has a custom scroll controller, then we can avoid using the primary scroll controller and avoid exceptions like "The provided ScrollController is currently attached to more than one ScrollPosition".
A variant of SingleChildScrollView that provides horizontal scrolling via the mouse wheel. This is needed due to changes in Flutter 2.5, where the mouse can no longer be used to drag and scroll horizontally on web/desktop platforms. https://docs.flutter.dev/release/breaking-changes/default-scroll-behavior-drag
A `CommandBar` control provides quick access to common tasks. This could be application-level or page-level commands. See https://docs.microsoft.com/en-us/windows/apps/design/controls/command-bar The current implementation does not implement the open/closed state, nor does it implement the secondary commands "more" button with dynamic overflow of items into the secondary commands menu.
|
I am very interested in this component. I also have an implementation, different but perhaps it can contribute things.For example, in my version I distinguish two groups of buttons, one of which is automatically hidden when there is no horizontal space.If you want we can mark it as a draft and spend a few days reviewing it together. |
Also changed cross-axis alignment for items within a CommandBar to be center-aligned. Needed so that items will be properly vertically aligned (including separators) if items are of different heights.
|
@bdlukaa - addressed comments and added @henry2man - all help would be welcome! this could be added as an enhancement to this (whether in this PR or a follow-on) by:
Do you have any code to reference that demonstrates how to figure out which of the items can fit vs which ones should be hidden into a secondary menu? |
I have a very simple code: a width parameter in px that is evaluated during the execution of the "build" method. A LayoutBuilder could be used: "if width is less than x then hide buttons and show menú button" This approach is quite simple but can be extended/adapted if buttons have a constant width |
* A CommandBar now takes a list of primary and secondary command bar items. The secondary command bar items do not yet appear anywhere. * The primary command bar items are intended to be displayed on the horizontal area of the command bar. * Conceptually similar to PaneItem, CommandBarItem is now given a "display mode" when building the widget. The display mode indicates if the item is being rendered on the primary (horizontal) area (and if it should display in "compact" mode) or the secondary (flyout menu when "more" button is pushed) area. * A CommandBar can be given a `compcatBreakpointWidth` that indicates that if the widget is rendered with a smaller width, then it should render all of the items on the primary area in "compact" mode. * Foundation is laid for supporting the secondary area and an overflow behavior mode of "dynamic", but is not yet implemented.
Similar to Wrap, but only displays widgets on a single run, and then hides widgets that would have overflown. If widgets are hidden, then it will display the specified "overflow widget". This is useful to implement the dynamic overflow mode of command bars. It could also be useful if a vertical nav bar wanted to implement a "more" button instead of vertical scrolling.
Also add mainAxisAlignment and crossAxisAlignment fields
* Illustrates right-alignment and dynamic overflow modes. * Moves command bar examples into a new navbar pane to avoid clutter.
|
@henry2man @bdlukaa -- After some research, I figured out how to implement a fully featured command bar, including:
This was implemented with a new In the example app, with additional examples for command bars added, it was getting cluttered on the others pane, so I added another navbar pane. I could move it back to others if you want, it was just a little awkward testing the wrapping behavior with a lot of stuff above it. All the new functionality is best illustrated with a video: |
klondikedragon
changed the title
|
SO COOL! This will open possibilities for the same thing on NavigationView! I'll review ASAP |
|
@bdlukaa - I've addressed comments and cleaned up the concept of |
|
Incredible ! |
|
@klondikedragon Hello! I'm having issues with #277. It uses |
This is a first implementation of command bars as described in #231.
A
CommandBarcontrol provides quick access to common tasks. This could be application-level or page-level commands.Refer to the spec.
The current implementation does not implement the open/closed state, nor does it implement the secondary commands "more" button with dynamic overflow of items into the secondary commands menu.
Also, during implementation of the example, I realized that I needed control over the
primaryandcontrollerproperties of theListViewinside of theTreeView, so this also adds these properties toTreeView.Here is what the examples look like with the various overflow behaviors:
And here is what it looks like alongside the large
TreeView:Pre-launch Checklist
CHANGELOG.mdwith my changes