Ribbon

[vgromfeld]

Problem statement

Office and applications like Paint are using a "large" ribbon to display all their available commands. Those ribbons display all the available commands in groups. Those groups can automatically be collapsed if there is not enough space available to display them all based on a priority order.

The toolkit already provides a "small" ribbon through the TabbedCommandBar (See #500 and Porting TabbedCommandBar #243) but does not have any way to display the "large" ribbon.

Inspiration

Default

Narrow

Proposed solution

Add a new custom control to the toolkit.
It will use a custom layout to automatically collapse the ribbon's groups when there is not enough space available.
If all the groups cannot fit in the available width, the ribbon should display a left and/or right scroll buttons.

<Ribbon>
   <RibbonGroup Label="Selection" />
    <RibbonCollapsibleGroup Label="Edit" Style="{StaticResource RibbonLeftCollapsibleGroupStyle}" Priority="1">
        <!-- group content -->
    </RibbonCollapsibleGroup>
    <RibbonCollapsibleGroup Label="Shapes" Style="{StaticResource RibbonLeftCollapsibleGroupStyle}" Priority="2">
        <!-- group content -->
    </RibbonCollapsibleGroup>
</Ribbon>

Result

[michael-hawker]

For future reference, the WPF Ribbon docs are here.

One main difference here is that this is just the internals of a Ribbon tab, vs. the WPF control which handled the tabs itself.

However, now with both SelectorBar and the Toolkit's TabbedCommandBar, this solution could probably be combined more modularly with those vs. trying to handle everything together, eh? Though don't think we've tried to combine the later yet.

It should be something we think about for a Sample though in order to show the complete experience.

[Arlodotexe]

This was added in #546. See original [duplicate] discussion in #500.

[DL444]

I see the currently available API is simply RibbonGroup hosting arbitrary content. Should we in the future expose common group patterns at a higher abstraction level? For example, implementing adaptive command groups (see Layout - Page Setup in Microsoft Word) where commands are labeled and stacked optionally based on available width can be pretty complicated with today's primitive API (RequestedWidths), especially if internationalization requires width stops to be computed dynamically at run time.

I further imagine future complex scenarios that could benefit from a close integration between Ribbon, RibbonGroup, and their content. Having group encapsulations higher up the stack enables this integration.