Mac OS X: Can’t command-click on background window title to move it

Posted by Pierre Igot in: Macintosh
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:

Command-click on window title

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:

Address Book Window Title

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:

Command-clicking on AB window title in BG

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:

  1. 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.
  2. 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.
  3. 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:

Command-clicking on title of text clipping window

But now put this text clipping window in the background and try command-clicking on the background window’s title again:

Command-clicking on title of text clipping window in background

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.


6 Responses to “Mac OS X: Can’t command-click on background window title to move it”

  1. danridley says:

    For me, this is something of such low importance that it doesn’t bother me in the slightest. But as long as you’re ranting: shouldn’t you be able to command-drag background metal windows by any blank metal area, rather than just by the title bar, given that you can move them by any blank metal area when they’re in the foreground? And especially since there’s no visual indicator of where the title bar ends? And especially since you can background-command-drag Unified windows by their toolbar?

    Also, you can command-drag by the window title in at least the following applications: iTunes, Mail, Calculator, Terminal. Visually, it looks like windows that have an icon next to the title in the title bar are the ones that don’t let you do so.

  2. Pierre Igot says:

    If you rarely use command-dragging to move windows in the background, then I suppose it is indeed something of “low importance.” But if you do use command-dragging, then it is not unimportant. I want to stress that Apple responded to my bug report on this within a couple of days, giving me the standard “Engineering is aware of this and working on a solution” reply—which doesn’t commit to any kind of time line for fixing the problem. But at least I can say that they are aware of it, and presumably this means that they don’t consider it completely unimportant :).

    That said, you are right that the problem goes far beyond just the issue of what happens when command-dragging on the window title. There are all kinds of inconsistencies. For example, you can click on the blank metal area of the Finder toolbar to move the window around, but command-clicking on it when the window is in the background… brings the window to the foreground. Argh.

    I tend to wrote posts about single, clearly identifiable and reproducible issues, even if they are part of a more general “cluster” of bugs and flaws. This is because that is the way that Apple likes bug reports. The more specific and reproducible it is, the better chance they will acknowledge and fix the bug. General rants about clusters of interface flaws are not nearly as effective.

  3. danridley says:

    I’m just curious, and I don’t mean to sound rude or dismissive, but what on Earth is the working model that makes you need to frequently reposition background windows?

    I’ll shove a window to the bottom of the screen that contains hostnames or passwords that apply to a virtual machine or remote control session where I can’t use copy and paste due to software limitations; and I can imagine scenarios where one would need to reposition a window to keep a playing video or iChat session on top while bringing something below into a visible space. But I also suspect I’d need this functionality even less if I weren’t using a single 13.1″ screen most of the time. So I’m curious why this is a frequent need for you.

    Again, I’m not trying to say you “shouldn’t” need/use this or anything, I’m just curious because I don’t get it.

  4. Pierre Igot says:

    Dan: There are numerous situations where I need to move windows around and I don’t want to have to switch to the corresponding application, because I don’t want to lose the current focus.

    It’s not really possible to provide you with a detailed account of each and every type of scenario where the need to move background windows arises. But I frequently need to drag things (files, text, etc.) from window to window, and I often have to get to windows that are half-hidden. Or I am working on a project that requires me to keep an eye on several windows at the same time, so the background windows need to be fully visible even if they are in the background.

    I have two large screens (30″ + 23″) and I tend to have many windows open at any given time: multiple Finder windows, multiple Safari windows, multiple Word and Pages windows, multiple Mail windows, etc.

    Maybe the new “Spaces” feature in 10.5 will help me manage this better, but at this point, in 10.4, I still find myself having to frequently move windows around. (When you have dozens of windows open, the Exposé features become rather useless, and they are mostly designed for switching anyway.)

    We all have different ways of using our computers. That’s the beauty of it. Surely the very fact that Apple “invented” this command-dragging for background windows in the first place is an indication that I am far from being the only one who needs this. The problem is not with the importance of the feature itself. It is with its poor implementation in the current incarnation of Mac OS X.

  5. danridley says:

    It’s just that this feature had always struck me as a small-screen feature — when you have to jiggle things around to compensate for not really having enough room to work. I don’t think I’ve ever used it when I had my second monitor attached. That’s the reason I was surprised and curious about your usage, as I knew you have a fair bit of screen space to work with.

  6. Pierre Igot says:

    I am afraid one really can’t have too much screen space to work with, at least not as far as I am concerned. Like I said, at any given time, I usually have dozens of windows open in my OS X environment. That’s more than enough to fill my two screens and regularly forces me to readjust the position/size of my windows.

Leave a Reply

Comments are closed.