Moving an item that extended the jQuery object between panes
was previously wiping out all jQuery data since remove() was being
called on the view item instead of detach().
Previously, removing the last pane item also ruined our ability to
determine if the pane had focus. Now, if we're removing the last item,
we instead just go ahead and remove the entire pane. Remove contains
logic to switch focus to the next pane if its active view is focused,
which works as intended if we leave the active view in place.
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.
This event is triggered when the item changes on the active pane, or
when a different pane becomes active.
Also: Pane now sets itself as the active pane, rather than letting
PaneContainer handle the focusin event.
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.
When a pane is split, it attempts to make a copy of its current item
if no items are passed to the split method. When splitting, multiple
items can also be passed to the constructor of the new pane.
As a consequence of these changes, editors will no longer need to
listen for destruction of their edit sessions. An editor will
eventually only ever be displaying a single edit session, and the
editor will destroy that edit session when it is removed. Panes
will be responsible for supporting multiple edit sessions, and
they will automatically remove the editor when they have no more
edit session items.
The problem I've been struggling with is that we need to potentially
assign tabs both to EditSessions and also to other views added by
extensions, like a markdown preview view. EditSessions are however not
actually views… instead they plug into editors. The solution is to
have the pane ask a model object what view should be used to render
it. When asked to show a non-view item, the pane constructs and
appends a view for that item or recycles an appropriate view that it
has already appended.