We were re-using the header byte of the stroke header to count the bits.
Where that header is anything but 0xff we got out of sync and raised an
error. Fix this by renaming things so we don't accidentally use the
wrong fields.
Fixes#283
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This one hooks into the correct portal APIs, hopefully fixing the issue with
the Flatpak version not saving files correctly.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
pack_end, introduced in 29761204a9 means they
align to the bottom of the window. Where there aren't enough drawings to fill
the window, everything is bottom aligned. Hack around this by adding an empty
label to the bottom that expands to the maximum available size and stop
expanding the rest. This new label thus pushes everything up to the top
position.
Fixes 29761204a9
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The first drawings we load are from disk. If we sync a drawing from the device
with a different key (i.e. created in a different month), the new flowbox for
that drawing was appended to the list and in last place. This caused
out-of-order sorting (though a restart of Tuhi would fix it).
So simply change the behavior to sort by oldest timestamp first and pack_end()
for all of them. If we pack all our flowboxes with pack_end, they are
effectively in reverse order, i.e. last one added is first in the list.
Fixes#244
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If the device name is longer than one reply, the registration will crash.
This adds support for a variable number of replies until the reply ends
with `0x0a`.
This is a workaround for registering problems with Spark.
The registration hangs at "Connecting to device...".
Internally the `GENERAL_ERROR` occurs, which is expected
when registering a Spark device, but this should also
raise an AuthorizeException, but it instead reaches the
handler as DeviceError.
It is currently unclear why the `GENERAL_ERROR` passes to
this handler, so this catches any `GENERAL_ERROR` while
registering a Spark device.
There's just no point to that and if the tablet is currently in live mode, it
refuses the GET_WIDTH request anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We have a dbus property for this so let's just use that as a backend for our
live property instead of emulating our own on top of it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
0xb3 is the generic error code (or success, where applicable). Let's handle
those by default so that the rest of the messages only have to care about
replies with message-specific opcodes.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Add a new main() there so we have a single entry point for the gui instead of
a complex script that needs to be called. That start up script should really
just be the minimum bits possible.
It's still not perfect because we won't work without the gresources and they
require that the pkgdatadir is set. But at least it moves all the logic out of
the startup script.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We have implied inclusion orders here, specifically with gi. This works as
long as the files are included in the right order from other files but its not
generic enough - we really do need the gi.require_version() bit
everywhere to avoid issues.
Of course, once we do this flake8 complains about everything so let's
reshuffle things in an order it's happy with. This seems to be local modules
first, then ... whatever except when not?
application.py is excluded from this patch because it's about to get changed
in the next one and I'm too lazy to separate those out.
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>
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>
Martin Owens