The Gnome Global Menu extension is discontinued again
Please see:
GTK+ no longer supports generic loadable modules
source: https://blog.gtk.org/2018/06/26/gtk-3-94/
The last cite mean to me, that if we don't like how Gtk+ is doing something, we can not modify it anymore.
This Gtk+4 fact, will be sad and will make Gtk+ unusable to the Gnome Global Menu extension, as it's implemented now. That's why the Gnome Global Menu extension will be discontinued again. The first reason was because the lack of the Gtk+ Wayland support for the Global Menu, that was resolved here and now will be because Gtk+ will no longer supports generic loadable modules.
One thing you need to know, is that the unity-gtk-module and the appmenu-gtk-module are both generic loadable modules and then they will have not support in Gtk+4, bloking the uniform support for the global menu, to the Gtk+4 applications.
All this means for the Gnome Global Menu extension, that now is only in the hands of the developer of a Gtk+4 application, the decision to export the menubar, the appmenu, both features or nothing. Of course then, the result of that decisions will be that some applications will exported the menubar, while others will export the appmenu, others will not export anything and some ones will export both. Is easy to see then that this will be a full-chaos if we will have not way to unify all developers decisions to work at same way.
In my opinion, continues the support of the Gnome Global Menu extension in that context, will only contribute to have a linux desktop similar to a Frankenstein, with one application working in one way and another in another. All that will be with base on the particular decision of the developers. So, if we will have not really be able do anything to fix that situation and make it uniform, the global menu will be then a chaos more than a solution to something.
In fact, this problematic escape also to the global menu feature. If for example we don't like the window CSD feature of Gtk, we can not use a module like gtk3-nocsd, because in Gtk+4 it will have no way to modify (hacks) the Gtk+ internally. This also mean to me, that the shell developers will have not the chance to apply a procedure to make more uniforms the applications in his desktops. They also will be limited to create or port concepts from other places, like was the case of Unity desktop in a lot of aspects. In my opinion, this will make all Gtk+ linux desktops more and more plastics and lacking of innovative concepts, because they will need to accept the upstream conceived Gtk+ features, or they will needs to avoid the usage of Gtk+ in favour of other toolkit with more configurable options.
Also, some application developers will prefer to stay in an older version of Gtk+, to keep compatibility with a feature that was supported thanks to a general Gtk+ module, that now will have not way to be loaded. This fact will stooping the normal evolution of that application to a new Gtk+ version, that without any doubt will have a lot of improvements.
Of course, if a solution to Gtk+4 is found, we can revert the state of the extension when this happens. Ideas to fix that problematic are welcome.
Please also see that the same Gtk+ developer (@matthiasclasen) that say in this source:
If you rely on loading GTK+ modules, please come and talk to us about other ways to achieve what you are doing.
Then close an issue about this problematic here: https://gitlab.gnome.org/GNOME/gtk/issues/1132 making clear that actually they don't want to help in all cases.