You could theme some window manager, but it's not the same. It'd be a tough project! The Mac UI was holistic. Early on, it didn't even make much of a distinction between application and operating system. Just getting the menu bar right (shared between OS and application) when every program has its own idea on how to present a menu would be a major challenge. Applications really do need to be designed for the classic Mac environment. Back in the day software was almost never ported directly, but had to be substantially redesigned for the Mac.
Yeah, apps were responsible for drawing the menu bar and handling its mouse events (delegated to toolbox libraries). They also used to ask the OS to put in the menu items for the apple menu, and were responsible for delegating those mouse clicks to the OS as well. Background tasks required the foreground app to release the processor (or interrupts like vertical blank). Everything depended on proper cooperation.
Linux has a standard protocol (dbusmenu) for exporting menu structures supported by most common app UI libraries, and environments like KDE's Plasma use this to offer a global menu bar option, too.
Unfortunately there's a number of Linux apps that don't publish any menus, including most GTK3/4 and Electron apps. I don't think Firefox does either. I remember trying the global menu option in KDE and being sorely disappointed in how few apps populated it.
To get consistent usage out of a dbus-based global menu (KDE's or that one XFCE panel plugin) one would need to fork quite a number of packages, and for proprietary Electron apps you'd probably just be stuck.
GTK apps can support the global menu. There's a GTK plugin that adds support, and many distros install it by default. I think it was originally written by Canonical (their custom Unity desktop also used a global menu bar).
Not sure about the state of things with Electron. I'm sure you're generally right and there are some gaps, and of course, on Mac OS you do only very rarely encounter an app with an empty menu bar (I have though).
It's not maintained, but a few years ago I was feeling nostalgic and playing with "mlvwm", the mac-like virtual window manager, a project from the late 90s.
At least a small amount of C knowledge is sometimes helpful for getting those old projects working. Sometimes a new compiler or new libc will expose old bugs.
My experience with old window managers is they need tweaks to work reasonably on modern high dpi displays.
Iirc mlvwm builds with imake, which is positively ancient. It's the build tool that X.org got rid of after taking over from XFree86.
Ah, so you're the one I have to thank for that! I've used it on Solus and a few others after my dual 867 "Mirrored Drive Doors" machine went down. Thanks!
