Notebook pane grouped in upper right after changing layout

[ikeszvpvb9ye]

Spyder 4.1.2 the dock panel of the Notebook panel is automatically in the right panel if you select View -> Windows layout -> Spyder Default Layout

What steps will reproduce the problem?

Continuing the task #245

1. Install Anaconda, Spyder4.1.2 and Notebook
2. Enable Notebook pane through the menu View -> Panes -> Notebook.
3. We observe the Notebook pane in the pane group on the left, it is grouped with the python script pane
4. Select the menu View -> Windows layout -> Spyder Default Layout
5. Enable Notebook pane through the menu View -> Panes -> Notebook
6. We observe Notebook pane in the pane group on the right, it is grouped with Variable Explorer, Plot, File panes

What is the expected output? What do you see instead?
After choosing View -> Windows layout -> Spyder Default Layout and View -> Panes -> Notebook, the Notebook pane is grouped in the pane group on the left next to the python script pane

Versions and main components

• Spyder Version: 4.1.2
• Python Version: 3.7.8
• Qt Version: 5.12.5
• PyQt Version: 5.12.3
• Operating system: Win10 x64 1909

Dependencies

Please go to the menu entry Help > Optional Dependencies (or
Help > Dependencies), press the button Copy to clipboard
and paste the contents below:

atomicwrites >=1.2.0 : 1.3.0 (OK)
chardet >=2.0.0 : 3.0.4 (OK)
cloudpickle >=0.5.0 : 1.3.0 (OK)
diff_match_patch >=20181111 : 20181111 (OK)
intervaltree : None (OK)
IPython >=4.0 : 7.13.0 (OK)
jedi =0.15.2 : 0.15.2 (OK)
nbconvert >=4.0 : 5.6.1 (OK)
numpydoc >=0.6.0 : 0.9.2 (OK)
paramiko >=2.4.0 : 2.7.1 (OK)
parso =0.5.2 : 0.5.2 (OK)
pexpect >=4.4.0 : 4.8.0 (OK)
pickleshare >=0.4 : 0.7.5 (OK)
psutil >=5.3 : 5.7.0 (OK)
pygments >=2.0 : 2.6.1 (OK)
pylint >=0.25 : 2.4.4 (OK)
pyls >=0.31.9;<0.32.0 : 0.31.9 (OK)
qdarkstyle >=2.8 : 2.8.1 (OK)
qtawesome >=0.5.7 : 0.7.0 (OK)
qtconsole >=4.6.0 : 4.7.2 (OK)
qtpy >=1.5.0 : 1.9.0 (OK)
rtree >=0.8.3 : 0.9.4 (OK)
sphinx >=0.6.6 : 3.0.1 (OK)
spyder_kernels >=1.9.0;<1.10.0 : 1.9.0 (OK)
watchdog : None (OK)
zmq >=17 : 19.0.0 (OK)
cython >=0.21 : 0.29.16 (OK)
matplotlib >=2.0.0 : 3.2.1 (OK)
numpy >=1.7 : 1.18.1 (OK)
pandas >=0.13.1 : 1.0.3 (OK)
scipy >=0.17.0 : 1.4.1 (OK)
sympy >=0.7.3 : 1.5.1 (OK)
spyder_line_profiler : 0.2.0 (OK)
spyder_memory_profiler : 0.2.0 (OK)
spyder_notebook : 0.2.3 (OK)
spyder_terminal : 0.3.0 (OK)
spyder_unittest : 0.4.0 (OK)

[ikeszvpvb9ye]

The same goes for other presets in View -> Windows layout. It seems logical that the Notebook pane should dock in the same group as the pane with a python script

[jitseniesen]

I can confirm. This is indeed a bug, either in the plugin or Spyder itself, though perhaps not of the greatest importance.

[jitseniesen]

This is still an issue with Syder 4.1.4 and Spyder-notebook 0.3.0. I think we need to wait for the new plugin API in Spyder 5 before we can solve this.

[ccordoba12]

@goanpeca, I think there's no API entry in master to tell Spyder where it should put external plugins when using our layouts, right?

[goanpeca]

I think there's no API entry in master to tell Spyder where it should put external plugins when using our layouts, right?

No, we need to define the concept of LOCATIONS on the default layouts, so we can tell plugins to be placed in a given area.

Matlab has 6 areas:

• Top left
• Bottom left
• Top middle
• Bottom middle
• Top right
• Bottom right

RStudio has 4 areas:

• Top left
• Bottom left
• Top right
• Bottom right

Horizontal split has 2

• Left (Editor)
• Right (Everything else)

Vertical split has 2

• Top (Editor)
• Bottom (Everything else)

Spyder Default has 5

• Far Left (Projects)
• Left (Editor)
• Middle (Outline explorer)
• Top Right (Helps, Variable explorer etc...)
• Top Bottom (Consoles, history etc...)

What to do?

To be able to handle this properly, those areas need some names, then the Layout renderer will place them accordingly on those zones, and the pre-defined Layouts do not define the hard-coded locations for docks, but place the dock on a given LOCATION

These locations need to probably be named based on the global functionality, like:

• ConsoleLocation
• ExplorersLocation
• EditorsLocation
• ViewersLocation

Etc...

If you can define these things I can make a PR to use this.

[ccordoba12]

If you can define these things I can make a PR to use this.

Great! Thanks a lot @goanpeca!

@jitseniesen, could you give a hand here? I think the names should be spatial locations (e.g. TOP_RIGHT, BOTTOM_RIGHT, etc), instead of functionality-based, because we shouldn't constrain where developers can put their third-party plugins.

[goanpeca]

@jitseniesen, could you give a hand here? I think the names should be spatial locations (e.g. TOP_RIGHT, BOTTOM_RIGHT, etc), instead of functionality-based, because we shouldn't constrain where developers can put their third-party plugins.

The issue with that is:

• Right now is that the Spyder default layout defines 4 horizontal locations. so If location-based is the desired approach then users would need to be aware of a 2x4 grid (2 rows, 4 columns). If the Spyder default only used 3 columns, at least the was a possibility to define Left, middle, Right, and top and bottoms but the Spyder default layout breaks this.
• User would need to define things based on a 2x4 (or 2x3) grid all the time and we would need to make decisions on behalf of users.
• What does TopMiddle/BottomMiddle mean in horizontal split (Left or right?, this a decision that needs to be made for the developer, and hence it is a constraint). This example is based on a 3 column approach, but Spyder users 4, so that is already making things more difficult already.

Functionality (or another concept) based.

• By using locations based on functionality, the layout will adapt gracefully, example:

class SomePlugin(SpyderDockablePlugin):
    NAME= "some_plugin"
    LOCATION = Locations.Editors
    ....

If this way, Matlab, Rstudio, Spyder, Horizontal, Vertical, layouts will always work, since those locations are clearly defined for each layout, whereas a fixed position does not make any real sense across the different layout that Spyder bundles as defaults.

In horizontal split, Location.Editors will go on the left, and every other location goes on the right.

because we shouldn't constrain where developers can put their third-party plugins.

Could you elaborate on this, based on the above constraints @ccordoba12?

[nerohmot]

Personally I like the standard Eclipse/PyDev layout ...

but then ofcourse in spyder 🤣

@goanpeca I like your idea about the Locations/Areas very much, because it goes a long way in the direction how Eclipse solved this issue in 'perspectives'!

With perspectives we cover all of the above use-cases and can cover any others that might appear in future easily without any change to Spyder! Here is how that would work:

Any plugin can define ONE perspective, named after the plugin, and why not with a nice icon if needed. In a perspective it is defined how many areas there are, where the areas are located, and which of the default 'panes' go in what area. One of the areas is designated as the 'default' area, and any 'pane' not recognized or not assigned an area will go in the default area.

• Spyder itself would define 5 areas, and designate one of the area's as default, building the standard 'layout' as we know it now.
• the Horizontal Split (plugin) would define the 2 horizontal areas, designate the top only for the editor, and all the rest goes in the (default) bottom area.
• the Vertical Split (plugin) would define the 2 vertical areas, designate the left area for the editor, and all the rest goes in the (default) right area.
• the RStudio-sytle (plugin) would define the perspective as described above.
• the Semi-ATE plugin 😁 would follow the 'Eclipse/PyDev' style 🎉
• along comes a git(hub) plugin, and that plugin can present the user with a clever layout, defining a 'rest' area as default, dump editor layouts and whatever in it and make it invisible! 🦸
• the ... you get my drift right?

Now what happens if you switch perspective? Things still work because of the 'default' area!

In Eclipse one can switch between the perspectives by clicking the desired 'perspective' button shown below in the red-marked area (top right):

In our case that would maybe take up too much space in the (already crowded) toolbar, but we could maybe put it under a 'hamburger' to the far right of the toolbar ?