Add an AppBarDropDownButton

[lhak]

Proposal: Add an AppBarDropDownButton

Summary

There is currently a DropDownButton control, but no corresponding control to place into a commandbar.

Rationale

Adding dropdown menus in a commandbar currently requires adding a (maybe retemplated) AppBarButton with an associated menuflyout. Unfortunately, even if the placement property of the Flyout is set, there is still a gap between both elements:

In comparison, the commandbar menu for secondary controls does not show this issue:

While it is possible to add workarounds to the application (e.g. manipulate the margins of the flyout), this should be handled automatically. As can be seen, the style of both flyout is also different (at least on the current windows insider build)

Functional Requirements

Usage Examples

Detailed Feature Design

Open Questions

[mdtauk]

A future UWP ribbon may have need for this, as well as versions of other controls when placed into a ribbon/tool bar. Thinner strokes on text and combobox fields for instance.

[adambarlow]

@lhak, @mdtauk
At one point during the creation of the new button controls in RS5, e.g DropDownButton and ToggleButton, etc. we had to decide if we were going to continue down the road of class explosion with AppBar* everything. We knew we were going to need to have then later versions of all of these that also went into Ribbons as Martin mentioned above. At which point we would need Ribbon* controls, etc.

I think perhaps a more elegant solution to all of this is some sort of implied styling capability which I have hinted at in the Ribbon feature proposal. This solution allow base controls to perhaps implement interfaces which allow them to self-style when they are dropped in various containers, freeing us from class explosion. However, this implied styling feature needs to be detailed out and designed as well. Which will be part of nailing the design for the Ribbon architecture.

Note: we decided instead to create an AppBarElementContainer in the short term to allow for these controls instead of creating various AppBar* variants.

[mdtauk]

The idea of localised styles which override controls when they are placed into a panel, is very interesting. It would have to apply to the control without giving it a Style value.

An initial thought of adding a ResourceDictionary to the Panel.Resources of the Ribbon Control maybe.

Or perhaps taking the generic.xaml dictionary included in Microsoft.UI.Xaml package, adding in Styles and Templates for RibbonButton, RibbonComboBox, Ribbon SplitButton - and somehow translating the control's default template for these ones when placed in the Ribbon Control.
But that would probably need some platform changes to how XAML handles it's themeing/templates and styles.

[lhak]

Ok, for mow I will keep using a retemplated version of the MenuFlyoutPresenter to compensate for this gap. Is there any way to disable the shadow to keep a consistent look with the commandbar overflow menu?

[YuliKl]

@jesbis and @chigy, can you comment on how to disable shadow in MenuFlyout?

@lhak - thank you for this feature proposal. Sounds like you have a reasonable workaround for your scenario. Between your current approach and the option to use AppBarElementContainer to place a DropDownButton into a CommandBar, I don't think it makes sense for us to add a new AppBarDropDownButton class.

[msft-github-bot]

We appreciate the feedback, however this doesn’t currently align to the project’s goals and roadmap and so will be automatically closed. Thank you for your contributions to WinUI!

[mdtauk]

Just a little thought about applying default styles to controls based on their container/parent...

TargetType="AppBar/DropDownButton"

Treating the TargetType and Style values more like a path to help make things more conditional?

[kurema]

So there's also no chance for AppBarRepeatButton...
I want RepeatButton in CommandBar, but OK. There's workaround.