Summary: | walk through windows does not work if changed from alt+tab | ||
---|---|---|---|
Product: | [Plasma] kwin | Reporter: | Maciej Pilichowski <bluedzins> |
Component: | general | Assignee: | KWin default assignee <kwin-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | dima, feffer777, finex, jpakkane, mail, mensch, purevw, schubert.seb |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | openSUSE | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Maciej Pilichowski
2008-06-10 21:07:13 UTC
Do you mean ALT+TAB? Well, it was alt+tab, but I always reassign it to win+tab. But it really does not matter, since the key is recognized, there is a response, but the wrong one. I can confirm this in SVN, changing the global shortcut to anything other than Alt+tab breaks it in different ways depending on the shortcut used. Now even alt+tab does not work. I want to confirm that this is still a problem in 4.2 beta 2 and add some additional information about the bug. If a custom shortcut is used for "walk through windows", the shortcut will work properly to INITIALIZE the walk-through process (the walk-through window will pop up and the second entry will be highlighted). Once started, however, you can only move further down the list by hitting alt-tab and can only move back up the list using alt-shift-tab. So, it seems that alt-tab is hardcoded in to the mechanism (apart from initialization). Resolving this one would be a huge help to me as I'm setting up a wiimote to use with my media server, and being able to use alt+right and alt-left to walk through windows would be much better than having to assign another button on the wiimote to act as a shift key when I don't otherwise need to. I'm running 4.2 and have the same problems Patrick is describing. Reverting to the defaults keyboard shortcuts (Alt+Tab and Alt+Shift+Backtab) after having changed them to something else doesn't bring back the proper application switching behaviour for me though. *** Bug 178930 has been marked as a duplicate of this bug. *** *** Bug 187478 has been marked as a duplicate of this bug. *** Even reverting to Alt-Shift-Tab is broken: the default for walking in reverse is "Alt-Shift-Backtab", but if I enter it manually, it appears as "Alt-Backtab". After restarting kwin, it still doesn't work. That is, as Lucas mentioned in bug 187478, restarting kwin makes it use the new shortcuts - but it doesn't work for Alt-Shift-Backtab. If I change "walk" to Meta-Tab, it starts switching - but never exits; I have to press Enter or Esc to stop. One time it froze completely. Meta-Backtab doesn't work, just like Alt-Backtab. Using backtab with shortcuts doesn't work due to bug 179562. I may have the same bug. Window switching does not work at ll in KDE4. KDE3, Ubuntu Intrepid (gnome), and Windows XP all switch windows correctly. None of the above workarounds worked for me. alt+tab simply does nothing in KDE4. It worked before, so I assume that this is due to a recent upgrade. I subscribe to the "stable" KDE repositories. Hopefully a fix will be issued soon. It's a pain to have to use the mouse to switch windows. I have suffered from a similar bug in every single KDE release since about 3.5.something days. It happens both on Debian and Kubuntu. Steps to reproduce Change modifier key to mod. Press and hold mod, keep holding it for a while. Press and release tab, keep holding mod down. The task list appears. Release mod. At this point the task list should disappear, but it does not. The only way to make it go away is to press tab or esc. If you press mod and then flick tab very, very quickly and then immediately release mod, you change to the second topmost window. This is the correct behavior. But you have to be very fast, if the task list appears, you are screwed as discussed above. What should happen: when you release mod, the task switcher should go away immediately, no exceptions. I upgraded to 4.2.* and alt-tab now switches windows, but I get no window list. Focus is switched to the next window. If I hold "alt" and repeatedly hit "tab", I can switch through all windows. This problem is unique to one machine only, so I assume it is a problem with a settings file, and not really a bug. If I knew what file to delete, I could probably just start over. If it is of any importance, Compiz does show the switcher list if I choose it over Kwin and window manager, but the machine totally hangs and the only thing I can do is hold the power button to force a system halt. None of the keys can force a reboot or restart of X. (In reply to comment #14) > I upgraded to 4.2.* and alt-tab now switches windows, but I get no window > list. Focus is switched to the next window. If I hold "alt" and repeatedly hit > "tab", I can switch through all windows. This problem is unique to one machine > only, so I assume it is a problem with a settings file, and not really a bug. Ronnie your problem is not related to this bug and as you thought a wrong setting. Please consult a support channel like for example forum.kde.org as this is a technical bugtracker. I apologize for posting in the wrong area. Thanks for a very good product. I confirm the behaviour: WIN+TAB works after a restart, WIN+BACKTAB (WIN+SHIFT+TAB) does not even after a restart. WIN+TAB does not leave the window switcher window until another key is pressed. This can be fixed by xmodmap -e "add mod4 = Super_L" Apparently, this bug has been around for some time... https://bugs.kde.org/show_bug.cgi?id=149774 SVN commit 972533 by graesslin: Track change of global shortcuts for tabbox. Required for the tabbox to work correctly when a shortcut is changed. BUG: 163732 M +30 -0 tabbox.cpp M +18 -0 useractions.cpp M +7 -0 workspace.h WebSVN link: http://websvn.kde.org/?view=rev&revision=972533 Did the fix not make it into KDE 4.3 RC1? I'm still seeing this bug. |