Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Close some 'mini windows' via the keyboard System
One of the things that's bugged me for a while is that certain "mini windows" (such as the Font panel in Cocoa apps and the Finder's Show Inspector window) which have small close buttons don't respond to the Command-W command, but others (such as Terminal's Window Setttings panel) respond as expected.

However, I think I may have discovered the key thread linking them. Things in the first category can be closed by using the same keystoke used to open them. That is, after you hit Command-T to show the font panel, if you look in the menu bar, Command-T now says Hide instead of Show. The same is true for the Inspector; it now lists Hide as the action for the shortcut. So if you there's a menu option that shows a particular mini window, check the status of the menu when the window is active -- there's a chance it will now act to hide the window it just activated.

The Window Settings option in Terminal, however, has no shortcut, and therefore doesn't exhibit this hidden "hide" behavior. I personally think anything with a close button should just close if you hit Command-W and it's the frontmost window, so this is a little bit of a departure from a unified interface on Apple's part. However, anyone who finds counter examples from this behavior, please post below.

[robg adds: The behaviors are definitely inconsistent on Apple's part. I can, however, understand not just mapping Command-W to closing the frontmost window. In the Finder, for instance, you may wish to have the Inspector open while you're opening and closing multiple windows, so I understand the reasoning.]
    •    
  • Currently 1.00 / 5
  • 1
  • 2
  • 3
  • 4
  • 5
  (1 vote cast)
 
[7,160 views]  

Close some 'mini windows' via the keyboard | 5 comments | Create New Account
Click here to return to the 'Close some 'mini windows' via the keyboard' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Escape Key
Authored by: inspired_tmu on Jul 18, '05 11:36:51AM

Pressing the escape key sometimes closes these 'inspector panels', as they are often called.

Not true with all apps; the Finder's inspector, for example doesn't respond to the escape key. Blame it on Carbon 0:)



[ Reply to This | # ]
Close some 'mini windows' via the keyboard
Authored by: Lou Kash on Jul 18, '05 12:00:31PM

Finder:
open View Options = cmd-J
close View Options = cmd-J
open Get Info (floating) = cmd-opt-I
close Get Info (floating) = cmd-opt-I

Cocoa:
open Type panel = cmd-T
close Type panel = cmd-T
open Color Palette = cmd-shift-C
close Color Palette = cmd-shift-C

Mail (German):
open Activity Monitor = cmd-0 (zero)
close Activity Monitor = cmd-0 (zero)

iCal:
open Info window/drawer = cmd-I
close Info window/drawer = cmd-I

iPhoto:
open Info palette = cmd-I
close Info palette = KLICK THE RED BUTTON... ;)

That's in Panther. I don't know about Tiger.



[ Reply to This | # ]
Close some 'mini windows' via the keyboard
Authored by: GaelicWizard on Jul 19, '05 01:27:52AM

The reason that these panels do not respond to Cmd-W, IIRC, is because they are *NOT* the frontmost window. Try clicking explicitly on the title bar once or twice and you'll find that it hightlights (i.e. becomes metal in Tiger). At this point, either ESC or Cmd-W should close it.

The idea is that an Inspector window is complementary to another window, not a window in itself. Hence, it does not receive focus when activated.

YMMV,
JP

---
Pell



[ Reply to This | # ]
Close some 'mini windows' via the keyboard
Authored by: codeman38 on Aug 04, '05 09:41:06AM
That may be true for some cases, but it's definitely not true in the Info and View Options panels in the Finder.

[ Reply to This | # ]
These are called palettes and have always worked that way
Authored by: VRic on Jul 19, '05 11:47:52AM

This hasn't changed since long before Mac OS X, maybe even from the very beginning. What changed is the amount of inconsistencies in Apple's own products.

Palettes are not windows (unless you consider them in the technical/unix way, in which case even menus are windows). They hide when their parent application isn't frontmost because they're supposedly useless then (at least they should, otherwise the developer shouldn't have used palettes) and they don't respond to windows' closing kb shortcut because they don't belong to the windows layering, which makes a "close front window" shortcut irrelevant to them since none is frontmost (technically they are of course layered, but there's no way to tell which of 2 palettes is in front unless they happen to overlap).

These were proper, consistent and well thought-through innovations: otherwise either there would be no way to pull a document window to the front in Photoshop or it would then mask the palettes, you couldn't close the document without tedious shifting or you'd have to first close palettes even though you'll want them next time, etc. Other environments lacked palettes, and they were a mess.

This doesn't mean there aren't any inconsistencies, because controls are used by developers like they want and developers don't always know what they're doing. Old mac users constantly spot errors showing that current Apple developers know so little of the work of their predecessors that they don't understand much of the Mac UI past the most obvious ideas that casual users can grasp.

This probably contributed to them adding to the confusion by making palettes so similar to windows (one didn't mistake palettes for "mini windows" when the 2 kinds sported very different title bar patterns and were used consistently, before OSX).



[ Reply to This | # ]