Version: unspecified (using Devel) OS: Linux It happens quite frequently that I accidently press Shift+Tab during file name completion in bash, and find it quite irritating that it cycles through widgets (while Tab does not). It would be nice if Shift+Tab was passed to the terminal like Tab is. Reproducible: Didn't try
What version you running? I thought this was fixed
trunk, compiled two days ago.
Ah, so that's what's happening. I see the same thing in Konsole 2.5.3 (KDE Platform 4.5.3). A little backstory: I want to use Shift+Tab in vim and it was possible in earlier versions. However, in the current Konsole version Shift+Tab switches focus between containers. And sure enough, in the shortcuts dialog Shift+Tab is assigned to "Next View Container" by default. However - and this is why I comment here - setting the shortcut to None doesn't work. Shift+Tab is still not passed to the terminal, it seems to have the same behavior as before.
Correction: it seems to work if I only have one view now, but if I for example split the screen Shift+Tab still switch between the containers.
I can reproduce what Hans said in comment #3 and #4.
Git commit 105043b75c6d6906073bff2f5c6a522c0ad1a446 by Jekyll Wu. Committed on 12/10/2011 at 05:28. Pushed by jekyllwu into branch 'master'. Shift+Tab should not cause implicit focus switching in stand-alone konsole This allows passing Shift+Tab to the terminal process when split view is in use and the shortcut of "Next View Container" action is set as "None". BUG: 244514 FIXED-IN:4.8 REVIEW:102834 M +9 -0 src/MainWindow.cpp M +3 -0 src/MainWindow.h M +6 -5 src/TerminalDisplay.cpp M +1 -1 src/TerminalDisplay.h http://commits.kde.org/konsole/105043b75c6d6906073bff2f5c6a522c0ad1a446
I don't use split views, and after the previous commit, the bug still appears. This is both with the keyboard shortcut for "Next View Container" set to defaults (Shift+Tab), as well as None. To reproduce: - exit all Konsole processes - run Konsole - press 'k' - press Shift+Tab slowly multiple times Result: - the cursor gets unfocused while the tab bar and the "New Tab" button get focus, until the terminal display gets focus again.
(In reply to comment #7) Hi Christoph, thanks for your feedback. But I can't reprouce that problem. Pressing 'Shift+Tab' gave no result for me in bash(I guess you are using it), but I didn't notice the focus switched to other widgets. The next key pressed afterward went into bash as expected. I mostly use Shift+Tab for switching to previous tab in vim. Here is my example for reproducing the bug and verifying the fix. 1) add "nnoremap <silent> <S-Tab> :tabprevious<CR> " into ~/.vimrc 2) open konsole, make sure "Next View Container" does not have Shift+Tab as shortcut 3) split the view 4) run vim 5) open a few tabs with ":newtab" in vim, then press Shift+Tin vimab behavior indicating the bug: focus switches to another view and I am not in the previous tab of vim behavior indicating the fix: focus stays in current view and I am in the previous tab of vim
Okey, started from a clean configuration, and found the issue. Please enable "Show 'New Tab' and 'Close Tab' buttons in tab bar" from the "Tabs" edit profile page.
\o/ Please review and apply. http://paste.kde.org/134287/
(In reply to comment #9) > Okey, started from a clean configuration, and found the issue. Please enable > "Show 'New Tab' and 'Close Tab' buttons in tab bar" from the "Tabs" edit > profile page. Well, those buttons were enabled and shown in my previous attempt. Anyway, I just created a new user account and enabled that option to produce that problem, but failed again. Is that problem reproduceable in other apps? like zsh, or my vim example(without split view)? Or, since you are using the git version, you can modify src/TerminalDisplay.cpp to make TerminalDisplay::focusNextPrevChild(bool) always return false. If that problem disappears , then the previous commit is not good enough. If that problem still exists, I really have no idea. (In reply to comment #10) > \o/ Please review and apply. > > http://paste.kde.org/134287/ I would like to first find out where the previous commit goes wrong, if it does.
(In reply to comment #10) Hi Christoph, I still can't reproduce the problem. If the problem is still bothering you, go ahead and commit that change. I don't think that change will cause any harm.