Review Request: Use in-memory dom document when editing toolbars, to allow for dynamic changes
David Faure
faure at kde.org
Tue Sep 22 19:38:22 BST 2009
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1694/
-----------------------------------------------------------
Review request for kdelibs.
Summary
-------
Users of KXmlGuiClient::setDOMDocument probably noticed that the dynamic changes
made to the guiclient's XML, where not taken into account in KEditToolBar.
This is because KEditToolBar loads the XML file again from disk, rather than using
the in-memory XML tree. (And this in turn is probably because in KDE3, we had
KXMLGUIClient::conserveMemory which got rid of the in-memory xml tree, but we removed
it for KDE4 because it broke any kind of dynamic changes like action lists, plugins etc.)
So the fix is simple: using the in-memory domDocument() instead. The question is what
it breaks. I noticed that the ui_standards.rc merging left the name and version attributes
of ui_standards.rc into the toplevel tag -- fixed in r1026838.
If your app does unusual stuff around xmlguiclients and/or toolbar editing, please
test this patch before I commit it.
The reason for all this is bug 207296, but surely I'm not the first user of setDOMDocument.
I see that knotes, kopete, and kross use it already, at least.
This addresses bug 207296.
https://bugs.kde.org/show_bug.cgi?id=207296
Diffs
-----
trunk/KDE/kdelibs/kdeui/dialogs/kedittoolbar.cpp 1025321
Diff: http://reviewboard.kde.org/r/1694/diff
Testing
-------
Editing toolbars in kontact, konqueror, kate.
[found an unrelated bug while testing in konq, the Tools menu moves to first position, even w/o the patch...]
Thanks,
David
More information about the kde-core-devel
mailing list