Ah OK. I'm a bit confused though, so if you don't mind spelling it out for a noob....

1. I was under the impression that the application menu was removed by GNOME in 3.32... so why is there anything left for this patch to remove?
2. A "vendor key" means an option for distro devs to turn it off in the packaging step?
3. What happens (UX-wise) if this patch is not applied? Menus appear in the top bar even when the switch is turned off in gnome tweaks?

Thanks

I was under the impression that the application menu was removed by GNOME in 3.32... so why is there anything left for this patch to remove?

I was under the same impression but the reality is it wasn't. They actually forced it to be enabled, despite all the effort they did in the GNOME 3.32 stack to move appmenu functionality for individual apps into those apps.

A "vendor key" means an option for distro devs to turn it off in the packaging step?

Or a reliable gschema key / val. I checked on my laptop and across their schemas for something to achieve it, didn't find anything.

What happens (UX-wise) if this patch is not applied? Menus appear in the top bar even when the switch is turned off in gnome tweaks?

It's on by default, which I don't want. Because the AppMenu is pretty useless.

Got it, thanks. I compiled gnome shell myself without the patch (Solus makes it so easy :)) and yeah I see what you mean, the switch in tweaks doesn't do anything, the app menu is just always on.

I looked into this a little and it appears that there was something of a change in plans at GNOME (or the blogosphere just publicized an early-stage proposal that wasn't yet settled... idk).

Towards the beginning of this discussion, 7 months ago, the OP states that "the idea is to remove the whole thing" -- no more menu of this sort in the topbar. But then towards the end, 2 months ago, he says

I've personally been back and forth on what to do with the app name and icon in the top bar. Right now, my feeling is that the safest approach is probably to keep the indicator in the top bar, along with a menu similar to the one that's found in the dash, with items like "New Window", "Show Details" and "Quit"

So that suggests that the decision in the end was that there will be two menus, one within the app with more app-specific stuff, and one in the topbar with more general window management stuff.

This more recent discussion is in line with that. Indeed I'm noticing that without the patch applied, both the menu in the app and in the top bar are present, but the contents are different.

With this in mind, would you consider reversing your decision to remove the "app menu" in Solus GNOME?

I don't use it either, but I think that the GNOME devs' decision here is reasonable. I haven't read through all of that discussion, but I know that there were, for instance, complaints that removing the app menu would remove a (sometimes) useful indication of which window is focused. I think this is a valid concern, and this decision addresses it (though a full-blown menu does seem unnecessary). In any case, it doesn't look like the window in the top bar is going away any time soon.

both the menu in the app and in the top bar are present, but the contents are different.

It will depend on an app-by-app basis. Most applications implement the identical functionality in the headerbar, app menu, or with the menu that is present when you click on the application icon that we have set as part of the default window decorations.

With this in mind, would you consider reversing your decision to remove the "app menu" in Solus GNOME?

No.

I haven't read through all of that discussion, but I know that there were, for instance, complaints that removing the app menu would remove a (sometimes) useful indication of which window is focused

Issues around window focus are, as one of the users states, something which can be resolved in the GTK theme by changing the active window backdrop. This is something that would / should be addressed by Plata, is already addressed by Adwaita, etc.

Their (the GNOME dev's) argument against is just "this should be extension territory" when they are effectively breaking previous user behavior / userspace by forcing it on and removing the very functionality which allowed it to be disabled in GNOME Tweaks to begin with. That is, to put it politely, incredibly stupid. I'm not going to support GNOME's backwards behavior in this regard.

It will depend on an app-by-app basis. Most applications implement the identical functionality in the headerbar, app menu, or with the menu that is present when you click on the application icon that we have set as part of the default window decorations.

In 3.32, these menus are different than the menu in the top bar. I just tried like 10 apps. The menu in the top bar is identical to the menu you get by right clicking on the icon in the dock or dash, except "add to/remove from favorites" is replaced by "quit".

I agree though that it should be toggle-able by the user.

Just came across this when I went to compile the shell without the patch after upgrading. Thanks for doing this! Unite is working very nicely.

For anyone coming across this later, just do gsettings set org.gnome.shell show-app-menu true to enable the app menu and Unite will work.