-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Fix several problems with our shortcuts system #3235
Conversation
- This prevents clashes with the IPython Console
- Before they were global shortcuts, which was interfering with the IPython console shortcuts.
- This attribute is going to be used to save shortcuts and show them when a user selects a global menu. - This way we avoid adding global shortcuts that override local ones.
- This way we could show shortcuts for those actions but only when global menus are made visible by the user. - By doing that we'll prevent clashes with widget shortcuts but at the same time we'll be able to show shortcuts in our menus, which is important for our users.
I don't understand the part about hiding and showing shortcuts in the menu. Why aren't they always shown ? From what I understood, the shortcuts are hidden when the menu is hidden. |
@Nodd, thanks for asking! This is the thing: If we directly assign a shortcut to an action present in a global menu or toolbar (e.g. Run cell) that shortcut acts at the application level and so it supersedes the same shortcut present in any widget (e.g. However, I think it's quite valuable to show these shortcuts next to their actions' text when the user selects a menu. So that's why I show and hide them when the menu becomes visible/invisible. I know this is very intricate (and @goanpeca probably won't approve it) but I haven't found find any other way of doing it. And I invested two full days thinking on how to solve this problem! The easiest thing would be to not show these shortcuts, but I think that wouldn't help our users to memorize them. So we're forced to circumvent Qt limitations here :-) |
Also: - Remove shortcut for Winpdb (I don't think it's really necessary). - Make the debug shortcut a global one.
OK I understand. Not a perfect solution indeed, but that's a tricky situation. If I thought that child widgets had the priority when using shortcuts, but maybe it's not the case with application shortcuts. I discovered recently that in the vim plugin there is a conflict between Esc to focus the vim widget (defined at application level) and Esc to close the search pane (defined in itself only, I suppose). I'll have to enable the shortcut for the editor only. |
I really prefer one solution for all platforms. Else you'd have to remember to change contexts for Linux and Windows, and add That could become a nightmare in no time :-)
Yes, please define it only for the Editor because it also conflicts with the IPython Console ( |
@Nodd, on second thought I think you were right :-) So I added code to handle the case of So things are transparent now for external plugin developers: if they want to disable a shortcut from an action in a global menu, they just need to set their context to |
But for that they need to use |
That's where they really belong
They are valid for all our plugins not only the Editor
They all have to come from config/main or be set by CONF.set
Ok, after a lot of work, I think this one is finally ready! I reviewed all our shortcuts and checked (or fixed) that their contexts were the right ones. Things were in a semi-broken state but hopefully they are good now. I really don't know how @blink1073 and @goanpeca were able to do substantial contributions to our shortcuts support, given the previous state of things! ;-) |
🎉 |
The main purpose of this PR is to solve conflicts between global and plugin shortcuts.
Now that we are allowing Spyder to be extended by external plugins, we have to be sure to define shortcuts in its right context to avoid ugly conflicts.
Some problems that this PR solves:
Ctrl+Enter
was not working on Mac because of conflicts with the IPython console shortcuts.Ctrl+Shift+<X>
was not working on Mac because of conflicts with the shortcuts shown in in theView > Panes
menu (we were using a hack to avoid that but it doesn't work on Mac! :-).