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
Because we're totally going to ship tuhi in embedded devices that are going to
be in use until after 2038 when time resets to zero, the world goes big bang
and the only survivers will be 64-bit species. Or something like that. Either
way, the API documentation already said so anyway and the DrawingsAvailable
property is already 64 bit too.
Semi-confusingly: the dbus 64 bit unsigned type is 't', it doesn't stand for
'timestamp'.
"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
While running the app in flatpak, there are a few deprecation warnings
coming in:
PyGIDeprecationWarning: GObject.SIGNAL_RUN_FIRST is deprecated;
use GObject.SignalFlags.RUN_FIRST instead
PyGIDeprecationWarning: GObject.property is deprecated;
use GObject.Property instead
PyGIDeprecationWarning: GObject.MainLoop is deprecated;
use GLib.MainLoop instead
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
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.
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
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>
Peter Hutterer