Welcome to this readme about KDED. KDED stands for KDE Daemon which isn't very descriptive. KDED runs in the background and performs a number of small tasks. Some of these tasks are built in, others are started on demand. Built in tasks ============== *) Checking for newly installed software and updating tdesycoca when new software is detected. Updating of tdesycoca is done by the program tdebuildsycoca which gets started by kded. When kded is first started it always runs tdebuildsycoca to ensure that tdesycoca is up to date. *) Checking for newly installed update files. Applications can install *.upd update files. These *.upd files are used to update configuration files of users, primarily when new versions of applications are installed with (slightly) different configuration file formats. Updating of configuration files is done by tdeconf_update. kded starts tdeconf_update when it detects a new update file. When kded is first started it always runs tdeconf_update to ensure that it has not missed any update files. tdeconf_update keeps track of which update files have been processed already in the config-file tdeconf_updaterc. It only performs a certain update once. *) Checking for hostname changes. It is a really bad idea to change the hostname of a running system and it usually only happens with incorrectly configured dial-up connections. Never the less, kded will check for hostname changes and if it detects one it will make the necassery changes to the KDE environemnt and X-server to allow continued proper operation. The program kdontchangethehostname is executed to make the actual changes. Configuration of built in tasks. ================================ The built in tasks have some configuration options that can be changed by editing the kdedrc configuration file. Changes need to be made with a text- editor, there is no GUI available. All options are listed under the [General] group: HostnamePollInterval: This can be used to adjust the time interval at which the hostname is checked for changes. The time is specified in milliseconds and has a default of 5000 (5 seconds). CheckSycoca: This option can be used to disable checking for new software. tdesycoca will still be built when kded starts up and when applications explicitly request a rebuild of the tdesycoca database. The user can also manually rebuild tdesycoca by running the tdebuildsycoca program. The default value of this option is "true". Checking can be disabled by setting this option to "false". CheckUpdates: This option can be used to disable checking for update files. tdeconf_update will still be run when kded starts up. The default value of this option is "true". Checking can be disabled by setting this option to "false". CheckHostname: This option can be used to disable checking for hostname changes. The default value of this option is "true". Checking can be disabled by setting this option to "false". Example kdedrc file with default values: [General] HostnamePollInterval=5000 CheckSycoca=true CheckUpdates=true CheckHostname=true If FAM or DNOTIFY is not available, the filesystem will be polled at regular interval for any changes. Under the [DirWatch] group in the kdeglobals file the following options are available to adjust the polling frequency: PollInterval: This can be used to adjust the time interval at which the local filesystem is checked for new software or update files. The time is specified in milliseconds and has a default of 500 (0.5 seconds). NFSPollInterval: This can be used to adjust the time interval at which remote filesystems, such as NFS or Samba, are ebing checked for new software or update files. The time is specified in milliseconds and has a default of 5000 (5 seconds). The above options are not used when FAM is used to watch for changes in the filesystem, or when DNOTIFY is used. Specifying larger intervals may reduce the CPU load and/or network traffic. Shorter intervals are not recommended. Please note that in previous versions of KDE these options where listed in the tderc file. Example kdeglobals fragment: [DirWatch] PollInterval=500 NFSPollInterval=5000 Tasks loaded on demand ====================== Some things can be greatly simplified if they can be coordinated from a central place. KDED has support for modules that will be demand-loaded whenever an application attempts to make DCOP call to the module. This can be useful for central administration tasks. An example of a KDED module is the print module. When an application prints a file, the print module will watch over the print-job while the file is being printed. This allows you to close the application after submitting your print-command to the printer, the print module will make sure to inform the user when a print problem occurs (printer out of paper, printer on fire) A KDED module should install a .desktop file with ServicesTypes=KDEDModule A KDED module will be loaded on KDE startup if it has a line X-TDE-Kded-autoload=true Note that this flag doesn't cause the module to be loaded if the KDE desktop is not running (i.e. when running a KDE application in another environment). Normally KDED modules are loaded whenever they are accessed, so you don't need autoloading enabled. On demand loading can be disabled by putting the following line in the .desktop file: X-TDE-Kded-load-on-demand=false Further it should contain: X-TDE-ModuleType=Library X-TDE-Library=foo X-TDE-FactoryName=foo Which means that kded_foo.la is the name of the library that contains the module and KDEDModule *create_foo(const QCString &) is the factory function that should be called. The .desktop file should be installed to ${kde_servicesdir}/kded