[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: Re: KDED Modules and their DBus Path
From: Michael Jansen <kde () michael-jansen ! biz>
Date: 2008-04-22 20:24:15
Message-ID: 200804222224.16530.kde () michael-jansen ! biz
[Download RAW message or body]
> 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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic