# Namespace KSettings.Dispatcher

Module | kutils
Namespace | KSettings.Dispatcher

Dispatch change notifications from the KCMs to the program.

Since your program does not have direct control over the KCMs that get loaded into KSettings.Dialog you need a way to get notified. This is what you do:

    Dispatcher.registerComponent(componentData(), this, SLOT(loadSettings()));

Author Matthias Kretz <kretz@kde.org>

### methods

- componentNames ( )

  returns QList<QString>

  Returns a list of all the componentData names that are currently registered

- configForComponentName (componentName)

  returns KSharedConfig.Ptr

  Argument | Type | Default
  --- | --- | ---
  componentName | QString |

  Returns the KConfig object that belongs to the componentName

- registerComponent (componentData, recv, slot)

  returns Nothing

  Argument | Type | Default
  --- | --- | ---
  componentData | KComponentData |
  recv | QObject |
  slot | char |

  Register a slot to be called when the configuration for the componentData has changed. componentData is the KComponentData object that is passed to KGenericFactory (if it is used). You can query it with KGenericFactory<YourClassName>.componentData(). componentData.componentName() is also the same name that is put into the .desktop file of the KCMs for the X-KDE-ParentComponents.

  componentData - The KComponentData object

  recv - The object that should receive the signal

  slot - The slot to be called: SLOT( slotName() )

- reparseConfiguration (componentName)

  returns Nothing

  Argument | Type | Default
  --- | --- | ---
  componentName | QString |

  Call this function when the configuration belonging to the associated componentData name has changed. The registered slot will be called.

  componentName - The value of X-KDE-ParentComponents.

- syncConfiguration ( )

  returns Nothing

  When this function is called the KConfig objects of all the registered instances are sync()ed. This is useful when some other KConfig objects will read/write from/to the same config file, so that you can first write out the current state of the KConfig objects.