Things to consider:
We could start from something like this:
<CommandBar HorizontalAlignment="Center" VerticalAlignment="Center" OverflowButtonVisibility="Auto">
<AppBarButton Content="File">
<AppBarButton.Flyout>
<MenuFlyout Placement="Bottom">
<MenuFlyoutSubItem Text="New">
<MenuFlyoutItem Text="Project" />
<MenuFlyoutItem Text="Solution" />
</MenuFlyoutSubItem>
</MenuFlyout>
</AppBarButton.Flyout>
</AppBarButton>
<AppBarButton Content="Edit">
<AppBarButton.Flyout>
<MenuFlyout Placement="Bottom">
<MenuFlyoutSubItem Text="Go to">
<MenuFlyoutItem Text="Go to project" />
<MenuFlyoutItem Text="Go to line" />
</MenuFlyoutSubItem>
<MenuFlyoutSeparator />
<MenuFlyoutItem Text="Undo" Icon="Undo" />
</MenuFlyout>
</AppBarButton.Flyout>
</AppBarButton>
<AppBarButton Content="View" />
</CommandBar>
Any example of this "classic" version that we are talking about?
Think about VS:

Maybe this might be even better
https://www.thomasclaudiushuber.com/2017/02/18/lessons-learned-from-building-a-visual-studio-shell-with-uwp/
Do we have a defined set of features that we want to support? So far i see using keyboard shortcuts and keyboard navigation with this. Styling is going to be weird as well.
yep keyboard nav, shortcuts(access keys)
Current MenuFlyout is not mvvm compatible afaik. No matter what we do we must consider mvvm approach first imo.
Probably a combination of keybinding and button command (both bind to a ICommand) ?
@hermitdave The blog post of Thomas Claudius Huber is really awesome. I like the look of the menu in his Visual Studio made with UWP.
It's important to understand the motivation behind wanting something like this. Is it that someone must have an identical equivalent to the current/traditional/classic menu? Or is it something that's needed as a "stepping stone" to a newer, more modern, interface? I ask because there's no justification here which makes it hard to know that the right thing is being built and I'm reminded of a project I did many years ago which was porting a green-screen app to win32.
With that project, we recreated the green screen experience with something visually similar such that it didn't require any user retraining, even though we'd completely rewritten the front end and there were a few subtle differences in how it worked. The rewrite meant we could slowly replace, update and enhance the app a part at a time with modern (for then) UI without upsetting and confusing users with a big change at a single time.
While I can imagine a menu control as is mentioned here being useful it's important to understand why it's wanted and how it's expected to be used. Without this, you risk just creating a new control that may not be what's actually wanted.
One of the motivation here is to provide a required control for desktop developers. They may be motivated to move from WPF or Winforms while keeping some of their UI
@deltakosh Sorry, I wasn't clear. The point I was trying to make is that it's valuable to understand why the people who will use this control want it. It's always better to understand what people want and then build that, rather than build something and then ask if it's what they want. Doing the research up front avoids wasted effort and disappointment when people don't get what they were hoping for.
Building a control like this makes sense for a lot of reasons but what are the specifics of should be built?
Is the aim to recreate exactly what's currently possible in WPF? And WinForms? or should it be something updated and more appropriate to a modern app?
WPF, in particular, has a lot of properties, and even more events, for a MenuItem. Are all needed? If not all then which?
Or is the purpose of this item to first define these things?
Ok I get your point.
My initial thinking was to provide a WinForms comparable Menu control but you are completely right,let's use this issue to discuss what kind of API do we want.
ANy thoughts on this?
My POV here is that we should start by mimicking the WinForms behavior while keeping it simple.
Who is motivated to give a first try?
Did you really just say
we should start by mimicking the WinForms behavior
I read it as start with something simple.
Yep, no need to go wild directly. A first step with a really simple menu
I will try to find time to do it. Anybody is welcome to pick this up in the mean while.
If there's nobody asking for this and able to provide any specific requirements then I'd support the approach of creating something simple at first and then extending it as requested.
Specifically, I think it needs to have:
With no specific requirements coming in from real-life usage, I don't think this needs complex MVVM support.
@mrlacey not seen common usage of checkboxes in menu. but agree with general list.. I'd add commanding so be forward looking
Agree with both of you. If we have a first version with all of these it's gonna be perfect
How critical is Touch support, classic menus get criticized for lack of "Touch" ease of use, so what is primary input needed for this new menu system since it's UWP which focuses heavily on touch friendliness?
Keyboard, mouse and touch must be supported
Its not a control per say, but I have used something like below in my app.
and
We can replace the icon only to text label to give it a menu feel.
Personally, I'd prefer to move away from a "Top" menu with dropdowns and instead have "Shelves" with menu items within a panel.
I'd want the first "Shelf" to be a customized list of actions that I use frequently - Visual Studio has countless menu items, but in reality you only use 10-20 of them on any given day. Let me add the ones I want and let me re-order them.
Secondly, I'd want to have a customizable "Command Bar" at the top of my custom Shelf. And of course the option to "Pin" open my Shelf.
All the other shelves would be whatever that specific app would need. Personally I'd go away from "File, Edit, View, Window, Help and try to merge some of those items together.
Keyboard Shortcuts would be easy to use, Keyboard Navigation would be easy, you could easily show Keyboard Shortcut codes and of course you can have icons. Hover effects could use the new Lights coming in Creative Update.
Having a Shelf would be far more powerful than a bunch of dropdowns, would be far easier to code and customize on the fly, pinning it open would be super helpful and you could have virtually unlimited number of menu items within each shelf as you could add in scrolling. You could dock it to either side of the screen, and those of us who use VS would be used to this type of experience.

@micahiverson these changes have to be phased in. If you have a binary option, menu (old way) and something totally different, the adoption would be very small.
The old ways are still in heavy use and desktop bridge and further adoption of XAML / UWP by those apps would depend on how close the UI / UX can be.. not how modern.
I think the point of this control is more like a way for older app to be ported to UWP without having to redesigned the whole UI/UX, but i agree that we should also make this more flexible if we can.
I think the question @micahiverson wanted to point out , is how touch-friendliness would this control be. More like how Windows scale the right click menu style from small/clean for mouse and big for touch.
Err.. We shouldn't be thinking of one or the other. Any pointer interaction is welcome. So touch is equally important.
completely aligned with @code-scottle
I was thinking this was in part re-thinking what it means to have a "Classic Menu" that would work well in UWP and offered a more flexible UI experience. Rather than, how can we technically build/support a Windows 32 type of menu system.
I will start working on the classic menu in case no one already started :)
Wonderful! It's all for you:)
closing via #1086
how to show shortcut key in menuflyoutItem uwp
@Ajit14Singh For generic UWP questions it is best to ask on stack overflow
Most helpful comment
I will start working on the classic menu in case no one already started :)