Hi kdehackers! 
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).

Agent:
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)

Receive files:
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.