March 13th, 2007 • 10:56 am
For a very long time, Mac OS has had this feature where you can command-click on the title bar of a background window to move it around behind the current foreground window without bringing the background window to the foreground.
This is handy in a variety of situations, where you don’t want to switch away from your current foreground window, but you want to be able to see the contents of some other background window on the side.
There has always been one fundamental problem with this handy feature, however, which is that command-clicking on a window’s title bar also has another meaning when the area you are command-clicking on happens to be the center area where the window’s title appears.
That other meaning is that command-clicking on a window’s title itself normally brings up a pop-up menu showing the path to the location of the window’s corresponding file on your hard drive:
So, if you are an Apple engineer, how do you elegantly reconcile these two seamingly incompatible uses of command-clicking on a window’s title bar?
Well, it would appear that, if you are a Mac OS X engineer, you simply don’t. You don’t even bother to combine the two uses in a way that makes any sense for the end user.
I have already had the opportunity to explain that, in Mac OS X, command-clicking on a the window title itself in the title bar of a background window does not allow you to use command-clicking to move the background window around.
Instead, it brings up the pop-up menu with the path to the document window’s file. I honestly doubt that this is the preferred behaviour for the majority of Mac OS X users. Think about it: The user is currently working in Window A, and Window B is in the background, half-hidden by Window A. The user command-clicks somewhere on Window B’s title bar.
What is most likely to be the intention of the user here? Does he want to command-click on the Window B’s title bar to move the window around, or does he want to command-click on the Window B’s title to bring up the pop-up menu with the path to Window B’s corresponding file?
Or, to put it another way, is it really more likely here that the user wants to see the path to the corresponding file of the background window, rather than move the background window around?
That’s bad enough as it is. But now consider the following additional fact: In Mac OS X, there are a number of windows where command-clicking on the window title itself fails to bring up a pop-up menu with a path, simply because there is no path to speak of, or simply because Apple has failed to implement the feature in that particular case.
One such example, among many others, is the main window in the Address Book application. Address Book’s main window has a title bar and has a title in the middle of that title bar (“Address Book”), with a little proxy icon next to it, but command-clicking on this title (or the proxy icon) fails to bring up a pop-up menu with a path, quite simply because, in this case, the window is not a document window and does not have a corresponding file in the Finder.
So command-clicking on this title when the Address Book window is in the foreground does nothing:
That’s fine, I suppose. What’s not so fine, however, is what happens when the AddressBook window happens to be a background window, and you want to command-click on it to move it around without bringing it to the foreground:
Guess what happens here? Based on the click-through behaviour referred to above and described in another post, command-clicking on the Address Book window’s title should bring up a pop-up menu. But there is no pop-up menu to bring up, because the Address Book window is not a document window that corresponds to an actual file in the Finder!
In this case, you would think that the Apple engineers involved without be able to use a little bit of common sense:
- Right, when the user command-clicks on a background window’s title, we’ve implemented this “click-through” behaviour that brings up a pop-up menu of the path to the file, instead of allowing the user to use command-click to move the background window around.
- But in the case of windows with no path, command-clicking on the window’s title—whether the window is in the foreground or in the background—won’t bring up a pop-up menu with a path, since there is no path. In addition, clicking (without the Command key) on the window’s title when the window is in the foreground can be used to move the window around.
- So in that case, we should probably restore the other command-click behaviour, i.e. allow the user to command-click on the background window’s title to move it around without switching it to the foreground.
What do you think? Do you think that the Apple engineers involved did the sensible thing here and allowed users to use command-clicking on the background window’s title to move the window around?
Of course not. Instead, command-clicking on the title of a background window whose title does not bring up a path does… absolutely nothing. It doesn’t bring up a path (since there is no path to bring up), but it doesn’t allow you to drag the window around either. It is effectively a dead area in the window’s title bar. Command-click anywhere else in the background window’s title bar, and you will be able to move the window around, as expected. But not when you command-click on the window’s title itself.
And, since this window title can vary in length, there are actually cases where the window title takes up almost the entire width of the window’s title bar. In such case, the dead area becomes effectively almost the entire title bar, and it is in fact pretty difficult to find an area of the background window’s title bar (near the left or right end) that does allow you to use command-clicking to move the window around.
It gets worse. Apple’s engineers have been so careless that they have actually failed to implement even this vary flawed approach itself properly. Consider what happens when you open a text clipping file. Command-clicking on the title of that text clipping’s window does bring up a pop-up menu with a path:
But now put this text clipping window in the background and try command-clicking on the background window’s title again:
Here, command-clicking on the title does… absolutely nothing. In other words, it fails to even bring up the pop-up menu with the path, even if that’s not really what the user wants. And it certainly fails to allow the user to use the background window’s title bar to drag the window around in the background.
You know, there was a time when we Mac users were really proud of the attention to detail in our operating system. We might have been a small minority, but at least we had an operating system that exuded quality through all its pores. And that quality made it worthwhile to stay in the minority and endure the direct or indirect abuse of the PC majority.
I am not saying that Mac OS X is not a quality operating system. But some degree of quality, some level of attention to detail has certainly been lost. Maybe I am nostalgic for a time that never existed. Maybe the classic Mac OS also had a number of long-standing bugs and design flaws that Apple’s engineers never bothered to fix. But I really don’t remember having to deal with so many simple flaws on a daily basis.