Jerome Yuzyk posted on Sun, 22 Apr 2012 22:23:58 -0600 as excerpted: > On Saturday, April 21, 2012 12:20:22 PM Duncan <1i5t5.dun...@cox.net> > wrote: >> Jerome Yuzyk posted on Fri, 20 Apr 2012 19:54:45 -0600 as excerpted: >> > KDE 4.6.5 on Fedora 15 >> >> Thanks. A lot of folks forget to include that info. >> >> > Alt-Tab (and Alt-F2) suddenly stopped working. I have no idea what I >> > did. >> > >> > How do I restart them? >> >> Possibilities: >> >> 1) Are you sure the alt-key on your keyboard is still working? I've >> had > > Yes, Alt-Tab works in my Windows VMs, and Alt-key for picking menu > items. > >> 2) The keyboard shortcuts may have been changed. Try kde settings > > Tried, they're ok. > > > Oddly, Ctrl-F1 etc works fine. > > > Is this function handled by KWin or Plasma?
In settings, it's kwin for switch-window (alt-tab), the run command interface (aka krunner, uses plasma libs but is a separate app) for run command (alt-f2 by default, I have an inet/media keyboard here, with extra keys, one of which I assigned to launch the open dialog clear back in the kde3 era, so I had to look that one up...). Except... I'm not sure if it's the actual apps that handle it, or if they simply delegate to khotkeys or whatever. Even if they do handle it themselves, it's surely thru a common library, probably part of kdelibs. Either way, that would explain why two unrelated apps had the same problem. What about alt-f3, normally assigned to trigger the window menu? Does that work. What about ctrl-alt-esc, normally assigned to kill window (you might wish to launch a handy window to kill before trying that one)? And, you confirmed that they were still assigned correctly. What about trying to reassign the usual shortcut back to the function, even if it says it's already assigned? Normally, when you hit the alt, it will show up as a modifier (as will shift, meta/win, ctrl...) before you hit the modified key. Here (kde 4.8.2, gentoo), using the walk-thru-windows function since I do have it assigned the default alt-tab still, if I hit the button to assign it a new shortcut, then hit alt (and keep it down), the button shows alt+ ... waiting for me to hit the alt-modified key. I can then hit shift and it'll show alt+shift+ . If I release the shift it'll go back to just alt+ . If I then hit tab as the modified key... I immediately get a warning about a conflict, saying it's already assigned to kwin, walk thru windows. (Apparently the warning isn't smart enough to see that I'm assigning the same shortcut to the same function, and warn me about /that/ instead of the more generic it's already assigned warning that I'd get if I tried assigning that key combo anywhere else, as well.) What I'm wondering is where the detection is going wrong. If you try to assign alt+tab back to the same walk-thru-windows function it was assigned to previously, you should either get a warning saying it's already assigned, if kde is properly detecting it, or be able to see what it's detecting instead. (FWIW, even if you accept the key change edit itself, you can still hit either apply, at the bottom of the setting dialog, to finalize it, or reset, to revert to what it was before. So just don't hit that apply button if you don't want it to stick.) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman ___________________________________________________ This message is from the kde-linux mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde-linux. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
