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.
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`.
There still appear to be crashes occurring when
using libgit2 from multiple workers at the same time.
So only start a new status worker once the current one
completes if a refresh was requested while a worker was
running.
Closes#367
This keeps the status-changed event from triggering
the first time the status is requested as it goes
from undefined to 0 which should be treated as no
change.
Now the status bar and tree view both listen for
status change events and use the cached information
available from the git object to update their views.
By default this will occur when the window gains
focus and the Git class can now be subscribed to
so listeners can become notified when the status
of a repository changes.