Reply to post: Re: Menus and application windows

Say helloSystem: Mac-like FreeBSD project emits 0.5 release

ThomH

Re: Menus and application windows

No to disagree with the main part of this comment, but the menu bar always relates to the frontmost application. If that application has any windows at all, they'll be on top.

That aside, I set my menubar to hide automatically and rarely mouse up to it other than when heading for the Apple menu for system preferences and suchlike; even when I want something from the menu bar it's almost always easier and faster to use the keyboard shortcut — either the specific one or command+shift+/ to open the search box.

I have two relevant suspicions:

Firstly, that Apple simply considers the menubar to be part of the brand. It made an awful lot of sense in 1984, when the Mac had a 9" display and ran exactly one application at a time, and from there the classic OS was stuck with it by the same complete lack of forward-planning that also prevented the addition of memory protection, preemptive multitasking, etc. So I'm imagining it was then carried forward to OS X because, you know, Macs have menubars, and if you're Apple circa 1999 then how many more of your customers can you afford to lose anyway?

Secondly, that almost everybody who writes a Mac app nowadays makes sure to put almost nothing in the menubar, because it's so disconnected. Even floating tool windows seem to be out of fashion. macOS just seems to be a little behind here; I think the same instincts finally fully manifested on Windows whenever we all accepted that the multiple-document interface — the old big parent window with multiple child windows, pull-downs belonging to the parent but acting on the currently-selected child like a desktop within a desktop — was a terrible way to show multiple documents.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon