Improvement suggestion: toggle panes with some key binding.

[ubaldot]

My custom layout is the following:

However, during my latest project I noticed a couple of things

• I change the windows focus very often, especially between the two editor splits and sometimes I have to go to area that contains the various panes on the right-hand side. This requires me to take the mouse for changing focus very often and I get very tired.
• Sometimes I just want to have the two editor windows side-by-side to cover all the screen without anything else, otherwise the text is very tight and I may need to scroll horizontally to read the code, in-spite I have the 80 columns limit set with black.

Therefore, I was wondering if it is possible to add some key binding to hide/unhide the right hand side of the screen, see picture below.

Or, more generally, I am wondering if it is possible to add some key-bindings like:

• F1 hide/unhide Project pane
• F2 hide/unhide IPython terminal
• F3 hide/unhide Outline
• F4 hide/unhide Variable Explorer
• ...
  ...or something similar plus some another keyboard shortcut to jump from one editor split to another split (if you are familiar with Vim I am thinking about a <c-w>w command).
  In this way one would only have two editor's view side-by-side (which is quite common) in a very clean way and don't have to switch between keyboard and mouse too often.

[CAM-Gerlach]

Ctrl-Shift-Alt-M maximizes the current pane, which seems to basically be what you want. The only problem is the outline pane is considered part of the Editor and maximized too. @ccordoba12 how hard would that be to change? Is there any reason not to do so?

[ubaldot]

Hum, not really. I just tried it this morning and it won’t maximize the editor. :/

[CAM-Gerlach]

Right; as mentioned above, it coincidentally happens that the one pane that in the custom layout you have, the Outline, is the one pane that will get maximized along with the Editor if its open, and the UI will look exactly like you showed in your screenshot. Also, I might have changed the default shortcut on my end; you can select View -> Maximize current pane to ensure you're actually activating it. What I'm proposing is us not maximizing the outline pane along with the editor, which would get you what you want. However, I'm not entirely sure if there's a concrete reason for it other than the Outline pane historically being part of the Editor (which I think should no longer be the case now with the new plugin system), which is why I asked @ccordoba12 about it.

[ubaldot]

I was also thinking that a "quick and dirty" solution would be set the minimum width of the right hand side section, where the panes are arranged as tabs, to zero.
At the moment, if a user drags the boundary towards right, then it will be limited to a fairly large width, i.e. then it won't shrink more than the amount that you can see in the picture below.

[ccordoba12]

Or, more generally, I am wondering if it is possible to add some key-bindings like

We already have keyboard shortcuts that show a pane if it's hidden and give it focus if it's visible (e.g. Ctrl+Shift+E for the Editor, Ctrl+Shift+V for the Variable Explorer, etc). So my suggestion would be to add a single shortcut to quickly close a pane (e.g. Alt+Shift+C). That way users wouldn't need to learn a whole new set of shortcuts for this.

What do you think?

The only problem is the outline pane is considered part of the Editor and maximized too. @ccordoba12 how hard would that be to change?

Is not that hard, actually.

Is there any reason not to do so?

Historical reasons mainly, i.e. that's how Pierre (the original Spyder's author) decided to implement the maximized view for the editor. However, I agree that having the Outline is useful. The thing is we must not enforce it and that's harder to implement.

I was also thinking that a "quick and dirty" solution would be set the minimum width of the right hand side section, where the panes are arranged as tabs, to zero.

That's technically not possible because some widgets require a minimal size. However, we could hide whole areas in the interface, at least according to this:

https://forum.qt.io/topic/24211/how-to-show-hide-a-whole-docking-area/3

So we could add shortcuts to do that.

[ubaldot]

Many thanks for the answers guys!

However, we could hide whole areas in the interface,

This!
This would be THE solution!
To hide/unhide the whole block on the right hand side of my previous pictures. 🙂

[ubaldot]

Follow-up: is this included in any roadmap?

Giving that I am here, and after having experienced (and solved!) many issues thanks to your suggestions, I could summarize a a couple of refined requests as it follows:

1. The user shall be able to hide/unhide portions of the screen (for example left and right according to the picture below) such that when the area is hidden it collapses in a thin stripe with few clickable icons (think e.g. to VS Code vertical stripe on the left hand side of the gui).

2. It would be handy to have a key-binding to switch focus from one editor view to another as well, i.e. say that I have two splits like in the picture below, I would like to jump from one editor view to the other (or to rotate between them in case you have many editor views opened) just by using the keyboard. Also, it should be allowed to close the most left editor view as well (at the moment the option "close this panel Alt+Shift+W" is greyed out in the left editor view).

What do you think?

[ccordoba12]

The user shall be able to hide/unhide portions of the screen (for example left and right according to the picture below)

That's an interesting idea but not easy to implement at all.

It would be handy to have a key-binding to switch focus from one editor view to another as well

That's interesting too but what I don't know what set of shortcuts we should use and in what order we should assign them.

Also, it should be allowed to close the most left editor view as well (at the moment the option "close this panel Alt+Shift+W" is greyed out in the left editor view)

There's always a "root" or "parent" editor and that's the one that can't be closed.

[CAM-Gerlach]

That's interesting too but what I don't know what set of shortcuts we should use and in what order we should assign them.

I definitely like that idea, as I've often found situations where having it would be useful.

As for UI, I'd suggest making it behave like Ctrl-Tab, Alt/Cmd-Tab, etc and just have it toggle between panels in some order, ideally MRU but it wouldn't be necessarily required for an initial implementation, since in the most common two-panel case it wouldn't matter.

As such, Ctrl-Alt-Tab (and adding Shift to reverse the direction, if needed, by extension with Ctrl-Tab, Alt/Cmd-Tab, etc) seems to be a reasonable choice for a shortcut.