I'd pay good money for an 'Always on top' window option on mac.
I'd already be happy if maximizing a window on macOS worked reliably.
I've referred to macOS's "maximize window" feature, which you trigger by double-clicking a window's title bar.
This would create a situation where an application has one window foreground above the foreground application while it is not the foreground application.
On the UI / implementation side: I don't think it's possible to have any windows of an app foregrounded past the foreground app's frontmost window if that app isn't itself foreground. They'd have to create a new category of window (and probably move a bunch of internal data structures around) to make that possible. I know, "it's just code," but it's code based on some very deep and old assumptions about the way the window manager works that probably have hard-to-predict consequences if violated.
On the UX side: having a window floating foreground when the top-of-desktop menubar says another app's name in the corner is going to trigger a "WAT" for a lot of users, and I think Apple is deferring to them.
Also through dock you can configure a window to be on all of the screens
*<-using macos 10.14
So many ways on windows / linux.
> Can't you just use a different X?
Lol, this is Apple we're talking about, the company famous for not allowing people to customize things to their own liking (for better or worse).
I find this very foreign. As if a unix system didn't let you change the shell!
This is sad to hear, because I'm a happy user of a headless macOS (not set up by me), to which I ssh almost daily for testing purposes, and it is a fairly decent unix system. It has a few idiosyncrasies, sure, but those help to make your pipelines more portable. I always supposed that the GUI would be just a regular program running on top of that unix.
It is launched via /System/Library/LaunchAgents/com.apple.Finder.plist
I’m not 100% sure but I’d say it’s pretty likely Mac OS works the same way, just like on Mac OS the left part of the menu bar (including the system menu) is drawn and managed by the current application (using a system library so the application developer doesn’t have to worry about how it works).
IIRC it is not drawn by the application, it's a system app that gets the focused (or rather, activated) app menu hierarchy as the app instructs through some IPC, but it's not the app process itself drawing there. The only part where an app actually can draw is on the right part, when one implements menu bar extras (which previously required hacks to inject into because the menubar extra API was severely limited, but IIUC now has a dedicated, managed API to replace the hacks)