Bug 198155 - newly assigned shortcut keys don't work
Summary: newly assigned shortcut keys don't work
Alias: None
Product: kmenuedit
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: Unassigned bugs mailing-list
: 199315 (view as bug list)
Depends on:
Reported: 2009-06-28 13:18 UTC by adam
Modified: 2009-11-23 18:18 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:

script to enable menu shortcuts in khotkeysrc (822 bytes, text/plain)
2009-08-12 20:12 UTC, IgnorantGuru

Note You need to log in before you can comment on or make changes to this bug.
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:

   Name=Firefox Web Browser

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)...

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. ***