KDED Modules and their DBus Path

[Michael Jansen]

> You can -also- register those daemons under that name; the dbus
> registration is not unique per-process. Just register khotkeys (since I
> guess this is what this is about :) as org.kde.khotkeys in the khotkeys
> code (independently from the automatic registration of the kded module).

I knew that. My questions stems from the fact that i have been thinking about 
switching an implementation from a kded module to a standalone daemon quite 
often. Because of KDE_MULTIHEAD to be precise.

khotkeys hat those problem when using KDE_MULTIHEAD. You couldn't call that 
interface in a way it would work for both.

Making sure kdedglobalaccel and khotkeys can switch their implementation would 
give as more flexibility to make KDE_MULTIHEAD support real later.

> One reason for the org.kde.kded /modules/<modulename> naming is that it
> allows the autoload feature of kded to work (just make a call to a module
> and it will be loaded if necessary).

That i didn't knew. But that is only of interest for autoload enabled modules. 
And again. I don't like that we expose a implementation detail for this 
purpose. 

A method like 'gimme service xyz, however that is implemented' would be my 
preferred solution. Is it possible to register a standalone daemon under 
/modules/<modulename> ?

But as i said. It worked before, so i don't think it will be a big problem 
tomorrow.

Mike

-- 
Michael Jansen
Available for contract work ( Development / Configuration Management )
http://www.michael-jansen.biz