Mac OS X: The weird behaviours of Mail’s ‘Activity Viewer’ window
Posted by Pierre Igot in: MacintoshAugust 9th, 2004 • 4:29 am
Take a look at this Mac OS X window:
It’s Mail’s “Activity Viewer” window. Now take a look at this one:
It’s the “Find/Change” window in InDesign CS.
They are both what are called “utility windows” in Mac OS X.
The problem is that they don’t behave in the same way when it comes to closing them, even though they have the same visual appearance and the same close button in the top-left corner.
In InDesign CS, if you have a document window open and then this “Find/Change” window open on top of it, when you use the command-W keyboard shortcut, the application assumes that you want to close the document window, not the “Find/Change” window.
In Mac OS X’s Mail, on the other hand, if you use the command-W keyboard shortcut while the “Activity Viewer” window is in the foreground, Mail… closes the “Activity Viewer“.
I am not sure which behaviour is the correct one. The section about closing windows in the Apple Human Interface Guidelines doesn’t address this issue.
I suspect that the correct behaviour is the one in InDesign CS. After all, utility windows are used for palettes and things like that. They are not supposed to be part of the list of regular document windows.
What’s even stranger in Mail is what happens when you use the “Cycle Through Windows” command (which is not part of the menu interface but can be accessed using a keyboard shortcut, as in most Mac OS X applications). This command is supposed to be used to cycle through all available document windows.
In Mail, however, the “Activity Viewer” is treated, here again, as a document window and is part of the cycling-through-windows process. But since it’s not actually a document window, Mac OS X doesn’t really know whether it should switch the document window that is currently active to the background. So what does it do? Well, a bit of both. The background of the window’s title bar turns from the gray gradient used for active windows to the faded striped background that’s used for background windows, which is supposed to indicate that the window is now in the background. But at the same time, the three “gumdrop” buttons in the top-left corner of the title bar stay coloured and active, as if the window where still in the foreground!
So you get this hybrid window title bar status that seems to indicate that the window is both in the foreground and in the background at the same time:
Weird, uh?
I am afraid it’s a bad example of Apple not complying with its own interface guidelines that we have here. (And it’s not the only such problem in Mail: when you click on an item in the mailbox drawer on the side of the main Mail Viewer window, the item becomes highlighted, but only in the grey colour that’s indicative of a background selection. So effectively the mailbox drawer is never in the foreground, even though it’s active.)
August 9th, 2004 at Aug 09, 04 | 10:00 pm
René: Interesting link! Thanks… I certainly wasn’t aware that this was a new feature! I guess the key (ahem) problem here is why Apple chose to make the “Activity Viewer” window a key window if the only keyboard action it can respond to is
!
And you’re right, InDesign should probably use this feature to indicate which document window the “Find/Change” actions apply to. The question, however, is whether this hybrid status is available at all to developers in Carbon applications. In the Apple documentation, it’s filed under “Cocoa” :).
Then of course there is the issue of whether Adobe cares at all. Big software juggernauts like Adobe and Microsoft tend to be excruciatingly slow when it comes to adopting new features, especially when these new features appear to have a mostly “comestic” function (i.e. visually clarify something for the user). Such things are not their forte, let’s say.
Thanks again.
August 9th, 2004 at Aug 09, 04 | 7:18 am
Pierre,
I believe the “weird” appearance is actually a new feature in Panther. Mac OS X (or at least Cocoa) has always known two different window states, called “key” and “main”, but the “main” status was not visible in Jaguar. “Key” means that a window receives keyboard events, and “main” is usually the document the user is working on. The concept is explained in a bit more detail on an ADC page.
Imagine you have two documents and a Find window in TextEdit. Prior to 10.3, if the “Find” window was active, there was no visual indication as to which document your search would operate on. Internally, TextEdit knows the last selected text document because it still has “main” status. The only state that changes when you open the “Find” window is “key”. If you close the Find window, the document becomes both “key” and “main”.
Anyway, because the Activity window in Mail shows “key” state (by having a dark-gray gradient in its title), it is correct that it also accepts the Cmd-W shortcut. In my opinion, InDesign CS is wrong here. However, I think that the Activity window should not become “key” at all, because it does not contain anything that could be handled with the keyboard. (For an example of such a “never becomes key” window, see the OS X Character Palette.)
As for the mailbox drawer problem, I agree that this is quite annoying because it makes it impossible to change mailboxes with the keyboard. Maybe Apple will fix this in Tiger…
René