What to do about KShortcutsEditor and undo

Andreas Hartmetz ahartmetz at gmail.com
Tue May 20 01:49:59 BST 2008

Hi all,

yesterday Michael Jansen sent me a patch containing better unittests for 
global shortcuts and some more ideas about global shortcuts. We had a 
discussion and I took some time to think about the topic some more.
I came up with the following plan:

-Add setUndoCheckpoint() to KShortcutsEditor so that KControl modules can call
 it when asked to save configuration. Calling KShortcutsEditor::undo() will
 then only undo to the state at the checkpoint.
-Remove automatic undo in KShortcutsEditor on destruction, it's not a very
 good idea if only for the reason that it crashes if the actions are destroyed
 before the editor. This actually happens in the KWin effects config modules.
 KControl modules should call undo() on their destruction when the 
 actions are still alive. KShortcutsDialog could make use of the new 
 functionality without changing its observable behavior, I think.
-Remove (if no protests, otherwise deprecate)
 KGlobalAccel::overrideComponentData(). It was conceived as a special-case 
 hack for KControl modules (which configure actions that they don't "own");
 KActionCollection::setComponentData() can replace it and it will be more 
 consistent and generally applicable. Credit to mjansen for pointing this out. 
 overrideComponentData() is only used in kdelibs and kdebase, according to  
-Port the affected KControl modules (a small amount of work) that are not 
 working very well at the moment anyway, with crashes and no undo as people
 are used to in KControl modules.
-Actions need to be turned into dummies by KCMs so that their global shortcuts 
 wont't be marked as "absent" when the corresponding actions are destroyed.
 At the moment this is implemented by calling  
 KAction::setProperty("isConfigurationShortcut", true) which is not optimal
 but no worse than KGlobalAccel::overrideMainComponentData() which caused
 special behavior to the same effect.

There are some more details but this mail is long enough already.

Sorry for bringing this up right after the feature freeze. I didn't realize 
the potential of KActionCollection::setComponentData() and that/how undo 
could be made to work as it should. It's more of a bugfix actually - see the 
next to last point, KControl modules not working.
After implementing this plan the issues should be settled. AFAICS we'd have 
all the necessary features and hopefully no desirable but missing 
functionality anymore. Reply if you think otherwise.
Uh, I'm somewhat ashamed that this took so long. I did other things in the 
meantime :/


Flint Paper is insane. I really respect that.

More information about the kde-core-devel mailing list