Panes act as the on-screen roots for all visible view hierarchies. If you want to show a view, that view must be placed directly or indirectly inside of a pane, and the pane itself appended in your SproutCore application by calling the append() method.
Every SproutCore application should have a "main" pane added in its main() function. The easiest way to create a "main" pane is to use the SC.MainPane class. SproutCore only allows one "main" pane to exist in the DOM at any time; if you try to append another "main" pane, any existing "main" pane will be removed automatically.
In addition to the "main" pane, you can append() an unlimited number of non-main panes. These panes may be eligible to become "key" pane, which gives them (and the views inside them) first priority in handling keyboard events. For example, SC.Alert is a pane subclass that when shown, becomes the key pane. This allows it to capture the "Enter" and "ESC" keyboard commands, which it routes to the default button and the cancel button, respectively.
If a keyboard event is not handled by the "key" pane, SproutCore will automatically give the "main" pane a chance to handle the event as a "key equivalent" (i.e. a command key such as Ctrl+N). Keyboard events that are not "key equivalents" are not routed to the main pane (unless, of course, the main pane is also the key pane).
All panes, regardless of "main" or "key" status, are siblings in the DOM and children of the <body> tag.
SC.Pane is the root of the pane hierarchy, and is a direct subclass of SC.View. Thus, all methods defined in SC.View apply (more or less) to panes. You will rarely create instances of SC.Pane, though you can if needed. The class is not "abstract". Note: as the root of a view hierarchy, a pane will never have a parentView; pane.get('parentView') always returns "null".
SC.MainPane adds a small amount of code to turn an SC.Pane instance into a pane with "main" status. You should use this class to root the view hierarchy for the "main" pane you want to show at startup.
SC.Panel implements modal panes -- panes that must be interacted with (or dismissed) before any other mouse events are handled by the application. This functionality is very useful for modal dialogs (SC.Alert), modal "sheets" (SC.Sheet), context-sensitive dialogs (SC.Picker), and menus (SC.Menu).
SC.Alert contains a number of specialized class methods to create and show a modal alert in a single call. SC.Alert provides a more consistent user experience than the built-in alert() and confirm() functions provided by JavaScript.
SC.Sheet can be used anywhere an SC.Alert is used, but where a more complex modal dialog is required.
SC.Picker is a powerful panel class that implements context-sensitive, inline, modal dialogs -- nearly always anchored around some view that is being edited or manipulated. Pickers contain a myriad of configuration options to specify their "preferred" layout and will automatically reposition themselves onscreen as the browser window is resized. The preferred layout is specified by the preferMatrix parameter in the SC.PickerPane instance's popup() function. This parameter is an array of the four anchor sides in order of preference from highest to lowest terminated by a fallback anchor side. The anchor sides are defined by their index in SC.POINTER_LAYOUT, where perfectRight is 0, perfectLeft is 1, perfectTop is 2 and perfectBottom is 3.
For example, the preferMatrix, [3,0,1,2,2], is analogous to [perfectBottom, perfectRight, perfectLeft, perfectTop, top]. The interpretation of this particular preferMatrix would be "appear at the bottom of the anchor, if there isn't enough space at the bottom then appear to the right of the anchor, if there isn't space to the right then appear to the left, if there isn't space to the left then appear at the top of the anchor and if that fails and there isn't enough space on any side then just appear at the top".
SC.Menu is a kind of picker and configures itself automatically when shown. Because menus are inline modal, anchored to a specific view, and require complex positioning onscreen to display properly, they make an ideal subclass for SC.Picker.
Unlike SC.Panel, SC.Palette does not prevent mouse handling outside of its visible views. Thus, palettes are useful anywhere a persistent helper window would be used in a Mac or Windows application. Examples include: floating toolbars and formatting palettes, temporary notifications (Growl), and inspectors. Palettes can be repositioned onscreen by dragging on their background.