So using: registerShortcut("ScriptTest1", "test", "Meta+C", function () { ... }) This works fine as long as Meta+C is not already bound and leads to an entry in kglobalshortcutsrc: ScriptTest1=Meta+C,Meta+C,cool However if I run it a second time with a *different title*: 1. The keybinding doesn't work. 2. registerShortcut doesn't let the script know the keybinding won't work. 3. A non-working entry is added to kglobalshortcutsrc So for example if I change ScriptTest1 to ScriptTest2 and run the script again I now have two entries of the following format: ScriptTest1=Meta+C,Meta+C,cool ScriptTest2=,Meta+C,cool Further additions will all follow the ",Meta+C" format and not work. However if I go back and use the original title ScriptTest1 then the keybinding will work again. Reproducible: Always Steps to Reproduce: 1. Register a shortcut with an unused key-sequence using the title "title 1" 2. Register a shortcut with the same key-sequence as before using the title "title 2" Actual Results: The key binding will only work the first time the script runs. Expected Results: Maybe "registerShortcut" should throw an exception when it can't register a shortcut and maybe it shouldn't add these extra entries to kglobalshortcutsrc
I mark it as a duplicate of your other bug report. As mentioned there the shortcut system sucks. Nothing we can do in KWin about it. We don't even know whether the shortcut is registered or not. *** This bug has been marked as a duplicate of bug 318379 ***
few notes on this: a) it's possible to determine whether a global shortcut is taken (by another component) b) it's necessary to actively "forget" global shortcuts - otherwise they stay forever. Reg. scripting i'd say it will be required to a) tell the script that assigning the shortcut is not possible (you'd otherwise have the "shortcut already taken blablah. wanna steal blablubb?" dialog) b) wipe all global shortcuts of a script w/ unloading them (ie. it will not be possible to configure the shortcut via the keys kcm and have that setting after a restart) b.1) therefore make the global shortcut inconfigurable. That's in a way limiting for scripts (they cannot dynamically occupy a shortcut, nor keep it configured) but probably unavoidable due to their nature - also it's possible to "configure" the shortcut right within the script.
WRT to your "b" and "b1" I'd also considered that. However due to the fact that "registerShortcut" will overwrite the shortcut with the same name in effect it isn't possible for the user to re-configure kwin script shortcuts? Therefore I'd suggest either: 1. Leave things as they are now BUT have the shortcut API not change the existing key sequence if the key binding already exists. CONS: User has to actively remove shortcuts that were assigned and no longer being used. PROS: User can redefine keybindings made by scripts even when script is not running. 2. Remove script bindings on script shutdown - CONS: User can reconfigure script-created key-bindings but they will be lost on restart (maybe can provide work-around?), PROS: Does not force as much burden onto user to maintain shortcuts. BTW, should the status of this bug be "RESOLVED/DUPLICATE"?
> That's in a way limiting for scripts (they cannot dynamically occupy a > shortcut, nor keep it configured) but probably unavoidable due to their > nature - also it's possible to "configure" the shortcut right within the > script. It's too limiting for things like Present Windows 2.
(In reply to comment #4) > It's too limiting for things like Present Windows 2. "iAmAReasonableDeveloperAndKnowWhatImDoingAndPromiseToCleanupShortcutsMyselfAtTimes();" ;-) iow - we'd have to move full shortcut management to scripting then and eventually provide different functions to registerShortcutTemporarily(, bool temp = true)
(In reply to comment #3) > CONS: User has to actively remove shortcuts big fat con - afaik there's absolutely no GUI support for this, ie. one had to edit the kdeglobals rc (also it's a usability fail, users cannot really know whether or not they will or not need some global shortcut or why it constantly re-appears after deleting it etc.) > CONS: User can reconfigure script-created key-bindings but they will be lost on restart see Martins comment. -> we'll need a temp parameter, allowing to assign them permanently - and also allow the script to delete shortcuts (eventually doing so on uninstall?)
Cool, can you create an issue to track that since this one is marked "resolved" or is this too low priority for an issue?
-> Bug #318422