feat(edge-groups): expose isAutoHide() and toggle auto-hide from the demo context menu - #1537
Merged
Merged
Conversation
…demo context menu `DockviewGroupPanelApi.setAutoHide` had no matching getter, so nothing could read back whether an edge group auto-hides. Add `isAutoHide()`, delegating to the existing `DockviewComponent.isEdgeGroupAutoHide` resolution (per-group override, falling back to the `autoHideEdgeGroups` option for that edge). Use it in the demo: right-clicking a tab in an edge group now shows a checkable "Auto-hide edge" row in place of Float / Popout, which neither apply to an edge group. It is one toggling item rather than an on/off pair because every edge group in the demo starts auto-hiding, so in a pair the ticked row is the one you would reach for first and clicking it would do nothing. Turning auto-hide off also expands the group. A collapsed edge group loses its click-to-peek trigger along with auto-hide and its sash is locked at the collapsed size, so without this it would be left as a strip with no way to open it. Documented on the edge groups page for anyone calling `setAutoHide(false)` directly. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.



Right-clicking a tab in an edge group in the demo now offers a checkable Auto-hide edge row, flipping that edge between a pinnable tool window and a static docked panel while the dock runs.
Core
DockviewGroupPanelApi.setAutoHidehad no matching getter, so nothing could read back whether an edge group auto-hides. This addsisAutoHide(), alongside the existingisCollapsed()/isPeeking():The resolution logic is not new. It delegates to
DockviewComponent.isEdgeGroupAutoHide, which was already there: the per-group override if one is set, otherwise theautoHideEdgeGroupsoption for that edge. Returnsfalsefor non-edge groups and before the group is initialised.Demo
The new row takes the slot held by Float / Popout, neither of which apply to an edge group. Grid groups are unchanged.
It is one toggling item rather than an on/off pair. Every edge group in the demo starts auto-hiding, so in a radio pair the ticked row is the one you would reach for first, and clicking it would do nothing.
Turning auto-hide off also calls
expand(). A collapsed edge group loses its click-to-peek trigger along with auto-hide, and its sash is locked at the collapsed size, so without this it is left as a strip with no way to open it. That trap applies to anyone callingsetAutoHide(false)directly, so it is called out on the edge groups docs page too.Testing
dockviewGroupPanelApi.spec.ts(uninitialised returnsfalsewithout touching the accessor; initialised delegates toisEdgeGroupAutoHide). Full spec passes, 53 tests.Noted, not fixed
The tab context menu can render below the viewport for bottom-edge tabs. The menu is in the DOM but positioned off-screen, so nothing appears. It flips upward correctly in some layouts but not others. Pre-existing context-menu positioning, untouched here.
🤖 Generated with Claude Code