-
Notifications
You must be signed in to change notification settings - Fork 33.4k
Views should collapse downwards (fix #126523) #243558
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
/assign @benibenj who owns the issue this fixes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did not have a close look at the implementation yet, but I see there is a setting which is being added. I do not think we should add a setting for this. We should think about what the best possible behaviour is and make sure everyone uses that.
I'm wary of the fallout that typically arises when behaviour changes without it being an optional change. |
You are right, which is why we should only change the behaviour if we are actually improving it. But for smaller behavioural issues like this, we do not want to add a setting because these are very hard to discover and only a very small amount of users will benefit from it. |
I've often wished that we could make a change to behaviour behind a setting that defaults to "new way" for new installs of VS Code and to "old way" for existing users. Or better still, produce a little notification the first time an existing user experiences the new behaviour after the update that introduced it, giving them a chance to opt out of the change. In this case, collapsing a view the first time might notify "We now collapse views downward whenever possible. Do you want to revert to the old behavior of collapsing upwards?" In the absence of such a capability I'm OK to remove the setting on this change if doing that will increase its chances of being merged. |
I also wondered if Alt+click could offer the opposite behaviour. And maybe a tip on the button hinting at this. |
workbench.view.collapseDownwards
setting (fix #126523)
I gave this a try but I doesn't really feel better. See how when collapsing a view, the header moves away from the cursor so it's not possible to expand easily again. Also I think it should notice when the user resizes a view to not change the size of that view. I'm not sure how this could be solved without a overcomplicated solution. |
A similar thing already happens when expanding a view after having resized the one above it. And after I do move the mouse to reverse the expansion action it collapses upwards, so I have to drag the split downward again in order to reinstate the larger area of the view above (Explorer in this case). |
All cases mitigated by being able to use left-arrow key to collapse and right-arrow to expand instead of moving the mouse. |
This PR fixes #126523