we already are keeping a record of the x,y and p. So we are trying
to duplicate the effort by using new_rel.
The problem is that some reports have relative coordinates but absolute
pressure data. Which means we are missing the pressure change as it has
a relative value of 0.
By trusting the wacom internal state, we can have the json data that
matches it completely.
This is a first implementation of variable stroke pressure. It is based
on a set of individual-width-variable strokes. The ideal implementation
should convert the variable-stroke-width path into an outlined shape.
fixes e4e0a3b ("kete: rename the script from tuhi-kete.py to kete.py")
When renaming tuhi-kete into kete, we forgot to also update
tuhi-kete-sandboxed.py.
xdg is declaring itself as pyxdg.
Detected when installing through flatpak. It tries installing 'xdg'
through pip while we already manually installed it:
Processing dependencies for tuhi==0.1
Searching for xdg
Reading https://pypi.python.org/simple/xdg/
Download error on https://pypi.python.org/simple/xdg/: [Errno -3] Temporary failure in name resolution -- Some packages may not be found!
Couldn't find index page for 'xdg' (maybe misspelled?)
Scanning index of all packages (this may take a while)
Reading https://pypi.python.org/simple/
Download error on https://pypi.python.org/simple/: [Errno -3] Temporary failure in name resolution -- Some packages may not be found!
No local packages or working download links found for xdg
error: Could not find suitable distribution for Requirement.parse('xdg')
Error: module tuhi: Child process exited with code 1
Turns out this is not the gi.repository but a different package:
'Command line to private gist. Example: gi.py myFile'
It's incompatible with python3 and fails on import and seems to conflict with
gi.repository (also, the upstream seems dead).
Fixes#103
We need python 3.6 but old Ubuntus only have 3.5. 3.6 can be installed (and
thus we get past the 3.6 sys.version check), but the gi.repository backports
are in various states of disarray (see #103 and #104).
And Python (and in particular gi) makes it hard for users to distinguish
between "the dependencies are a mess" and "this is a bug in tuhi".
So let's catch any error during gi.repository import and print a warning to
the user, in the hope of getting less bugs caused by Ubuntu frankenpythons.
Still won't fix issues like #104, but I'm not sure how to test for those
errors.
Related to #103
Export the supported versions in a Manager property and require the client to
request a specific version in GetJSONData. Without that, the server could
never update the format and clients would have to support every single
historical version to make sure they can run against any version server.
Fixes#98
Because we're totally going to ship tuhi in embedded devices that are going to
be in use until after 2038 when time resets to zero, the world goes big bang
and the only survivers will be 64-bit species. Or something like that. Either
way, the API documentation already said so anyway and the DrawingsAvailable
property is already 64 bit too.
Semi-confusingly: the dbus 64 bit unsigned type is 't', it doesn't stand for
'timestamp'.
It can easily take more than 5 seconds when reading the data. The current
timeout just cuts the connection while it is still reading.
We *could* just remove the timeout here as the device will gracefully
send us a 0xc8 opcode with a blank CRC if we shut the device down while
retrieving the data.
However, better being on the safe side and keep a timeout, but restart it
if we are still getting pen data during the timeout.
Fixes#91
When using the live mode on the Slate, the bloc note actually hampers
the pen and prevents it to address all of the pixels on the screen.
Add some artificial boundaries that roughly match the primary design
of the device.
The Intuos Pro has a clip where you put a regular sheet of paper, so there
is no point restraining the active surface.
Fixes#88
For data packets other than basic motion/pressure strokes, add a PacketHandler
that can deal with that particular packet. Those handlers are part of the
class declaration, when we instantiate a protocol we pull them all into a
packet_handlers list and go through them. The first one to return True is
considered the right handler and we expect something has been done with the
packet.
This patch includes the handlers for the end-of-stroke and end-of-sequence
packets, the rest to be added later.
Instad of carrying around a lot of parameters, move this into a class with
properties. Eventually we can subclass that one for the special opcodes (or
something...)
Makes end-of-stroke handling easier, we can call seal() on the current stroke
and it'll make drawing.current_stroke() None, which is something we can deal
with.
Now that we got the basics running and reliable, this debug message is mostly
just noise, especially when in an office with lots of bluetooth devices
around. Comment it out, to be enabled when necessary.
On the Intuos Pro at least we sometimes get events that are all relative at
first and it can take several events for us to have all three values as
absolute. This is likely a parsing error on our side, but meanwhile don't
write the data until we have at least one known value for all three axes.
And because the SVG writer isn't happy with empty strokes, add a seal()
function to the drawing to purge empty strokes.
Fixed#92 or at least works around it
The prefix (4 bytes on the spark/slate) is some data that we don't know yet.
It *could* be the size of a tablet/drawing in LE byte order: 14434x29794
although that doesn't quite match the Intuos Pro data where the prefix is
different.
Either way, having this be an opcode of 0x3800 was probably just coincidence.
Let's skip over the header normally and assume that once we have a prefix, we
have a drawing. This opcode never occurs a second time within the same
drawing.
The Intuos Pro has a different prefix, we'll need to override this. Dropping
the comment about the 8bt, on the intuos pro the prefix is nonsensical so
let's not leave a false lead there.
On the Spark, the 0xc9 CRC comes almost immediately after the 0xc8
end-of-sequence. This causes a race condition where sometimes we process the
0xc8 before the 0xc9 arrives, other times the 0xc9 overwrites the current
nordic_answer value before we get to it - triggering an unexpected opcode
exception.
Fix this by appending the nordic answer and only ever pulling off enough to
satisfy the current request.
Fixes#90
Benjamin Tissoires