Pressing the ‘Previous tab’ only switches back and forth between the last two used tabs, instead of cycling back in the list of open tabs. Reproducible: Always Steps to Reproduce: 1. Open several (3 or more) .po files, so that a tab is created for each of them. 2. Click one tab. Click another tab. 3. Press the shortcut key for ‘Previous tab’. Actual Results: Each time you press the shortcut key, Lokalize switches between the two last used tabs. Expected Results: Each shortcut key press should cycle backwards through the list of tabs (just like ‘Shift + Left arrow’ does in Konsole or Yakuake). Pressing the shortcut key for ‘Next tab’, on the other hand, *works*, in that one can cycle between all open tabs. However, the order the tabs are cycled through is somewhat confusing. I think it would be better if the ‘Previous/Next tab’ shortcuts cycled through the tabs in the visual order, i.e. ‘Previous tab’ would select the tab to the left of the current one, and ‘Next tab’ would select the tab to the right of the current one (just like the similar feature in Konsole/Yakuake/Dolphin).
I’ve made some progress on this issue. With a simple change, I can make Ctrl+Tab and Ctrl+Shift+Tab behave like Ctrl+[ and Ctrl+] currently do. If I then revert commit d344548d0e3b8b86a2c973826d12d6ec16a74045, I get the desired behavior. However, we lose the feature that d344548d0e3b8b86a2c973826d12d6ec16a74045 introduced, which opens the last open tab when you close a file. I am now sure we want to loose that feature. So, unless we do want closing a tab to open the next tab to the right, I need to look into a different solution. I am attaching the work I’ve done so far for reference.
Created attachment 113040 [details] Changes that fix the issue but remove a feature
I’ll forget about the shortcuts, since the report is not about them, and focus on the behavior of the previous tab action. I’ve created a poll to ask for feedback from users at https://framadate.org/4GhuwxmYxXLgPCAm and sent it to the kde-i18n-doc kde mailing list.
Based on the (limited) feedback on the survey, most users prefer the current behavior. So even though I agree that the current behavior is confusing, I don’t think it would be a good idea to simply change it. If you really want this implemented, it should be as an option, and the default value should be the current behavior. This is what Firefox has, only that in their case the default behavior is the one you propose. I personally prefer Firefox’s approach for navigation to the previous or the next tab, but I prefer Lokalize’s behavior when closing a tab (open the last active tab). But, if that is what you want, it will be more complex to solve. In any case, please state if you want to keep this report open, and if so, what would be de desired behavior when selecting the next tab, when selecting the previous tab, and when closing a tab. Also specify how it should be enabled, e.g. a single option or two options (one for next/previous, one for closing).
(In reply to Adrián Chaves (Gallaecio) from comment #1) > I’ve made some progress on this issue. With a simple change, I can make > Ctrl+Tab and Ctrl+Shift+Tab behave like Ctrl+[ and Ctrl+] currently do. I wasn’t aware of the ‘Ctrl + [’ and ‘Ctrl + ]’ shortcuts. They don’t work with my keyboard layout (where [ and ] are not *keys*, just characters accessible using the ‘Alt Gr’ key in combination with the ‘8’ and ‘9’ keys). And I couldn’t find them in the shortcut config dialogue. If there were (‘Ctrl + [’ and ‘Ctrl + ]’) available for cycling between the tabs, this would be very useful (and this bug report wouldn’t be needed). But at least on my (Norwegian) keyboard layout, there aren’t. There’s only the ‘Previous tab’ and ‘Next tab’ shortcuts, which I find utterly confusing and useless (and whose behaviour is completely different from the ‘Previous tab’ and ‘Next tab’ features in *other* KDE applications, like Dolphin and Konqueror).
I'm a bit confused, is there a consensus about how Ctrl+Tab should behave in a perfect world ? I can try to add an overriding option to cycle through tabs the normal ways (left-to-right/right-to-left) and keep the current behavior when a tab is closed (I think this should even be the default behavior).
That would be great, Simon.
You can comment the change review here, which should offer the flexibility for everyone https://phabricator.kde.org/D15444
Git commit 2049c62fbb7dc9eb71adf7a6143903c36383277f by Simon Depiets. Committed on 14/09/2018 at 07:57. Pushed by sdepiets into branch 'master'. Simplify the behavior of tab switch navigation Summary: This feature simplifies the behavior of the tab switch navigation. The Ctrl+[ and Ctrl+] shortcuts become Ctrl+Tab and Ctrl+Maj+Tab and override the previous default QMdiArea's embedded QTabBar shortcuts behavior (which only drew a box around the tab which would be selected once the key was released). The behavior will be similar to Chrome/Konsole by default (switch directly to the next/previous tab in the order the tabs are displayed). The exception will remain when a tab is closed, in that case the previously opened tab will be displayed. This behavior can be overridden in the menu option by selecting "According to tab activation order". In that case the current behavior (prev tab selects the previously selected tab, next tab selects the oldest selected tab) will be used. Finally a shortcut was added to just switch between the last two previously activated windows : Ctrl+[. Reviewers: #localization, adrianchavesfernandez, huftis, aacid, ltoscano Tags: #localization Differential Revision: https://phabricator.kde.org/D15444 M +0 -2 src/cataloglistview/cataloglistview.cpp M +23 -7 src/lokalizemainwindow.cpp M +10 -1 src/lokalizemainwindow.h M +1 -0 src/nokde-stubs/prefs.cpp M +7 -0 src/nokde-stubs/prefs_lokalize.h M +0 -1 src/noteeditor.cpp M +3 -0 src/prefs/lokalize.kcfg M +35 -1 src/prefs/prefs_editor.ui https://commits.kde.org/lokalize/2049c62fbb7dc9eb71adf7a6143903c36383277f