Previously, package specs needed to deactivate the root view to test
their package serialization. Now, specs can just deactivate and then
reactivate the package, relying on serialization infrastructure that's
independent of the lifecycle of the RootView.
Panes now trigger an event every time their active item changes,
regardless of whether the pane itself is active. Panes also trigger
events when the become active and when they are removed. The rootView
now scopes its active-item-changed event listener only to active panes,
and also listens to listens to pane activation and removal events to
update the title when switching active panes and removing the last
pane.
PaneContainer is responsible for all pane-related logic. Laying them
out, switching focus between them, etc. This should help make RootView
simpler and keep pane-layout related tests in their own focused area.
Since this is the more external method, having a shorter name
is more convenient. The former `buildEditSession` method took a
Buffer, and is now called `buildEditSessionForBuffer`.
In additional, rename `registerViewClass(es)` to `registerDeserializer(s)`.
This moves us to a situation where any kind of object may want to be
deserialized, not just views.
Allowing root view to be focused was stealing focus away from the
editor whenever a click event made it to the root view. This unnecessary
switching of focus was interfering with the ability to drag tabs.
But if RootView can't be focused, focus ends up being returned to the
document body when there are no focusable elements. This would be fine,
except for the fact that we frequently bind global events on root view,
and so they aren't triggered when events are triggered on the body. We
could just bind all global events on the body, but this would require
us to always attach elements to the DOM during specs, which is a serious
performance killer in specs.
The workaround is in the keymap. When the keymap handles a key event
that was triggered on the body, it triggers the corresponding semantic
event on the root view anyway, so from the event perspective, it's as
if the root view actually had focus. The only place this might fall
down is if someone wants to capture raw key events. But that's the
keymap's job anyway, and we maybe add a hook on the keymap if such a
need ever arises.
Previously we were relying on the package module itself to have a
`name` field. But now that we're using `atom.loadPackage` to load up
packages, we can infer the name of the module from the name of the
package directory.
