Spec: New features for CommandBar/CommandBarFlyout

[mdtauk]

It is very good to see these controls getting a fresh look by the teams. The Alarms & Clock app in the insider ring, has replaced it's Command Bars, so I was thinking maybe that was an indication of a deprecation or not recommending using these controls.

So the Secondary Items flyout being brought into line with other flyouts and menus with nesting, toggles, and radio items.

Support for other buttons like SplitButton and DropDownButtons - which would be useful for things like font colour options etc.

There is support for "other" controls using the wrapping panel, but as is mentioned in the spec, these do not receive styling. I would like to ask if support for ComboBoxes and TextBoxes has been considered? One scenario I am thinking about, is setting a Font or FontSize with a CommandBar or CommandBarFlyout in something like a RichText control.

On the surface, CommandBar and CommandBarFlyout is the same control, except one is docked and always visible, and the other is contextual and is shown when needed. So it is good both controls are being considered together. ☺

[yoshiask]

Built-in styles to support adding SplitButton to CommandBar and CommandBarFlyout

Is this the best option? I feel like it would be more clear to developers to have a AppBarSplitButton. Presumably this style would be applied automatically by an AppBarElementContainer, but that implies that the SplitButton isn't officially supported in the context of a CommandBar. Using only a style would also mean that "SplitButton" would not be recognized by Intellisense as valid content in a CommandBar, and therefore not recommend it as an autocompletion. Devs might not realize that they can use a SplitButton there.

[anawishnoff]

Thanks for the feedback, @mdtauk and @yoshiask! You both bring up good points.

@mdtauk - About considering other controls to be integrated into an AppBarButton: this is definitely something I've been thinking about, in terms of what controls would be useful inside of a CommandBar/Flyout. TextBox is an interesting one, especially as you bring up that using CB/CBF in text editors is quite common. See my response below as well.

@yoshiask - Your idea of creating new type of AppBarSplitButton is a great idea, and I also appreciate your point about Intellisense - that's an important thing to think about in terms of discoverability as well.

For these changes I purposefully tried to keep it at a small scope, as the team is crunched for resources right now. I thought of this as sort of as a starting point to making CommandBar more customizable. I think that adding new types for AppBarSplitButton (and maybe even AppBarDropdownButton, AppBarTextBox or others) would be a great future second step here. I'd encourage either of you to open up an issue requesting this feature and I can keep an eye on it.

[mdtauk]

I think, if you were to add those AppBar<ControlName> as allowed controls for use in CommandBars - these primitive controls should use the existing control, but overriding the Control's Template to fit aesthetically and behaviourlly with the CommandBar and CommandBarFlyout.

I think the Win32 equivalent is the ToolStrip and Ribbon controls - which host common controls, but renders them differently.

This way there is no duplication of control code. For controls like Buttons which have a label which hides with a CommandBar, and is not shown on the CommandBarFlyout - there may need to be some logic for handling labels if needed.

[yoshiask]

For the record, the TabbedCommandBar I've been working on for the Windows Community Toolkit is including style overrides for common controls that don't have an AppBar 'wrapper'. I'd be more than happy to contribute them directly to WinUI.

[anawishnoff]

@mdtauk, I think you make an excellent point about duplicating control code, and editing the controls themselves to fit in with CommandBar. There's also the fact that we don't recommend using AppBar for WinUI apps - CommandBar is the standard, so having new controls that start with AppBar* may be a bit misleading.

I think a more durable plan (revising my own comment above) would be to either edit the CommandBar/CommandBarFlyout controls so that they are able to "accept" controls other that AppBar*, or edit the SplitButton and other controls so that they can easily be integrated into a CommandBar/CommandBarFlyout without a wrapper class.

@yoshiask, I think generally using the WCT to pursue next steps like these is a great approach. Would you mind linking to the work you've been doing?

[mdtauk]

@mdtauk, I think you make an excellent point about duplicating control code, and editing the controls themselves to fit in with CommandBar. There's also the fact that we don't recommend using AppBar for WinUI apps - CommandBar is the standard, so having new controls that start with AppBar* may be a bit misleading.

I tend to use AppBar and CommandBar interchangably, so thank you for pointing this out. CommandBar is the Control, AppBar is the older control/primitive used.

Duplicated controls is a problem that grows in time, but allowing one control to override a template for a child or contained control is good enough most of the time to adapt existing controls. One such control could be a Controls.Primitive "Separator" control, which could be used and restyled for CommandBars, ListViews, NavigationViews etc.

I think a more durable plan (revising my own comment above) would be to either edit the CommandBar/CommandBarFlyout controls so that they are able to "accept" controls other that AppBar*, or edit the SplitButton and other controls so that they can easily be integrated into a CommandBar/CommandBarFlyout without a wrapper class.

If an existing control needs new properties to work well within a CommandBar - then you could extend the control, and provide a new ControlTemplate. Or add those properties to the base control (most of these cases will require WinUI 3.0 source code)

But if a CommandBar accepts other controls, it would still be desirable to adjust the visuals of the controls when used in the CommandBar.

The Windows 7 Ribbon control has sub controls, which look different to standard controls https://docs.microsoft.com/en-us/windows/win32/windowsribbon/windowsribbon-controls-entry

Including dropdown/combobox controls

[MikeHillberg]

Move this over to PR #121.