search

microsoft / vscode

Visual Studio Code
https://code.visualstudio.com
MIT License
164.21k stars 29.29k forks source link

Make it easier to resize panes without having to click on sashes #16533

Closed sam-n-johnston closed 6 years ago

sam-n-johnston commented 7 years ago

This is a feature request: On Ubuntu, you can easily resize any window by holding down alt, center click the mouse and drag. The window resize based on which of the corners or sides is closest. (You can test the functionality in windows with AltDrag). This makes resizing windows SO fast, you don't have to "aim" for a precise edge of the window, you just go very approximately and it will resize like you want. This is a huge help when you want to have multiple windows open on a single page.

So, the feature I would like to have is to be able to resize the panes more quickly than I can now. When I'm working with 2 or especially 3 panes opened, I find myself resizing the panes often. I want to see more of the code I'm working on currently, but I like to keep the other panes there for the references to functions/tests/etc I'm calling. When I'm finished working on that file, I resize the panes and start working in another pane. If I could hold alt, center click my mouse close to a pane edge to resize the panes, (or something similar) it would save me a lot of time.

Thanks!

bpasero commented 7 years ago

@sam-n-johnston how about "Minimize other editor groups" from the command palette and when you click to other editors they automatically maximize and minimize the others?

bpasero commented 7 years ago

untitled

sam-n-johnston commented 7 years ago

This doesn't really solve it. I have trouble using the minimized editor groups because I can see too little of the code. Personally, I need a bit more than twice the width of the minimized window to be able to see a useful amount of code (even with shft+scroll, it doesn't cut it). So it's essentially the same as having them all in one group and ctrl-tab it. My eyes have to jump and re-adapt to the new code that's being displayed when one is expanded, the same as when I change with ctrl-tab.

bpasero commented 7 years ago

If I could hold alt, center click my mouse close to a pane edge to resize the panes, (or something similar) it would save me a lot of time.

Can you explain more how this would work or help in your case?

sam-n-johnston commented 7 years ago

Here's a rough example of how I use my screen real-estate. It allows me to comfortably code on two windows and having a third pretty big one for viewing.

missing mark

In this screenshot, I was trying to resize the pane for example, and (this happens to me often), I accidentally added a debug break point. I usually don't like to have to be this precise with the mouse cursor for actions I find myself doing often. For example, when closing a tab, I prefer to center click anywhere on the tab rather than hit that tiny "x". If there were a really quick way to resize panes, I would find myself doing it much more often.

(This is just how Ubuntu does it, it could be another way) So instead, you could hold alt, center click drag in the red regions and it would resize the pane. No need to be really precise, yet you can resize the panes at will really quickly

regions

bpasero commented 7 years ago

@sam-n-johnston ok I see so basically a way to turn into a mode where you can resize panes without interacting with the editor at all. Would it help to have keybindings that allow for resizing in increments maybe be a better approach?

sam-n-johnston commented 7 years ago

Yeah, that could work. For example, key bindings to increase the size of pane #x by y%, while the other panes will reduce to accommodate (but not the explorer/folder pane, as it is usually fixed).

Tough this would make resizing the bottom pane and left pane hard/weird no? You would need a key-binding to make it enlarge and another one to make it smaller.

When I'm debugging for example and I need to see the value of an object, I usually augment the size of the debug pane, but when I'm in my explorer/folder view, I want it as small as possible usually. I do the same thing when running unit tests in the terminal view (big when running tests, small when normal console). So were getting at like 7 key-bindings to control the width of the panes if you have 3 opened (1 for each editing pane, 2 for the folder pane and 2 for the terminal/bottom pane).

Maybe I'm not seeing another type of key-bindings that could do the job better?

cleidigh commented 7 years ago

Contribution volunteer...

Development Environment:

OS: Windows 7 Professional SP1 (VM under OSX) Python: ActiveState 2.7.5

Visual Studio 15 Community \ C++ Tools \ SDK 8.1 VS Code: 1.10.1 (Code OSS Build environment) VS Code Insiders 1.10.0 2-27 build: (Test environment) VS Code: master clone 2-28 and 3-1 development tests (including sidebar resize implementation)

Node: 6.9.1 NPM: 3.10.8

Disabled/Voice Programming Environment:

Dragon Individual Professional 14 (voice\ dictation platform) NatLink COM Python/Dragon ExtensionApi Dragonfly grammar library ExtensionApi VSC UserSnippets and user extensibility extensions

@bpasero (I infer from post that you deal with these issues mostly workbench keyboard et cetera) @Tyriar (you have an issue with contrasts on UI elements - I'm also experimenting on this) @joaomoreno (you fielded my first bug fix submittal - all of two double quotes ;-)

I have been setting myself up for contributions over the last couple of weeks. this is an issue that I was already starting to work on before seeing someone else's issue post. I'm very interested in contributing especially on accessibility issues. I am disabled with ALS ,however I am fortunate enough to still have my voice. therefore my user method is entirely voice programming. Before ALS I worked in software firmware and hardware development for over thirty five years... right now VSC code is one of the main reasons I can still do some work. it's the most accessibility friendly editor I found (just recently in fact).

I already have a base working implementation for sidebar resize I would like to pull and submit. I based my implementation as best I could on the models existing in code such as togglesidebarvisibility. they are basic methods extendable to the panel part as well. I allow layout to do the math and other part management. I am sure I may need some architecture adjustments to conform with the rest of the code.

As a voice programming user unfortunately sash control, scrollbars or any control icons are terribly difficult to use they require many mouse grid voice commands to zoom in. keyboard control is everything, as long as there are shortcuts (ideally better than tap stops) it's possible to make decent voice commands , even compound commands.

I'm also looking at contributing for some UX issues like button control and color contrast. I'd like to help make VSC the most accessible program possible !

For sidebar and panel resizing what should my next step be? Just fork clone and pull?

Cheers Christopher

bpasero commented 7 years ago

@cleidigh thanks for your interest in helping out and we are happy to hear that you can use VS Code 👍 . I think continuing via a pull request would be the best thing to do :-).

Maybe we could also first discuss what you are planning to work on specifically. We also have a number of requests for being able to resize a sash (the divider between editors and sidebar and panel) using just the keyboard.

cleidigh commented 7 years ago

Absolutely agree about plan first.

Besides making sure the architecture is correct, I think there's some related issues such as the sashes you mention. also issue #21669 for navigation commands around the workbench is related because decisions there in terms of focus and keyboard shortcuts should jive.

I promise I'll do my best to RTFM and do code inspection before peppering you guys with questions... but in the beginning some will be necessary:

can you define exactly what the sash regions/functionality are? I know I can use the mouse to drag a border and change the size of a workbench part. I also saw you added the double-click on sash to size to minimum the sidebar. what do you mean by expanding the sash size? increasing the active click window?

Here are the things I thought I would start with:

Here are the things I learned/thought of as relevant issues:

For future work (keyboard scrolling, css/UI accessibility improvements) Do I include these in the pull request?

would you like a summary/set of file changes of my prototype to comment on/tear apart ;-)

ready to get started...

bpasero commented 7 years ago

@cleidigh very good questions. my initial reaction to being able to resize the sash via keybinding is that maybe there is a global command to let the sashes show up as elements you can navigate to when you press the tab key? And then when you tab through all the sashes that are visible you can use the arrow left / arrow right key to move them for resizing? We could expand this to let Enter behave like double click on the sash.

Something like this:

I just realize that this might be hard to implement because in order for the sashes to get keyboard focus they would need a tabindex=0 property, but then tabbing around you would actually tab to all the other elements that have this property (quite a bit). Alternatively we could have a global command "Resize sidebar" and this one would just show some affordance to make the side bar resizable using arrow keys. Maybe that is easier.

cleidigh commented 7 years ago

@bpasero

To be fair I reread the original post, @sam-n-johnston is asking for an improvement in sash panel resizing. His proposed solution from Ubuntu sounds good and could just be an expansion on the sash target with alt key.

this does not address the inability of a keyboard only approach (currently a keyboard only user cannot do any panel resize) Bottom line - these are two different UX problems or issues.

I assert that all parts are not equal, editor is paramount sidebar and panel deserve resize predominantly when either as focus If one is editing it's easy to toggle them off or contract with this added functionality...

I propose the following:

Potential Future Issues:

cleidigh commented 7 years ago

couple of corrections...

bpasero commented 7 years ago

@cleidigh I like the idea of making these commands work on the currently focused part, that is a very elegant solution! I also agree that it makes it easier to just have commands for expand and shrink, should also make your life easier in the pull request :-).

cleidigh commented 7 years ago

@bpasero I have been working on more code familiarization, found a bug in SCM and work to better understand code. I have a fork and a new branch ready to go and start.

I have been looking at @misoguy navigation feature , as well as your comments and others for reference.

couple of questions:

bpasero commented 7 years ago

I think talking in this issue is fine 👍 . You can start the PR anytime you like. I am not sure about the size change needed to be user configurable, I would first maybe start without it. Having this inside the actions.ts file is probably ok to begin with.

In the end, WorkbenchLayout is the owner of the resize sashes (that is how we call them, see Sash) between sidebar and editor and panel and editor. Then, EditorGroupsControl is the owner of the sashes for the editors. Have you thought about how to programmatically change the sash sizes in these 2 areas?

cleidigh commented 7 years ago

@bpasero should I make a new issue that is keyboard centric or do the PR on this issue.

I will give you an overview of my current partial implementation. right now I am struggling with development/debugger repository issues I just posted an issue on that, it's preventing me from doing forward progress

bpasero commented 7 years ago

@cleidigh I just created https://github.com/Microsoft/vscode/issues/22645, it is more specific towards your scenario.

isidorn commented 6 years ago

I think the work @cleidigh did with increasing focused view size does the trick for now. So closing this one as we are not planning any action around this in the next 12 months.