Out of the box macOS doesn't have a button to maximize the way Windows does. The green button in modern macOS is for full-screen and option-clicking that button will bring back the old "zoom" behavior which expands the window to fit the content being displayed. It's a lot less frustrating of an experience when you realize that the button doesn't do what you assume it does.
I suspect that'd play absolute hell with either their UX concept or the underlying UI abstractions / implementations.
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.
No...macOS doesn't work that way. There are a few hacks (Afloat, Helium) but all require disabling SIP, which is not desirable. And even if they didn't require disabling SIP, they only work part of the time in my experience.
Windows does not use a window manager like X does; the frames are drawn and managed by a library used by all applications, it’s not a separate program.
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).
arinlen|3 years ago
I'd already be happy if maximizing a window on macOS worked reliably.
fnord123|3 years ago
patrickserrano|3 years ago
shadowgovt|3 years ago
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.
weeddy|3 years ago
Also through dock you can configure a window to be on all of the screens
*<-using macos 10.14
breakfastduck|3 years ago
So many ways on windows / linux.
gundamdoubleO|3 years ago
enriquto|3 years ago
capableweb|3 years ago
> 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).
rufugee|3 years ago
tinus_hn|3 years ago
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).
guerrilla|3 years ago