[Feature] Add TabbedCommandBar (ribbon) control

[yoshiask]

Fixes #3259

PR Type

What kind of change does this PR introduce?

Feature

Sample app changes

What is the current behavior?

There is no ribbon or ribbon-like control for UWP. The current solution is to put CommandBars inside of a Pivot.

What is the new behavior?

Adds a TabbedCommandBar, which internally is almost identical to the current solutions, but provides a much friendlier developer experience.

PR Checklist

Please check if your PR fulfills the following requirements:

• Tested code with current supported SDKs
• Pull Request has been submitted to the documentation repository instructions. Link: Create TabbedCommandBar.md MicrosoftDocs/WindowsCommunityToolkitDocs#405
• Sample in sample app has been added / updated (for bug fixes / features)
  • Icon has been created (if new sample) following the Thumbnail Style Guide and templates
• Tests for the changes have been added (for bug fixes / features) (if applicable)
• Header has been added to all new source files (run build/UpdateHeaders.bat)
• Contains NO breaking changes

Other information

I forgot to do my work on a feature branch, so this PR is basically a duplicate of #3551, with a little bit of cleanup.

[ghost]

Thanks yoshiask for opening a Pull Request! The reviewers will test the PR and highlight if there is any conflict or changes required. If the PR is approved we will proceed to merge the pull request 🙌

[michael-hawker]

Quick comments

[yoshiask]

I'm using the package generated by the pipeline and I can see a few bugs that I'm not sure how to address.

• The animation when switching tabs doesn't work in the Toolkit Sample App, but they do in my personal app.
• The styles that I defined for the controls (e.g. DefaultTabbedCommandBarItemStyle, AcrylicTabbedCommandBar) aren't available in projects that just reference the Toolkit package. Attempting to use one of those styles in an app results in a "resource not found" exception.

[yoshiask]

@michael-hawker Just pinging you since it's been a while, did you see my last comment?
#3556 (comment)

[michael-hawker]

So sorry @yoshiask, I missed your comment after .NET Conf.

For your issues with the Sample App and stand-alone. The Sample App uses WinUI 2, so it's including their style overrides compared to when just run with the Toolkit and the system styles. This is something we have to address in the future better (opened #3598 to track this). It might be that we have to check for what this conflict/difference may be?

Do those two styles use specific resources found in the WinUI 2 styles?

[yoshiask]

No, all styles use system resources. Also just want to reiterate that the issue isn't coming from inside the custom styles. The issue is that the styles I wrote don't seem to be accessible outside of the Toolkit resource dictionary

[yoshiask]

For example, the DefaultTabbedCommandBarItemStyle is the style that couldn't be found.

[michael-hawker]

@yoshiask I see, you're saying for accessing in the code a developer would be using in their app, eh?

Does it work for any other style for any other controls in the Toolkit? This may be a general issue not specific to your component. This also may be related to how we don't require inclusion of resources in the app like WinUI does as well.

I know in more explicit cases where we wanted alternate styles for folks to leverage, we just had them as loose XAML files which we then had folks include explicitly like with the alternate styles for InAppNotification:

https://github.com/windows-toolkit/WindowsCommunityToolkit/blob/2a4938d9f11faf6ff3630294470194598ae4da3b/Microsoft.Toolkit.Uwp.SampleApp/SamplePages/InAppNotification/InAppNotificationXaml.bind#L14-L17

[yoshiask]

Okay, I'm officially calling it here. I'm not adding any new stuff (as much as I wanted to make the ribbon collapsible). I believe I've addressed all the feedback, but feel free to unresolve a thread if there's more work to be done there.

[Kyaa-dost]

@yoshiask Thanks for all the work ❤️

Will have to look more into this as we are still able to repro this error highlighted by the community.

[michael-hawker]

Thanks @Kyaa-dost, yeah I'm not overly worried about that bug as it's a bit tricky to actually reproduce unless you follow an explicit set of steps. I think it's something we can address later or even in 7.1 if we find out it's a bigger issue.

I plan to give this another whirl and double-check the contextual tab updates tonight. So excited to get this in for the release! 🎉

Great work @yoshiask!

[michael-hawker]

I noticed there's a few todos? Are those future todos, things that should be removed, or issues that should be addressed?

Maybe best to create a new issue to track any open/remaining things you want to track long-term and then just put a #1234 reference to the issue number in the comments with more details?

Otherwise, I think we just have to update the sample with the new binding to make it work by default... (see comments)

[ghost]

This PR has been marked as "needs attention 👋" and awaiting a response from the team.

[michael-hawker]

Alright, think we're good. @Kyaa-dost want to take it for a final spin with the fix for the Sample in the morning and we can get it merged?

@RosarioPulella after that mind updating the dev/split-controls branch to move this to Core?

[ghost]

Hello @michael-hawker!

Because this pull request has the auto merge :zap: label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (@msftbot) and give me an instruction to get started! Learn more here.

[yoshiask]

@michael-hawker I merged master back in and the bot removed the auto merge label