Bug 198155

Summary:	newly assigned shortcut keys don't work
Product:	[Applications] kmenuedit	Reporter:	adam <spam>
Component:	general	Assignee:	Unassigned bugs mailing-list <unassigned-bugs>
Status:	RESOLVED WORKSFORME
Severity:	normal	CC:	aendu+bugs.kde.org, gatoatigrado, jgj7.kde, untitled.no4, wstephenson
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	openSUSE
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:
Attachments:	script to enable menu shortcuts in khotkeysrc

Description adam 2009-06-28 13:18:51 UTC

Version:           0.8 (using KDE 4.2.90)
OS:                Linux
Installed from:    SuSE RPMs

Running KDE4.3b2, "release 138," under OpenSUSE 11.1, installed from OpenSUSE Factory repos.

I have several existing shortcut keys set up in the KDE menu editor under previous KDE versions, which continue to function normally.

When I try to set up shortcut keys for newly installed applications, the interface works normally, informs me of conflicting key commands, successfully captures and allows me to save the new shortcut keys, remembers them after reboot, etc. However, the key new combinations simply do not work. I have tried several keys and apps with the same result.

I have no custom key bindings set in the system settings (version 1.0, KDE 4.3 beta 2, release 138), and I have no keybinding commands set in the ccsm general settings, though I am also running compiz (0.7.8), also from the OpenSUSE repos. The fact that the application grabs the key combinations shows that it recognizes the keys, and I am not using any unusual keys that don't already function in other menu editor shortcuts. As I say, this bug does not affect existing key combinations in menu editor, which function normally.

Comment 1 G Cohen 2009-07-05 22:44:51 UTC

Same thing happens with Kubuntu 9.04 KDE 4.3 RC1. Shortcut keys that were set before upgrading to KDE 4.3 beta 2 work, but newly assigned shortcut keys don't.

Comment 2 adam 2009-07-16 14:34:55 UTC

Problem is still present in KDE 4.3 RC2. How come this is normal priority/unconfirmed? Wouldn't want to roll out KDE 4.3 with this bug, surely?

Comment 3 IgnorantGuru 2009-08-07 00:30:07 UTC

Fresh install of Kubuntu Karmic alpha 3 with full update today (KDE 4.3), and no app keyboard shortcuts assigned in kmenuedit work (it accepts and keeps them but they don't work).  Alt-Tab and other global shortcuts work okay.

Comment 4 IgnorantGuru 2009-08-07 01:37:44 UTC

Workaround...  It appears that when kmenuedit adds the shortcut to ~/.kde/share/config/khotkeysrc (via qdbus?), it sets "Enabled=false".  For example:

   [Data_1_2]
   Comment=firefox.desktop
   Enabled=false
   Name=Firefox Web Browser
   Type=MENUENTRY_SHORTCUT_ACTION_DATA

If you edit khotskeyrc and change "Enabled=true" for the desired entry, then tell khotkeys to reload its config file:

   qdbus org.kde.kded /modules/khotkeys org.kde.khotkeys.reread_configuration

Then the shortcuts work for me.  (Note: Don't change all the "Enabled=false" in that file to true because some are just examples)

Comment 5 IgnorantGuru 2009-08-12 20:12:38 UTC

Created attachment 36104 [details]
script to enable menu shortcuts in khotkeysrc

Be sure to run as user not as root

Comment 6 IgnorantGuru 2009-08-12 20:14:04 UTC

Also note that this bug may affect the workaround (namely, if it is a brand new menu item, you have to save it twice with the shortcut key before it will be stored, then use the above Enabled=true workaround)...
https://bugs.kde.org/show_bug.cgi?id=203601

Also, above is a simple script that corrects the problem in khotkeysrc... run it after saving the menu and it will enable the keys.  (On my system the "[Data1..." entries are for the menu - if this differs on your system you will need to change the script.)

Comment 7 Dario Andres 2009-08-18 20:21:08 UTC

*** Bug 199315 has been marked as a duplicate of this bug. ***

Comment 8 Will Stephenson 2009-11-23 18:17:17 UTC

This seems to work for me with svn (4.4pre)

Comment 9 Will Stephenson 2009-11-23 18:18:36 UTC

*** Bug 203601 has been marked as a duplicate of this bug. ***