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
lxr.kde.org.
-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 :/
Cheers,
Andreas
--
Flint Paper is insane. I really respect that.
More information about the kde-core-devel
mailing list