Version: (using KDE KDE 3.1) Installed from: FreeBSD Ports OS: FreeBSD See the so called "short description", really. Go into kmenueditor, assign the same keyboard shortcut to two different apps, apply, press that keyboard shortcut, try to run one of the apps from the menu that pops up without using the mouse. I don't know what part of KDE _really_ handles that menu so I file this bug here. Please change responsibility as appropriate.
Created attachment 1164 [details] Modification of KShortcutMenu to honor keys other than Up and Down. This patch alters KShortcutMenu to use QPopupMenu's default key responses if the keys do not match a listed action. This fixes the bug while still allowing the user to dismiss the popup like any other popup menu. The code I removed passes Up and Down to QPopupMenu if they don't match any of the listed actions, and responds to any other non-matching keystroke with a close() call. This makes Enter and whatnot appear that it has selected an item, when in fact it has dismissed the popup menu. I'm not sure what the goal was there. As the paths in the patch imply, this patch is against 3.1 release, but from what I can tell it works against HEAD as well. Please contact me with any questions.
I applied a similar fix a weeks ago. (It just passed enter/return accross, though). Thanks a lot for the patch and the report -- and the reminder that I need to backport it. (http://lists.kde.org/?l=kde-cvs&m=105285787009654&w=2) *** This bug has been marked as a duplicate of 55139 ***