I don’t know the exact history, but iirc the Athena widgets were developed at a time when the GUI vocabulary was still in flux. Personally I find manipulating Athena widgets to be pointlessly complicated anyway – grab and drag with the index finger maps much more closely to meatspace object handling than Athena’s strange middle button thing.

I do wonder how closely Athena behavior matches Smalltalk-80’s. Squeak isn’t as obvious a parallel as you’d think, though it’s pretty alien in its own right.

I suspect menu bar placement on very large screens is largely a matter of personal choice. I won’t speak for all Mac users, but setting the mouse speed as fast as I can reasonably handle it works fine for me. It may be different for multiscreen setups, but I’ve never been so lucky as to have that.

Of course, if you don’t use the menu bar, then its position doesn’t matter much.

Common user testing shows that most users use it quite a bit too, even when keyboard navigation is available, except for a very few commonly used commands. Your profile is almost certainly different from Joe User’s.

Now you may argue that Linux is not intended for “common users”, and therefore my point do not apply. I have no problem with that.

And which papers? All my papers are scanned and stored. Thereafter they occupy some real estate in a window on my screen, why I want maximized to the paper size, not more.

Having such a large screen (two of them in fact) lets me have many pieces of information on the screen at the same time, which I find invaluable for my job developing software. The last thing I want from my IDE is to cover all those windows when I maximize one of them.

If I had a really wide screen, I wouldn’t want that either. I prefer multiple regular shaped screens.

I don’t have any problem getting my mouse to hit a target, though. And, Fitts law is about time to hit target, while my concern is knowing where the target is because I’m accustom to it. I may, for instance, have preferred the windows controls on the right side (or even bottom somewhere like they are in emacs) had I been accustom to that.

I think this may be a case of misplaced fetishizing of an efficiency that is not really important. The best use of the mouse, if you want efficiency, is to hold down your papers in a breeze while you get busy with your keyboard!

Fitts law states that the time acquire a screen target depends both on the target size and on the target distance:

t â?? f(d/s) where t is the time, s is the target size, d is the target distance, and f is an increasing function, often taken to be a log function.

As you can imagine, when s â?? â??, then d doesn’t matter.

The point is: for the top of the screen (or any edge), distance doesn’t matter.

Now I get what you mean about the infinite height. Makes sense, except it is also the case that the menu is not always nearby. Unless one always maximizes the window. Therein lies the problem. .

Because a menu bar inside a window has a finite height, which makes it a hard target to hit. While a menu bar at the top of the screen has an infinite height, and makes it easy to hit.

On my Linux-Gnome screen, the top of the screen is occupied by system menus. Application menus are in their own windows. The result is that the most often used menus are difficult to hit, while those menus that I use less often use the most precious User Interface resource: the screen edge.

This is totally screwed.

(regarding your comment re the maximizing behavior, you basically have the same opinion as mine: always maximizing to the whole screen is dumb).

Why?

Maximizing to the largest area necessary to enclose all the available window content arguably is more efficient use of available screen real estate.

That does not make sense for a lot of applications. More than half of what I do is done inside a text editor that starts out blank. 20 percent of what I do is done in a terminal that starts out with a prompt. There is no pre-existing thing. Rather, there is my personal concept of what size I want the window to be when I use it. And, I do wish that was a bit more automatically adjustable.

I always wondered why by default, the gui version of emacs put the scroll bar on the left (though as expected this is easily changed).