Re: Menus in windows @DrXym
What you call the frame area, which I believe corresponds to what I called the menu bar is rendered by whatever toolkit you are using from inside the application (and, critically, the application's process space). The application can totally control what appears on that bar, although it will normally use standardised toolkit routines to do it.
This does not make it the Window Manager that is providing that menu bar. The Window Manager controls the encapsulating frame, and all of the widgets that it used to do this are outside of the application's process space (but do note, however, they may not be in the Window Managers process space - it could defer these to other processes under the way X11 is structured).
Do not confuse the Window Manager with the widget runtime shared object/library. They are not the same thing.
I see what you are getting at, however. The toolkit routines that create the menu bar are normally in shared objects/libraries that are dynamically bound in to the executable at run time. By providing a compatible but different set of routines at runtime, I can see that compliant programs could have their behaviour changed by the system, so that it would indeed be possible for the runtime to intercept and alter some of the expected behaviour.
But note that I said compliant programs. What about those that do not use the Gtk and QT runtimes to manage their menu bar. What if they do, but have statically linked the routines available at compile time. What if they are so old that they use the Xtk or Andrew Toolkit, or Motif, or CDE. Or, heaven forbid, coded all of the menu bars themselves!
If the modification is done at the runtime-call level (and this could be the bit I was unable to see when I wrote my earlier posts), it would be necessary for Canonical to patch each and every dynamically bound widget toolkit, and they would totally fail to manage statically bound binaries.
Regarding your comments on Wayland, remember that Canonical is not implementing Wayland. Their alternative to X11 is Mir, but this is not in current releases of Ubuntu. We are not talking about Wayland.
If, however, Wayland is making it the responsibility of the application to draw all window decorations, then I can see problems ahead when applications hang or crash. Having things like the "Close" button handled by another process, to allow mis-behaving process to be closed, is such a good idea that I wonder about the sanity of the Wayland developers in throwing this away. I have often wondered whether their drive to eliminate the overheads of X11 will end up throwing the baby out with the bath water. X11 may be old, but the concepts it introduced were mostly very sound, with the possible exception of the poor security model.