The previous process had a problem: the device object didn't exist until after
pairing was complete. But to pair we need some user interaction (press button
on device) and thus the ability to send notifications from the device to the
dbus client at the right time. This wasn't possible with the previous
approach.
The new approach:
* renames Start/StopPairing to Start/StopSearch to indicate we're just
searching, not pairing in the manager
* creates a org.freedesktop.tuhi1.Device object when a suitable device is
found. That object is not in Manager.Devices, it's "hidden" unless you know
the object path.
* Sends a PairableDevice signal with the new device's object path
* Requires the client to call Pair() on the device
* If the timeout expires without pairing, the device is removed again
./tuhi/dbusserver.py:55:1: E302 expected 2 blank lines, found 1
./tuhi/dbusserver.py:75:17: E126 continuation line over-indented for hanging indent
./tuhi/dbusserver.py:77:29: E203 whitespace before ':'
./tuhi/dbusserver.py:155:13: E126 continuation line over-indented for hanging indent
./tuhi/dbusserver.py:156:17: E131 continuation line unaligned for hanging indent
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
bus_own_name is asynchronous, so we first need to send a signal back and then
we can start connecting to the devices. Otherwise we'll have to implement a
queue which would be a lot harder than just waiting.
Peter Hutterer