Remove the Menu Control

[michael-hawker]

Issue: #2989

PR Type

What kind of change does this PR introduce?
-Feature

What is the new behavior?

Menu control removed as WinUI has MenuBar now.

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:
• 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

[skendrot]

This makes me pretty sad because I don't think the current Menu control handles all of the use cases this one does :(

[michael-hawker]

@skendrot yeah, I'm not sure if I fully understand the gap here, do you recall any explicit examples? I just know that we deprecated this a release or two ago and had originally talked with the WinUI team about pulling it out here.

@jevansaks @stmoy who should we sync with on your side about if we want to double-check a quick gap analysis before we pull this out. We could hold this back for a 6.1 like the TabView or something if it makes sense?

[jevansaks]

who should we sync with on your side about if we want to double-check a quick gap analysis before we pull this out. We could hold this back for a 6.1 like the TabView or something if it makes sense?

We're the right people to talk to! Let me know if you want to set up a Teams call to discuss.

[Kyaa-dost]

I agree with @skendrot regarding the functionality of the newer version vs this one. Let's chat next week with @jevansaks to understand the usage.

Thanks Kyaa. I've added the DO NOT MERGE tag for now, I'm just going to dismiss your review too to gray out the button and make it harder to accidentally merge.

[jevansaks]

@Kyaa-dost @michael-hawker @skendrot can someone give me a hint as to what the missing functionality is in the platform control? Thanks!

[skendrot]

The biggest problem is the inheritance of the controls of WinUI. Controls that should be an ItemsControl for easily binding to collections are not.

[skendrot]

For example, if I want to have a dynamic list of menu items based on a particular backing model I cannot do the following:

<MenuBar ItemsSource="{Binding MenuItems}"/>

The same can be said for the TabView, the TreeView and others

[jevansaks]

TabView and TreeView both have ItemsSource but MenuBar does not. Looks like an oversight on MenuBar, can you file an issue in https://github.com/microsoft/microsoft-ui-xaml?

MenuFlyout also lacks ItemsSource -- we can address that post WinUI 3.0.

[skendrot]

TreeView does have an ItemsSource property but it is not an ItemsControl and doesn't allow for binding nested children of the tree.
TabView likewise is not an ItemsControl and it does not have an ItemsSource property.
Controls that are used to display a collection of items should always inherit from ItemsControl, not Control

[skendrot]

Digging a little more and found that despite TreeView using TreeViewNode everywhere, there is actually a TreeViewItem control that is used "under the hood". Makes no sense why the two classes are used instead of one and why TreeViewNode is exposed at all

[jevansaks]

TreeView does have an ItemsSource property but it is not an ItemsControl and doesn't allow for binding nested children of the tree.

TreeView is the first example of a hierarchical databound control in XAML. It works differently than it did in WPF but we have some samples in the Xaml-Controls-Gallery about how to do it.

TabView it's called TabItemsSource and it's also a little complicated to bind because there's header and content but it's possible. The gallery doesn't have a sample but there is a test page.

We've started steering away from heavily derived trees in WinUI because polymorphism over UI types like RangeBase and ItemsControl provides little value, and the base controls especially like ItemsControl have a lot of baggage that comes along with them. Flattening the hierarchy gives us a lot more flexibility to make the control work well for its scenario and enables us to change implementations over to things like ItemsRepeater going forward.

[stmoy]

TabView it's called TabItemsSource and it's also a little complicated to bind because there's header and content but it's possible. The gallery doesn't have a sample but there is a test page.

Hot off the presses: we now have a sample in the Gallery! It hasn't yet been pushed to the Store, but the sample is here - [markup] [codebehind]

<TabView TabItemsSource="{x:Bind myDatas, Mode=OneWay}" AddTabButtonClick="TabViewItemsSourceSample_AddTabButtonClick" TabCloseRequested="TabViewItemsSourceSample_TabCloseRequested" />

[moderndev]

Controls that are used to display a collection of items should always inherit from ItemsControl

Conditioned over the years to think this way .... Why I wished we stayed with keeping controls managed and in this repo

We've started steering away from heavily derived trees in WinUI because polymorphism over UI types like RangeBase and ItemsControl provides little value, and the base controls especially like ItemsControl have a lot of baggage that comes along with them. Flattening the hierarchy gives us a lot more flexibility to make the control work well for its scenario and enables us to change implementations over to things like ItemsRepeater going forward.

I applaud this thinking, also moving to a more 'data oriented design' is a nice goal but too radical for alot to grasp.. My concerns with the winrt ui xaml controls was that you would move in this direction..

Sigh

[michael-hawker]

I'm going to close this PR for now until we know the remaining gaps are addressed in WinUI. Hopefully in the WinUI 3 timeframe we'd be able to close this out to start fresh in WinUI 3 land.