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.
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.
Tuhi raise -EACCES if the UUID stored is not valid anymore.
Instead of shouting some obscure error, we should notify the
user that a pairing need to happen or the device will not talk
to us.
Also fix a small sign mistake in calling os.strerror() for general
errors
Fixes#6
workaround for cumberness of having to type timestamps.
Instead of having some fancy formatted timestamp, help the user
by displaying the translated value
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
We are using argparse in the various prompt function that already
provide a NameSpace class. We can just reuse it instead of rebuilding
everything.
Given that we enforce/parse the type of the arguments, there is no
need to do more processing.
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?)
Peter Hutterer