The 'searching' notification was only emitted when it goes to stop, which
means we do not get notifications when it starts.
This makes SearchStopped signal redundant for the generic case, but allows
to get notifications if the search failed to start.
Rest is just making sure we have the same handling of events in Listener
and Searcher.
If stop() is called more than once, we might try to disconnect the
signals more than once, which raises some errors.
Better having one central place that handles the disconnect properly.
A device isn't registered or not, it's merely in a *state* of being
registering or not. Pass the current mode down to the TuhiDevice instead of a
boolean for 'registered'. The 'registered' gobject property is left in-place
for now, the dbus server needs it.
An 'event' boolean is less than obvious ('is-event' may be better). This
signalled the difference between a device-added during Manager startup and the
device-added at runtime (i.e. device goes online).
We don't need that differentiation. The manager adds all existing devices
immediately after connnect_to_bluez(). All we have to do is run through the
device list, add them locally and then subscribe to the signal.
This keeps the is-event confusion within one file only instead of spreading it
across two and an internal API. And we can re-name it to hotplugged.
Calling listen on an unregistered device currently triggers a register on the
device. This can happen when the device has been registered but the
ManufacturerData has not yet been updated.
Disentangle this by only calling the right function based on what we're trying
to get. This also requires that the connected/disconnected signals are only
handled when we're actually trying to do something with them.
Fixes#79 (multiple patches required)
Previously, we set self._mode and used that to determine what connection to
attempt. This can sometimes lead to a device attempting to register in
response to a listen() request (and vice versa).
Make this dependent on the caller arguments only. So when listen() is
requested do exactly that and generate the right exception if the device is in
the wrong mode.
Fixes#79 (multiple patches required)
We only ever used it in conjunction with vendor_id, so we can just make this a
normal property and send GObject notifies when it changes. This allows us to
listen for the MD to change when it finished registration.
[BT: do not add the second indirection by calling vendor_id]
Fold register_connection into register_device and (with comments) handle the
spark and slate here. This makes it easier to handle the Intuos Pro paper
later.
During the first attempt to register, we might not know before hand
the protocol of the device. Have a special class for it, and then
instantiate the correct protocol before continuing.
This makes the 'Protocol' entry in the config file mandatory
The Slate is more recent than the Spark. We better have the Spark as a
base class that we will never touch again and make the Slate depend on it.
When adding the Intuos Paper, we should make it a subclass of the Slate,
as the 2 protocols are similar.
The Intuos Pro Paper is close enough to the Slate but with some
subtleties. Instead of having a bunch of ifs, let's have nice subclasses
for the differences in the protocol.
We are already handling 2 protocols, one for the Spark, and one for
the Slate. That's one too many, and given that there are some subtleties
in the Intuos Pro Paper (see #56), we better start splitting the protocol
from the interface, so we can have different protocols for different
devices instead of having a bunch of 'ifs'
The Intuos Paper uses a different one, because of course it does.
The 'company ID' from the Paper will be added while adding support for it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This isn't something we need in the daemon, it depends too much on what the
client expects so let the client save this data and handle the rotation
accordingly.
Note that the sensor in Sparks and Slates is in landscape format, i.e. every
picture is 90 deg rotated from what you'd expect.
Fixes#33 (wontfix)
Instead of failing with a syntax error on format strings, actually bail out
instead. Likewise for setup.py, require 3.6 and add this to the classifiers
too while we're there.
Related to #71
To be able to run tuhi-kete, we need a tuhi server running. Provide a
script that spawns one if none is running.
Running simple 'python3 setup.py --install' started to go havoc by
complaining that /app/lib/python3.6/site-packages/easy-install.pth
was read-only.
The solution mentioned in https://github.com/flatpak/flatpak-builder/issues/5
didn't do the trick.
So using https://stackoverflow.com/questions/6301003/stopping-setup-py-from-installing-as-egg/27175492#27175492
as a trick to install the dependencies without the egg part
To start tuhi-kete:
$> flatpak run --command=tuhi-kete org.freedesktop.tuhi
Note that currently the fetched files are not available outside of the
sandbox
Related to #62
"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
flatpak-builder can produce an app by calling:
$> flatpak-builder --force-clean flatpak-tuhi \
org.freedesktop.tuhi.json
and it can run it through:
$> flatpak-builder --run flatpak-tuhi org.freedesktop.tuhi.json tuhi
The install with a local repo would be:
$> flatpak-builder --repo=repo --force-clean flatpak-tuhi \
org.freedesktop.tuhi.json
$> flatpak --user remote-add --no-gpg-verify --if-not-exists \
tuhi-repo repo
$> flatpak --user install tuhi-repo org.freedesktop.tuhi
$> flatpak org.freedesktop.tuhi
Fixes#31
Peter Hutterer