Change focus to Help window after Ctrl+Shift+H

[NotNormallyAGitUser]

Problem Description

After making Help window visible with Ctrl+Shift+H, the focus is still in the console. Pressing Ctrl+Shift+Alt+M maximizes the console instead of the Help window. It would be better if focus was on the Help window after Ctrl+Shift+H so that users can maximize with Ctrl+Shift+Alt+M without having to use the mouse/touchpad to change focus to the Help window

What steps reproduce the problem?

1. Ctrl+Shift+H to make Help window visible
2. Ctrl+Shift+Alt+M to maximize. The console maximizes instead of the Help window

What is the expected output? What do you see instead?

After Ctrl+Shfit+H, I would like Ctrl+SHift+Alt+M maximize the help window

Versions

• Spyder version: 5.4.3
• Python version: 3.9.18
• Qt version:
• PyQt version: PyQt5 5.15.7
• Operating System name/version: Windows 10 64-bit

Dependencies

PASTE DEPENDENCIES HERE

Mandatory:

atomicwrites >=1.2.0 : 1.4.0 (OK) chardet >=2.0.0 : 4.0.0 (OK) cloudpickle >=0.5.0 : 2.2.1 (OK) cookiecutter >=1.6.0 : 1.7.3 (OK) diff_match_patch >=20181111 : 20200713 (OK) intervaltree >=3.0.2 : 3.1.0 (OK) IPython >=7.31.1,<9.0.0,!=8.8.0,!=8.9.0,!=8.10.0 : 8.15.0 (OK) jedi >=0.17.2,<0.19.0 : 0.18.1 (OK) jellyfish >=0.7 : 1.0.1 (OK) jsonschema >=3.2.0 : 4.17.3 (OK) keyring >=17.0.0 : 23.13.1 (OK) nbconvert >=4.0 : 6.5.4 (OK) numpydoc >=0.6.0 : 1.5.0 (OK) paramiko >=2.4.0 : 2.8.1 (OK) parso >=0.7.0,<0.9.0 : 0.8.3 (OK) pexpect >=4.4.0 : 4.8.0 (OK) pickleshare >=0.4 : 0.7.5 (OK) psutil >=5.3 : 5.9.0 (OK) pygments >=2.0 : 2.15.1 (OK) pylint >=2.5.0,<3.0 : 2.16.2 (OK) pylint_venv >=2.1.1 : 2.3.0 (OK) pyls_spyder >=0.4.0 : 0.4.0 (OK) pylsp >=1.7.2,<1.8.0 : 1.7.2 (OK) pylsp_black >=1.2.0 : 1.2.1 (OK) qdarkstyle >=3.0.2,<3.2.0 : 3.0.2 (OK) qstylizer >=0.2.2 : 0.2.2 (OK) qtawesome >=1.2.1 : 1.2.2 (OK) qtconsole >=5.4.2,<5.5.0 : 5.4.2 (OK) qtpy >=2.1.0 : 2.2.0 (OK) rtree >=0.9.7 : 1.0.1 (OK) setuptools >=49.6.0 : 68.0.0 (OK) sphinx >=0.6.6 : 5.0.2 (OK) spyder_kernels >=2.4.3,<2.5.0 : 2.4.4 (OK) textdistance >=4.2.0 : 4.2.1 (OK) three_merge >=0.1.1 : 0.1.1 (OK) watchdog >=0.10.3 : 2.1.6 (OK) zmq >=22.1.0 : 23.2.0 (OK)

Optional:

cython >=0.21 : 0.29.37 (OK) matplotlib >=3.0.0 : 3.7.2 (OK) numpy >=1.7 : 1.24.3 (OK) pandas >=1.1.1 : 2.0.3 (OK) scipy >=0.17.0 : 1.11.1 (OK) sympy >=0.7.3 : 1.11.1 (OK)

[dalthviz]

Hi @NotNormallyAGitUser thank you for the feedback and sorry for the late response! I think that's the current behavior indeed (I was able to reproduce it :+1:).

I think there are some plugins that have the behavior you expect from the shortcut (to give focus) like the Editor, the Console and the Find pane. Maybe we should revisit which plugins get focus with their shortcut @ccordoba12 ? Maybe there is a reason for the current? At least in case of the Help pane, it kind of makes sense to let it have the focus over the combobox/line edit no? 🤔

What do you think @spyder-ide/core-developers ?

[mrclary]

I think, in general, window pane shortcuts should:

• open the pane if not already open and give focus to the pane.
• give focus to the pane if already open, not close them. For example the Outline and Project panes open if not already open, but close rather than give focus if they are already open.

These are just my opinion.

[ccordoba12]

Maybe we should revisit which plugins get focus with their shortcut @ccordoba12 ?

The problem is that some people could find useful (like @NotNormallyAGitUser) to give focus to panes that can have it (like Help), but others don't. In my case, I always ask for help from the code I'm writing in the Editor or IPython console. So, I'd find inconvenient to give focus to Help after that because it'd break my workflow.

A flexible solution that would acomodate both use cases would be to add an entry to the Options menu to turn on/off focus for plugins like Help.

[NotNormallyAGitUser]

@ccordoba12 : Thanks for clarifying the fact that it's not so simple. In addition to a GUI widget to enable/disable automatic shifting of focus, it can also be a parameter in the startup config file.

[ccordoba12]

Yep, that menu entry would be linked to an option in our config system so that it's preserved after restarts.

[mrclary]

In my case, I always ask for help from the code I'm writing in the Editor or IPython console. So, I'd find inconvenient to give focus to Help after that because it'd break my workflow.

I think you are correct here. However, the Help pane has two shortcuts associated doesn't it? On my mac, cmd+i shows the help pane without focus but updates to the requested context, while cmd+shift+h toggles the pane open/closed.

A flexible solution that would acomodate both use cases would be to add an entry to the Options menu to turn on/off focus for plugins like Help.

But I agree with this. The user could decide the behavior: make visible with focus; make visible without focus; toggle the pane open/closed.

In my case I find that panes will toggle closed when I just want them to be visible, e.g. in a tab group, requiring me to execute the shortcut twice (close pane, open pane with visibility in tab group but no cursor focus).

[ccordoba12]

On my mac, cmd+i shows the help pane without focus but updates to the requested context, while cmd+shift+h toggles the pane open/closed.

Right, but if we set that the plugin must receive focus after being raised, then both cmd/ctrl+i and cmd+shift+h will give focus to the Help's line edit widget (we don't have a way to make one shortcut work differently from the other).

In my case I find that panes will toggle closed when I just want them to be visible, e.g. in a tab group, requiring me to execute the shortcut twice (close pane, open pane with visibility in tab group but no cursor focus).

Could you expand on this? How is a pane closed through a shortcut? (I thought that was not possible).

[mrclary]

On my mac, cmd+i shows the help pane without focus but updates to the requested context, while cmd+shift+h toggles the pane open/closed.

Right, but if we set that the plugin must receive focus after being raised, then both cmd/ctrl+i and cmd+shift+h will give focus to the Help's line edit widget (we don't have a way to make one shortcut work differently from the other).

Aahh, got it.

In my case I find that panes will toggle closed when I just want them to be visible, e.g. in a tab group, requiring me to execute the shortcut twice (close pane, open pane with visibility in tab group but no cursor focus).

Could you expand on this? How is a pane closed through a shortcut? (I thought that was not possible).

Absolutely. Perhaps this is just a bug for macOS, but the following screencast illustrates the behavior. The Outline, Projects, Help, and Variable Explorer panes are all open. Using the standard shortcuts (cmd+shift+o, cmd+shift+p, cmd+shift+h, cmd+shift+v), you can see that the panes are not made visible, but rather closed, and executing the shortcut again opens the pane (and makes visible) without cursor focus.

Perhaps this is related to macOS menubar items? I think the menubar items should open/close their respective panes (hence the checkmark), but perhaps the shortcut gives priority to this behavior, rather than just making the pane visible.

[ccordoba12]

Thanks for the clarification @mrclary. This was working fine in Spyder 4 by disabling the shortcuts in the View > Panes menu. But it seems it was broken in version 5.0a3 and has been broken since.

I'll submit a PR shortly to fix it.