ToolBarHandler uses the KConfig file instead of .rc files to store
shortcuts. When refreshActionProperties() is called, it removes all
shortcuts, and sets shortcuts according to the scheme, and then
user-defined shortcuts from .rc file. This change makes it restore
KConfig shortcuts also.
With this commit, user-defined KConfig shortcuts persist across
schemes instead of being reset. Ideally these shortcuts should also be
scheme aware, but that change is out of scope.
CCBUG: #429743
As far as I can see we're only saving a merged menu when coming from
KEditToolBarWidgetPrivate::initOldStyle where we merge with the global
file (there we create the XmlData as XmlData::Local) but we are not
merging the files if we come from
KEditToolBarWidgetPrivate::initFromFactory (where we create the XMLData
as Part or Shell)
Fixes the infamous bug of "No Text" in the Okular menus.
Konqi's shadow is a hardcoded fully opaque color. The light gray works
fine in light mode, but is way too light for typical dark modes,
including Breeze Dark.
Instead of getting the light gray by using an opaque light gray, use a
transparent dark gray - this gives identical results on regular Breeze,
but only makes the shadow a little lighter on Breeze Dark. It also works
fine on colorful backgrounds, as it blends in better with the color.
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
Pointers never intended to be changed, so have the compiler assist that
intention as well as ensure the human reader to expect the usual pattern.
Also add an explicit "public:" to the begin of the data member listing,
for better overview of functions and data.
setupActions() reconnects to the menu every time it rebuilds, which happens on
every clientAdded. In Konsole that is every tab switch, so the connections pile
up: opening the Settings menu then runs setupActions() - and its recursive
findChildren<KToolBar*>() over the whole window - once per accumulated
connection. After a day of use that takes seconds.
l10n daemon script