Friedrich W. H. Kossebau
ccc747d718
The manual client reset in KXmlGuiWindow::saveNewToolbarConfig() was broken in 2 ways: a) it duplicated the work already done by KEditToolBar, which on apply/ok as needed already applies the changes to all clients by calling KEditToolBarWidget::rebuildKXMLGUIClients() b) it would only reinsert the client of the shell/main window, not any other possibly existing KXMLGUIClients, which results in that being appended to the end of the list in the factory. So on any next UI rebuilding by at least KEditToolBar things go wrong as the order of clients at least when it comes to the first/main client assumes the first is the snell/main client, to be matched against the UI standards file. Removing the duplicated reinsertion fixes this. As the API of KEditToolBar specifies how to use this slot, and all known existing usages in KDE code in their reimmplementations follow that and call this method as first thing, changing the behaviour here by not reinserting the main client at all should be acceptable. Also extend the API docs of saveNewToolbarConfig() with some more related information. BUG: 442179 FIXED-IN: 6.30
KXMLGUI
Framework for managing menu and toolbar actions
Introduction
KXMLGUI provides a framework for managing menu and toolbar actions in an abstract way. The actions are configured through a XML description and hooks in the application code. The framework supports merging of multiple description for example for integrating actions from plugins.
Kiosk
KXMLGui makes use of the Kiosk authorization functionality of KConfig (see the KAuthorized namespace in that framework). Notably, QAction instances added to a KActionCollection are disabled if KAuthorized::authorizeAction() reports that they are not authorized. The items on the standard help menu (KHelpMenu) can likewise be disabled based on Kiosk settings, and toolbar editing can be restricted.
See KActionCollection, KHelpMenu and KToolBar documentation for more information.