"pair" is alrady taken by Bluetooth and since we have a bluetooth device here,
it can cause confusion. Use "register" instead, with an explanation in the
README for the more paranoid of us.
Fixes#67
And let us handle the local time zone conversions in the client, because
having timestamps in localtime in the daemon is confusing and error-prone (how
is the client supposed to know what localtime was?)
As we're planning to cache the data locally, the timestamps are a
unique-enough way that makes it possible to access a specific drawing.
And this way we can also delete some drawings without all other indices
shifting around.
Fixes#16
Basically copied from the device's Listening approach.
While it's possible to have multiple clients searching at the same time it's a
niche case and the effort at fixing the race conditions that come from that is
likely not worth the effort.
Let's add multiple simultaneous clients when we have a real need for it.
We need to be able to selectively enable/disable listening mode per
device, and the Listening property needs to be updated.
The current approach uses a Listening property as a public state, and the
StartListening()/StopListening() calls to start/stop. The ListeningStopped
signal is just there to carry error codes.
The current design only allows for a single client to trigger listening,
anyone else will see -EAGAIN and has to wait for the property to update.
The coordinates are provided from the top-left position, but the sensor
is effectively turned. So on the Spark and the Slate, X goes down, and
Y is reversed and goes left.
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
Peter Hutterer