[oneplane]

IIRC this is one of the reasons the UI on the Mac opted for a fixed context-dependant menu bar at the top of the screen instead of the per-window one used by Windows (and Java).

It's basically 'fling your pointing device at the top' and 'go left or right to get the button you want'. Due to the lack of borders/stops, this would be harder if it was sandwiched between a titlebar and window content.

[205guy]

The reasoning is that mouse stops the border of the screen no matter how far the mouse is moved, making an effective target that is huge off the screen, so easy and quick to hit. This would hold true even with large screens, unless you dial down the acceleration of the mouse for fine control--as others have pointed out.

But the issue is Apple broke the whole mechanism with hot corners. Now if I move fast anywhere near a hot corner, it gets activated. And now the menu bar near the corners is tiny and hard to hit with a "huge" hot corner right nearby (the hot corner gets the benefit of the inifinte off-screen target). I find the same problems will full-size browsers (with tabs along the top), I'm always hitting the hot corners instead of the top lerpft and right tabs. I guess I can always change my corner settings.

Additional gripe about the top menu in MacOS: the biggest fault I've found is that it can be active for an app whose windows are hidden or that currently have any windows, thus creating a mismatch between what you see (other windows) and what is active (responding to keyboard shortcuts for example).

[lloeki]

> But the issue is Apple broke the whole mechanism with hot corners.

Well I always hated hot corners, and anyway by default they're disabled on macOS.

[natecavanaugh]

I'm super happy you brought up the infinite border aspect of the top menu, because that is the best aspect of it, and whenever I go back to Windows, that required fine touch control drives me nuts.

But WRT hot corners, the best part of hot corners is being able to assign a modifier key to them. Without using the modifier, it's crazy annoying, but having a modal aspect that requires active engagement seems to me the best of both.

Then again, I haven't actually engaged a hot corner in years. I find Keyboard Maestro the best option of all.

(P.S. just for anyone who doesn't know how to add a modifier to the hot corners, just hold down Ctrl, shift, option or CMD when selecting the setting).

[stouset]

OTOH, that behavior is absolutely necessary for me!

You can use Cmd-Tab to activate an app that has no windows, in order to activate hotkeys that let you create new windows! Especially when you’re using multiple desktops, this ability is invaluable.

[Sylos]

You can however also argue against having such a global menubar with Fitts's Law, as it means that other UI elements can't be placed at the screen edge, such as the min/max/close-buttons (though there are also concepts where those are global, too) and nowadays also browser tabs.

[oneplane]

While partially true, this could be solved by simply assigning priority to UI elements. Launchers/window managers often list their stuff at the bottom or sides (like docks and window lists) which allow for the same ease of navigation. There is of course only a 4-side box that you can use, and cluttering an environment with bars at all sides doesn't help a user.

The close/resize/etc buttons are indeed a different issue, while the controls are often duplicated (File or window menu on most operating systems and window managers have the close/resize/max options too). At some point I think Ubuntu had a default desktop environment where the close/max/min buttons were added to the top menu bar. I thought it was quite a nice idea, but the implementation never spread to other systems and sadly, support wasn't very universal across all applications.

Thinking along those lines, what if you added the title bar at the top too, you'd end up without a border/bar at the top of the window, making it harder to find something to 'grab' with your pointing device. Some operating systems use a modifier key + the mouse to turn all windows draggable and disable inputs while doing it, but that hasn't had much success (aside from it being the default on certain window managers).

[eadmund]

It was. I wonder, though: with modern monitor sizes, does that make as much sense as it did with a 9", 512×342 screen?

[ken]

"People for years have been explaining to me very patiently that in this era of giant screen monitors, we just have to do something about those menu bars way up there at the top of the screen" -- Tog, column 15, May 1990

He then describes an experiment where he used a 21-inch monitor and a 13-inch monitor attached to a Mac, and had subjects change the color of folders on one screen by selecting menu items on the other. Even compared to a pop-up menu right under the mouse, the far-off edge menu bar was still faster.

Objects on a 2018 MacBook Pro can be 70% further apart (D) than on a 1984 Macintosh, but the edges of the screen are still infinitely big (W).

[dsr_]

Depends on two things:

1. How fast can you get the pointer to the menu?

2. How easy is it to get the right item?

If you have a "large" screen, I would contend that having a dedicated menu button on your mouse/trackpad/trackball/pen is the best possible thing for any user who isn't a complete novice. Don't wave the pointer somewhere else, make the menu come to you.

If you can't do that for whatever reason, then having a high-acceleration pointer that can be flung all the way against an edge is next best. Going back to where you were, though, will be relatively hard.

[oneplane]

The 'make the menu come to you' approach would make sense for large and/or unusually controlled screens. Take game consoles and their directional controllers or old style mobile phones with numeric keypad for example, they made most menus pop up in context-menu style.

I imagine something like holding a menu button which acts like a modifier key that also pops up a menu on-screen. Then, using a physical layout on the screen that matches the layout of the buttons on your controller or pointing device to navigate/select items of choice without using x,y pointing systems such as the mouse arrow. This does however create a new problem: how to decide where the menu is going to overlap over the stuff you were working on?

[userbinator]

I remember this explanation too, but think it's one of those "good in theory, bad in practice" things --- going all the way to the edges all the time (and back!) is very tiring if you have your mouse set for high accuracy and have (a) huge screen(s).

This is something I remember very clearly since it was the explanation I was given when I first tried out the original Macintosh decades ago. Even with its tiny screen I had to lift and reposition the mouse, or otherwise move my whole arm, in order to go from one edge to the other. The other annoyance that stood out was menus that didn't stay open unless you held down the button, and a complete lack of keyboard navigation (I know about the keyboard shortcuts, but it doesn't compare to being able to browse through the menus with only the arrow keys, which could be done even with early Windows.)

[eitland]

Used a Mac full time three years.

Having to

-move the pointer diagonally across two screens, then pick something in a submenu (carefully, I think the submenu disappears if you don’t hit the end of the first menu and instead tries to move directly to the item in the sub menu)

- and back again

is one of the things I never miss.

[ninkendo]

MacOS's dual monitor implementation puts the current window's menubar on the current screen now, so at least you don't have to go across two screens.

[oneplane]

macOS treats click-hold and click-release differently for menus. Click-hold is for when you want the menu to disappear by itself, click-release for when you want it to stay open until you click on something else.