Update: Jasper St. Pierre
I want to point out that this was simply done for technical cleanup reasons as part of Wayland. We went from a GTK+ menu with some entries in it to a gnome-shell menu with the same entries. So it’s not a giant change.
The design team wasn’t involved in this bug. If I talked to them, maybe we could consolidate some of the menus.
Implement window menus in gnome-shell
This is something we’ve wanted to do for a long time for code clarity reasons and design reasons. Wayland really gives us the first opportunity to do it.
Convert window menus to use a compositor implementation.
Window menus being GTK+ widgets has always been frustrating to deal with. Under Wayland, GTK+ is using the X11 backend, so the menus there pop up in the wrong place, don’t take a grab, and are unstyled.
Given that we have a sophisticated menu system as a replacement in gnome-shell, we can port over to using that instead.
This does remove window menus for the default plugin, but given how we’ve been steadily removing features for that the entire time, I’m OK with this tradeoff.
This removes the bare minimum of unused code I could find. There’s probably still a lot of code left working around GTK+’s grab tracking that could go away entirely. A full cleanup should be
Obviously it will not work on applications that have custom header bars (like Chromium, if you have disabled system title bar and borders). At the moment isn’t either working with CSDs, but this is something that will be done soon!
Is it just a menu?
You can tell that is just another menu, but in reality is a new container that we can easily extend. For example we could add the application menu there as well, or have some custom events etc.. So it is pretty cool! It also looks nice too!