| Summary: | custom shortcuts (Window Activation and Command/URL) stopped working | ||
|---|---|---|---|
| Product: | [Unmaintained] khotkeys | Reporter: | ken manheimer <ken.manheimer> |
| Component: | general | Assignee: | Lubos Lunak <l.lunak> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | antonio.bulgheroni, benji.weber, berni, bluedzins, chemobejk, dbroome, kde, matthew.r.blissett, rdieter, stefnn |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Ubuntu | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
ken manheimer
2008-06-30 19:46:41 UTC
some followup notes: 1. i tried creating some custom shortcuts from a clean setup, including from a a brand new account. i found that the first shortcut i created worked, and the second and subsequent didn't. (both first entries were Activate Windows, one for an emacs window and one for konsole. both seconds, in the separate accounts, were Activate Windows for the opposite of the first - konsole and bash, respectively. neither seconds worked. both thirds were Command/URL launches - emacs - and neither thirds worked.) 2. looking at ~/.kde4/share/config/kglobalshortcutrc, i notice that editing an existing entry creates new lines in the config file, with different uuids. i doubt this is correct behavior. looking over some existing kglobalshortrc files, i notice myriad duplicate entries with different uuids. in short, something is really fubar. Point 1. Don't know. It worked in 4.0? ... not for me. Point 2. That right. That isn't correct behavior but it's the design of this application. khotkeys doesn't know how to change an existing entry. I recreates and deletes them. That worked for kde3 but with the changes made to global shortcuts in kde4 it will not work. Sorry. That's one of the reason i started a redesign. Lubos .. i more that once said khotkeys should be removed in it's current state from kde4. How about we do that and activate my khotkeys-redesign branch. It has global shortcuts working but needs some love. It will never get it as long as it's not part of trunk and i'm unwilling to work on trunk. As i'm the only one willing to work on khotkeys that means the current situation means we have a deadlock. I would bring the missing features back step by step. Mike Growing number of shortcuts in kglobalshortcutrc - I consider that to be a problem of the kdelibs shortcuts code, it should allow not storing some shortcuts there, since it's pointless. It is not specific to khotkeys, kwin's per-window shortcuts have the same problem. As for using your branch, I don't think that's possible for 4.1, due to freezes. After 4.1 is branched, I have no problem with that. For 4.1, if 4.0 version worked, it might make sense to simply revert to that version. i cannot confirm that using the 4.0 version would work mixed with the rest of my kde 4.1 beta 2 install. i *am*, however, running the kde 3.x khotkeys version, which happens to reside in /usr/bin/khotkeys in my kubuntu (4.0.8) kde 4 install, and it seems to work fine. it's a pain to have to stop the kde4 version and start the kde 3 one, and use the old kcontrol to change settings, but at least it does what it's supposed to do. so, if the khotkeys version in kde 4.0 is the same as the kde 3.x version (except for where it puts the config files, etc), and you don't have the option to release a fully functional new version with kde 4.1, i'd ask you to revert and wait to release the new version when it's fully operational! the one included in the kde 4.1 betas is worse than useless, from an end-user point of view. (i don't want to discourage improvement of khotkeys, by the way! it sounds like the rework is aimed at making it more maintainable, which might possible addition of some features i would dearly like to see. i'm unclear what michael jansen is suggesting re "hotkeys should be removed in it's current state from kde4" and all the stuff about "not part of the trunk" and "unwilling to work on the trunk", but i'm hoping he's not suggesting leaving khotkeys out until the redesign is complete, or including a partially working one while it's being completed?) incidentally, should this bug report be marked as "confirmed" if everyone agrees that the version of khotkeys released with the kde 4.1 betas is broken as i reported? *** Bug 166120 has been marked as a duplicate of this bug. *** Possible duplicate (as William spotted): http://bugs.kde.org/show_bug.cgi?id=160892 aargh! kde3 khotkeys works, but kde4 khotkeys DOES NOT. leaving a broken one there is worse than removing khotkeys entirely, because it cause misunderstanding and grief from the people who try to use it, and for many of us, lacking the functionality entirely would be a reason to abandon kde. why is this not getting priority attention? i recommend that everyone who's voted for this report vote for the one at http://bugs.kde.org/show_bug.cgi?id=160892 and vice versa. For me the current situation is (kde 4.2 beta 2 on gentoo): hotkeys do not work on startup. if i do qdbus org.kde.kded /kded org.kde.kded.unloadModule 'khotkeys' qdbus org.kde.kded /kded org.kde.kded.loadModule 'khotkeys' Hotkeys work for a while ... until they stop working sometime again. In current trunk (around version 926720) i implemented all input actions except the generic action type. Everything should work expect the "keyboard input action" when use to send more than say alt+x. Most importanty mous gestures, window actions and window triggers work. All of that will go live with kde 4.3 . Help making it really work before by using your kde 4.3svn packages. It looks like not many people running trunk regulary use this module. Should work in trunk. Please open new detailed bugs if not. |