If a client requested both listen and search, on listen off on the device,
the discovery was stopped too which lead to some unbalanced state in
the client.
Tuhi is not a permanent storage for drawings, this needs to be handled by the
client(s). To make sure no-one is tempted to use it as permanent storage,
always delete all but the last 10 drawings on startup.
Fixes#45
Spark is the past, Slate is the future.
Spark seems to have its own protocol, while the Slate and the Folio are
supposed to have the same firmware. We should probably make Spark the
exception than the other way around.
Relying on the name is a bad idea because:
- the Wacom Inkspace app asks the user to change the name of the device
on pairing
- the FW should be slightly the same between generations (Folio and Slate
vs Intuos Pro Paper edition vs Spark)
It appears the Spark doesn't have the "Mysterious characteristics"
mentioned here. And this characteristics seems to send a wacom-like
protocol when pairing to the device or from time to time.
Attempt to differentiate between the Spark and the rest based on that
so we can hope to support the Folio too, and maybe the Intuos Pro Paper
Edition.
Let's the developers of tuhi to consume more energy in their monitor
to light up more pixel when displaying single quotes whereas double
quotes.
It also makes the whole bit more uniform.
Fixes#32
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?)
fix ca82af78de ("tuhi: handle cold-plugged devices").
The point of deciding whether a device was in the pairing mode was actually
ignored when building the list of available devices.
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
If we're losing the bus name (i.e. we can't get it on startup) there really
isn't much we can do other than fail miserably. But in passing signals around
we can't do exceptions, so we have to move the mainloop to Tuhi so we can
quit() it on error.
Fixes#25
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.
TuhDevice.paired is set on every device update (RSSI changes!) and that sends
a GObject.notify() for the property. Filter those, otherwise
we're just spamming dbus with PropertiesChanged notify events even
though nothing has actually changed.
We likely get multiple 'udpated' notifications as the RSSI property changes,
all causing a Connect() on the device and an ugly error message (that we used
to catch and print). Make that error message prettier.
When bluez restarts (or the tuhi daemon restarts), the values we have
in the bluez device's field ManufacturerData are quite not accurate.
When bluez restarts they are empty, and if the last time we saw the
device was for the pairing process, the device will still be marked
as in the pairing mode.
So we should mark the cold-plug sequence differently from the hot-plug
one, and we should be more confident in the current configuration we
have stored to export the currently known devices over dbus.
Fixes#13
If the sender disappear, we should stop listening for incoming events.
We match the Start/StopListening() that way, but if a client forgets
to call StopListening() before leaving and some data are being retrieved,
it's not our problem.
This implements the ListeningStopped signal (especially the EAGAIN if we're
already listening) but does not yet actually trigger the listening on the
device.
There is still no timeout, and no signal gets emitted.
The current way of testing this is:
- call StartListening() on the DBus device
- start discovery on the adapter by some other mean
- press the button on the device -> the sync will happen
- call StopDiscovery()
- press the button on the device -> the sync will *not* happen
If the index is not valid, a python exception was raised, and the dbus
message was left without and answer.
Coincidentally, this matches the documentation
Benjamin Tissoires