This causes the active item to change in the model before the associated
view can be added, which causes problems with the ReactEditorView having
methods called on it before its afterAttach hook creates the component.
We call Pane::activate subsequently unless activation is suppressed,
which will focus the pane anyway, so this was redundant.
We always want to preserve at least one pane, so we don't call destroy
on the pane if it is the last pane. However, we still want to destroy
its items. This was previously relying on the view to destroy the
underlying item, which isn't as reliable as doing it in the model.
This was previously throwing an error when Workspace::open was called
with a split: right option and the rightmost sibling was a PaneAxis
since it was assuming findOrCreateRightmostSibling was always returning
a Pane, not a PaneAxis.
If the active item was the pane's first item, the second item (which is
the new first item) is activated. Otherwise, the item to the left of the
closed item is activated.
These methods set the *active* item, so the verb activate provides a
clearer correspondence. We could change the noun to "shown" item, but
that's awkward and having both active panes and active items is a nice
correspondence in terminology.
We don't actually need structural markup to ensure that all pane views
are absolutely positioned. We can just use the `> *` selector inside of
.pane-items.
/cc @probablycorey is there anything I'm missing here?
Previously, when you always had to specify the event name of 'value'
when calling `::subscribe` with a signal. Now, if you don't specify an
event name, 'value' is assumed.
The .item-views div needs to be the first child of pane and contain
the absolutely positioned repaint hack div inside it, otherwise the tabs
don't get honored as flexbox items.
It's a bit tricky… we don't want to blur the model when focusing the
pane's active view causes a focusout event on the pane, so we use
::suppressBlur on the model to prevent it from blurring as the focus
is transferred.
