Bluedevil-KDED in kdereview
alex at eyeos.org
Mon Apr 12 23:43:08 BST 2010
After a month of hard work designing the new Bluetooth stack for KDE (and
starting coding it), we're glad to move to review the first step of what we
hope becomes the new KDE Bluetooth Integration.
The code we are moving is a KDED, since we know that the less kdeds we have
the better, I'd like to explain why we need this one.
Basically we need a daemon that checks if there are BT interfaces, and if so
enable/disable a couple of services.
For example we don't want to have a "Bluetooth agent" when we have no plugged
adapters, but in the same way we want to "autolaunch" the agent if an adapter
is plugged. This is why we need the KDED.
So, as I said the KDED actually only loads/unloads services, and those
services are called helpers. Right now we have 2 helpers, the Agent and the
"Receive files" (in theory we are not going to have more than those).
The Agent remains quiet offering a dbus interface which is called by bluez
when it needs some user interaction. It's executed in the same KDED process
but in a thread, the thread is sadly needed because of the Bluez Design :/
The user interaction tough is splitted in a few small binaries which are
executed when needed.
The agent is used by bluez for example when:
-A device wants to reconnect
-A device ask for a PIN
-The mode has been changed and the user should be notified
(For example from flight to home mode, powersaving stuff)
The receive files help is much bigger than the agent, and because of this
we've taken another approach. The receive file is a dbus service which is
launched when a bluetooth adapter is available, and stopped when not - the
dbus service process actually stops after a timeout of 10secs at the moment.
And what does it do? The receive files dbus server listens for receive file
petitions and handles them.
More information about the kde-core-devel