Fix foreground process shortcuts #680
Conversation
There was a problem hiding this comment.
Hm, I'm not sure about the changes to the searchbar here, especially since if you've opened the searchbar it's now stuck open until the foreground process ends. It also seems like we'll get issue reports about not being able to create or switch tabs while a command is running.
I wonder if we should expand the behavior of the current "Natural Copy/Paste" toggle to have more of a "CLI app mode" or have a per-tab option to disable all app shortcuts while the current tab is focused. Or just generally something that feels more deliberate.
|
OK, thanks for the review - I'll rethink it. |
You can always create a new tab or switch tabs with the mouse. If we allow the foreground process to receive all key presses first (which seems necessary to fix the issue) then there is likely to be this issue, especially if the process eats the key event. |
|
@danrabbit One solution may be to special case certain key combinations such as those that switch tabs or create a new tab? These would not be passed to the foreground process. Let me know which actions should be special cased and I'll try and implement it. |
|
It doesnt really make sense to perform a search on a tab that has a foreground process so it seems reasonable to make the searchbar insensitive when such a tab is focused? |
Fixes #676
When a foreground process is current all key presses received by the MainWindow are passed straight to the terminal (MainWindow actions are therefore inhibited). As a consequence, the search entry and button are also made insensitive.
This has the drawback that MainWindow actions are inhibited whether or not the foreground uses any of the same shortcuts as MainWindow but there is no obvious way of determining whether or not a shortcut has been used by a foreground process. But as all actions can be initiated with the mouse this does not seem too much of an issue.