Propagated whenever we start talking to the device (and then again when we
stop). The purpose of this signal is merely that a UI can show e.g. a progress
bar while we're talking to the device to ensure the user something is
happening.
Fixes#138
Export the supported versions in a Manager property and require the client to
request a specific version in GetJSONData. Without that, the server could
never update the format and clients would have to support every single
historical version to make sure they can run against any version server.
Fixes#98
"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