Version: unspecified (using KDE 4.8.0) OS: Linux With the default settings, Alt+Tab for stepping forward and Alt+Shift+Backtab for stepping backward, the latter does not seem to recognize the Shift key and hence provides the same forward-stepping behavior as Alt+Tab. Reproducible: Always Steps to Reproduce: Press Alt+Shift+Backtab Actual Results: Task switcher walks through windows forward. Expected Results: Task switcher should walk backwards. I am using the US International keyboard layout with dead keys enabled. N.B.: This issue may stem from the same source as https://bugs.kde.org/show_bug.cgi?id=294245, since the Shift key seems to be giving problems.
For me Alt+Shift+Tab doesn't do anything (i.e. it does not step forward in the list as it seems to do for Steven). I'm using German keyboard layout, for that matter... This is with Kubuntu 12.10 and KDE 4.9.3.
(In reply to comment #1) > For me Alt+Shift+Tab doesn't do anything (i.e. it does not step forward in > the list as it seems to do for Steven). > > I'm using German keyboard layout, for that matter... > > This is with Kubuntu 12.10 and KDE 4.9.3. For me, the issue was that Alt + Shift was already set as a shortcut for something else (switching keyboard layouts, see bug 294245). Changing that setting removed my issue with tabbing through windows. Perhaps you have a similar issue? (But of course do check whether Alt + Shift + Tab is set for tabbing backwards.)
I use KDE Platform Version 4.11.3 (openSUSE 12.3)
Sorry, the last comment was meant for https://bugs.kde.org/show_bug.cgi?id=294245
Neither works for me in 4.14.9. If I try to reassign Alt + Shift + Tab as the shortcut key, it only recognizes Alt+Tab.
Can confirm on plasma 5.4.3 and kubuntu 15.10: Pressing Alt+Shift+Tab walks one window forward (wrong direction) with the first key press, then the subsequent key presses walk backwards (as expected). The desktop switcher shows the same behaviour (I find it easier to observe there).
This started to happen when I upgarded the kde suite from 5.8.(5 or 6) to 5.11.1 from the neon ppa. I tried MANY shortcuts (like ctrl+alt+arrows or meta+pg(up/down)) I tried many keyboards models from the input options I don't have layout switching I tryed with both usb keyboard and the integrated keyboard of the laptop I checked with xev that the presses are captured My conclusion as a user is that the problem it's not the reverse shorcut per se, but how input is handled. I can trigger a first reverse but no further than that. while the task switcher window is open, the only shortcut captured is further presses from the tab key. If I bind next task to say, ctrl+pg down, then switching tasks forward is not possible (beyond the first one). As if there is some where coded some behavior specifically for the tab key. Please help, or help me help you
(In reply to zeta from comment #7) > This started to happen when I upgarded the kde suite from 5.8.(5 or 6) to > 5.11.1 from the neon ppa. > > I tried MANY shortcuts (like ctrl+alt+arrows or meta+pg(up/down)) > I tried many keyboards models from the input options > I don't have layout switching > I tryed with both usb keyboard and the integrated keyboard of the laptop > I checked with xev that the presses are captured > > My conclusion as a user is that the problem it's not the reverse shorcut per > se, but how input is handled. > > I can trigger a first reverse but no further than that. > > while the task switcher window is open, the only shortcut captured is > further presses from the tab key. > > If I bind next task to say, ctrl+pg down, then switching tasks forward is > not possible (beyond the first one). As if there is some where coded some > behavior specifically for the tab key. > > Please help, or help me help you btw, I tryed different switching animations, so thatś not the issue. Compiz is disabled. i also tried sudo dpkg-reconfigure xserver-xorg with no success
Some update on how this is going: Operating System: Debian GNU/Linux KDE Plasma Version: 5.14.5 Qt Version: 5.11.3 KDE Frameworks Version: 5.54.0 Kernel Version: 4.19.0-2-amd64 OS Type: 64-bit this is on Xorg. I settled down to: alt + tab (+shift for reverse) as the main switcher (for windows in current activity) alt + F22 (+shift for reverse) as the secondary switcher (for windows in all activities) Note that: To use F22 I have remapped CapsLock (effectively disabling CapsLock) to F22 with this .Xmodmap file: ############################## remove Lock = Caps_Lock keycode 66 = F22 clear Lock ############################## then enabling it with xmodmap ~/.Xmodmap RESULTS: alt + tab mappings WORK. Also, while still pressing alt, I can hit ESC key to abort the switch alt + F22 mappings WORK, mostly. While still pressing alt, the ESC key does NOT abort the switch. I have to click outside with the mouse to abort the switch There is some hardcoding magic somewhere in the way alt/shift/tab/esc keys are treated, which prevents this from working. Note that this is not hardware related, because in both window switchers 1 and 2 (current activity and global) by the time I hit the ESC key, in both cases I am only holding down the ALT key. Best Regards
I've just tested this on the latest plasma from git master and I cannot reproduce the issue. Can you please test and confirm if this issue is still occurring or if this bug report can be marked as resolved. I've set the bug status to "needsinfo" pending your response, please change back to "reported" or "resolved" when you respond, thanks.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!