no way the grab failed or something other than KGlobalAccel grabs the
shortcut by force from KGlobalAccel, right?
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
now to figure out if importing of action collections settings should be
magic or done by a KShortcutsEditor::importConfiguration() call (there is
only one place where it is called, see kwin/kcmkwin/kwindesktop/main.cpp)
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
kinda hack tho but makes it easier to distinguish between main and plugin
action collection shortcuts, if there is only one top-level item it should
not be visible (decorated) for cases like kwin KCM but this will be done
later on
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
global shortcut resolution (the KGlobalAccel methods) work on
application level, X11 as far as I can tell does not have a method to
tell which application has grabbed a key (to fill KGlobalShortcutInfo).
other than that no configuration interface for global shortcuts (not by
KGlobalAccel itself, plasma and its applets have interface for that),
also the shortcuts interface did not and still does not handle global
shortcuts well so that is something to look into.
one of the problems solved with this change is the fact that multiple
plasma applets (e.g. multiple instances of the keyboard applet) could
not use the same shortcut, now it is possible. as for which applet gets
the shortcut action it is the one that has the grab first - that is how
key grabbing works in X11
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
no point in passing around windows to kded4 or its modules, job UI delegate
windows are different thing tho
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
only one use of it, in the case it was used for what the message is trying
to tell is the least concern (the system would be missing basic MIME data)
which means someone messed up at some level (shared-mime-info is required)
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
does totally different thing tho - the old method was reloading the
configuration of Plasma::RunnerManager while this one reloads the
configuration of the loaded runners. it is a convenience method still that
should not be used as runners are matching for obvious reasons
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
unless there are runners loaded that may have to be unloaded for example,
that way the initial loading of runners will be delayed until the first
query
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
performance gain for the runners, there should be no duplicates and even
if there was the only thing that was done about it is to print a debug
message when build for debugging
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
Plasma::RunnerManager::matchesChanged() is now emitted when new matches
arive, Plasma::RunnerManager::queryFinished() when matching is done (all
match jobs finished)
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
nothing but the manager is supposed to remove matches and there is a
Plasma::RunnerContext::reset() method
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
