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
In the normal mode (without -v) we'd see the errors, but not the messages when
we reconnect. Elevate the "connected to" message to info so it shows up.
And slight rewording, which may or may not be better.
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.
'list' and 'listen' are just too close to each other, meaning the
completion stops at 'list' while the lazy developer/tester want to
do a 'listen'.
Change the name of the less used command so we have separate spaces
for completion
Better keep this in a public place where it won't vanish from our disks.
Note that this is a python 2 script (because btsnoop), and it should not
be part of the installation, ever.
Peter Hutterer