Passing arguments to an already open KCM

KCMs can be launched within different applications (systemsettings, kcmshell, app KCMs, shortcuts from plama applets, KCMultiDialog, etc). Launching the same module twice is forbidden to avoid different instances messing with each other configurations.

This is technically done in KCModuleProxy by registering a dBus service with the module's name, and checking if it has been registered before. If that's the case, we currently load a dummy KCM (KCMError) informing the user about it instead.

I see two main problems with this approach:

• It's a bit cumbersome for the user to manually go check where the kcm is open. Of course in places like systemsettings it still makes sense to show the dummy KCMError, so there no empty.
• Some kcms do accept arguments, but they can only be passed on KCM constructor. There's no entry point for arguments after that.

The use case I'm trying to solve is about updating the kwinrules kcm (plasma/kwin!134 (merged)), but there can be potentially more kcms benefiting from this.

I've implemented a solution I'd like to have some feedback about. It affects several repos which might be more difficult to follow, hence this issue to have a more ordered place to discuss about the API and workflow:

a) On the new KCM instance:

1. KCModuleProxyPrivate::loadModule() gets called and tries to load the method.
2. It detects that a valid dBus service has been already registered, and calls updateArguments(args) on that dBus service. (!27 (closed))
3. If it's an standalone dialog, get closed.
4. If it's inside another container (ex:systemsettings) show the dummy `KCMError

b) On the previously open KCM instance:

1. KCModuleProxy receives the dBus call updateArguments()
2. KCModuleProxy emits the signal KCModule::argumentsUpdated(args) (kconfigwidgets!26 (closed))
3. For QML KCMs, this signal is forwarded to ConfigModule::argumentsUpdated(args) (kdeclarative!28 (closed))
4. The KCMs custom code processes it. This is opt-in, as the signal has to be connected previously. (plasma/kwin!134 (merged))

COMMENTS/QUESTIONS:

• [a2] The dBus method name could be something more general
• [a3] I haven't fully solved this part, as KProxyModule::reportError should take care of it but somehow it doesn't for me.
• [b2/b3/b4] I feel like this should be a slot instead of a signal, but that was generating MOC problems on inherited classes.

Sorry if this explanation was way too verbose or maybe unnecessary.