This fixes#16769, which described an issue whereby trying to drop into
a closed dock would cause the dock to repeatedly open and close.
I tried to describe in comments why this was happening and how we can
make sure to avoid it.
The solution adds another DOM measurement which I'm not too thrilled
about but I profiled and it didn't seem to be an issue.
* Add custom properties to atom-workspace
These track the editor's current font size, font family, and line
height.
* Move editor styles to text-editor; add monospace fallback
* Add default font family
So that there will always be a valid value.
* Fix specs
Previously, we would assign dock elements a minimum width/height of 2
pixels so that we could detect when the mouse approached the edge of a
hidden dock in order to show the chevron buttons. This, however, was
causing confusion for users, who expected that extra space to be
clickable in order to scroll editors located in the center dock.
With this commit we will instead register a global `mousemove` event on
the window right when attaching the workspace element to the DOM (the
event handler is debounced, so this shouldn't have any performance
consequence). Then, when mouse moves, we will programmatically detect
when it is approaching to the edge of a dock and show the chevron button
accordingly. This allows us to remove the `min-width` property from the
dock container element, which eliminates the confusing behavior
described above.
Prior to this change, the following commands successfully move between
panes in the workspace center, but they could not move between the the
panes in the workspace center and panes in the docks:
- window:focus-pane-above
- window:focus-pane-below
- window:focus-pane-on-left
- window:focus-pane-on-right
- window:move-active-item-to-pane-above
- window:move-active-item-to-pane-below
- window:move-active-item-to-pane-on-left
- window:move-active-item-to-pane-on-right
- window:copy-active-item-to-pane-above
- window:copy-active-item-to-pane-below
- window:copy-active-item-to-pane-on-left
- window:copy-active-item-to-pane-on-right
This commit updates these commands to work across all visible panes,
regardless of whether the pane is in the workspace center or a dock.
Summary of approach:
- Add tests for the `nearestVisiblePaneInDirection`, which provides the
core logic for the higher-level methods like `focusPaneViewAbove`,
`moveActiveItemToPaneAbove`, `focusPaneViewOnLeft`, etc.
- Test the generic logic extensively (i.e., the logic that is
independent of whether the given pane resides in the workspace
center or a dock)
- Also test the navigation between docks and the workspace center
- Since the core logic is tested in the new tests above, simplify the
tests for the higher-level methods (e.g., `focusPaneViewAbove`,
`moveActiveItemToPaneAbove`, `focusPaneViewOnLeft`) to avoid
unnecessary duplication.
- Add `nearestVisiblePaneInDirection` to `WorkspaceElement`, implemented
in terms of the existing `nearestPaneInDirection` method on
`PaneContainerElement` for now.
* master: (43 commits)
If one arch fails, kill the other for perf on appveyor
⬆️ dalek@0.2.1
Revert "⬆️ all packages that use atom-select-list"
⬆️ atom-keymap
⬆️ status-bar
⬆️ all packages that use atom-select-list
⬆️language-ruby@0.71.0
⬆️autocomplete-css@0.16.1
Ensure `packagesCache` exists before accessing it
🎨⬆️ less-cache
Use `core/` instead of `<embedded>` for keymaps loaded during snapshot
Set also defaultSettings.core.projectHome when initializing Config
Fix tests
⬆️ atom-keymap
Replace CommandRegistry.addBundled with a boolean param in .add
Delete unused build scripts
🔥 Remove parserlib
Resolve style sheets paths during `script/build` for bundled packages
Don't use cached less sources and imported files in dev mode
...
