Since most of the signals are propagated by the bindings we largely just need
to hook up simple methods to log what is happening.
One nasty hack: we import some of the bits into the kete namespace so
tuhi-live continues to work. This can be fixed up in a follow-up commit.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The first argument in any signal is the object that emits it, so we don't have
to add it again.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Both of the signals here are connect to the device, not Tuhi. The only reason
this worked was because the signal sent by the dbus bindings had the device
twice in the arguments and 'tuhi' was actually the device.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is used by the GUI and by kete and it's just an abstraction of the
handling anyway with little actual logic. Let's make this sharable.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This conflicts with trying to register the device on authentication errors and
making re-registration unreliable. Tuhi would keep connecting to the device
while holding the button down, so we'd get another failed connection and a
disconnect from the device. The Register signal would come in and get lost
somehow.
Fixes#195
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Check those modules that aren't part of the python installation and bail out
of meson where they're missing. This is technically wrong because we don't
need them at build-time and only at run-time but pragmatically sensible
because we waste too much time dealing with those bugs.
Fixes#200
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
flathub requires us to use specific versions, so let's do that here too so
we're consistent in testing.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This was the one that introduced the Gtk.Template class that we use. And
better to have a meaningful exit than a crash.
Fixes#197
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We used to drop all but the last 10 drawings on startup and as the comment
says so that users don't rely on tuhi for storage. That's mostly fine when
Tuhi is a separate daemon but now the primary interface is the GUI. So we can
run into this situation:
- user starts Tuhi (which in turn starts tuhi-gui and tuhi-server)
- tuhi-server downloads 20 fresh drawings from the device
- tuhi-gui crashes before it can fetch them from the tuhi-server
- restart Tuhi, the server now purges 10 out of those 20 drawings that the
user has never seen. They're gone for good.
Let's drop that code until we figure out a better solution to that (e.g. drop
drawings older than X months but that too is fraught with errors).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Previously, the YAML output was basically:
- send: [0xb9, 0x01, 0x00]
- recv: [0xba, 0x02, 0x44, 0x00]
using a context manager where replies are expeced we can now group the
replies in the yaml file:
with logger as _:
self.send_nordic_command(...)
self.wait_nordic_data(...)
And that will prodice a grouped entry in the YAML file:
- send: [0xb9, 0x01, 0x00]
recv: [0xba, 0x02, 0x44, 0x00]
Which means processing those becomes a bit easier.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Both handlers need to be set up to log at debug level, the logger itself will
filter correctly anyway where verbose isn't given. And we want them both to
log in the same format, so let's re-use the formatter.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The session id is a UUID, postfixed by an incrementing number. The UUID stays
the same for Tuhi's livetime, the number increments with every bluetooth
connect/disconnect. Result is e.g. 4e55c30035d043ce9f6f4914fb223820-2.
This session id is printed to the log file, added to the YAML raw logs and to
the JSON file, making it easier which log part resulted in which drawing, etc.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reproduced on the Spark, first bytes in a new file recording were
- file header: 0x62, 0x38, 0x62, 0x74
- stroke point: 0xbf, 0xff, 0xff, 0x4a, 0x14, 0x29, 0x31, 0x6a
- stroke delta: 0xa8, 0x02, 0x04, 0xc3,
The initial point thus has a delta pressure value 0x6a which must be added to
*something*. And zero is the most sensible *something* that I can think of.
Fixes#111
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Deprecated, but still exists on the Slate so let's wrap the connect attempt
so we throw the right error.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
It's caused by a timeout but the underlying issue is that we never got the
reply that we wanted.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Peter Hutterer