Drop pycairo by way of an environment variable, because we don't need it for
tuhi.
The way pygobject is setup it checks for setuptools during pip3 and then
complains that it's not there:
Collecting setuptools
Could not find a version that satisfies the requirement setuptools (from versions: )
No matching distribution found for setuptools
It's not actually needed since it has a fallback, but clearly... anyway.
Let's use the plain setup.py invocation, but with the right --prefix.
Of course that setup.py invocation doesn't work for the other packages,
so let's leave pip3 in place for those. Because how much worse would the world
be if this would just work...
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This one now includes Python 3.7, so we don't need to do it build it
ourselves. Fix the kete path up for 3.7 as well so this works again.
And finally, fix the pip incovations, the current ones we have install into
/usr/ which is read-only. Use the pip3 command generated by the
flatpak-pip-generator as listed on http://docs.flatpak.org/en/latest/python.html
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
tuhi/drawing.py:46: PyGIDeprecationWarning: GObject.property is deprecated;
use GObject.Property instead
@GObject.property
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
No need to get triggered by BlueZDeviceManager when it finds any GATT
characteristic. The BlueZDevice just needs its 'ServicesResolved' and
can resolve the GATT characteristics itself.
This solves a FIXME.
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
The object list returned by object managers get_objects() function is
not sorted. Though, we rely on objects being sorted by their object
path.
Replace the object managers get_objects() function with a variant
fixing that. Additionally, our variant makes it possible to filter
the returned object list by object path and interface.
Examples:
- get_objects():
/
/org/bluez
/org/bluez/hci0
/org/bluez/hci0/dev_00_00_00_00_00_00
/org/bluez/hci0/dev_00_00_00_00_00_00/service0000
/org/bluez/hci0/dev_00_00_00_00_00_00/service0000/char0000
/org/bluez/hci0/dev_00_00_00_00_00_00/service1111
/org/bluez/hci0/dev_00_00_00_00_00_00/service1111/char1111
/org/bluez/hci0/dev_FF_FF_FF_FF_FF_FF
/org/bluez/hci0/dev_FF_FF_FF_FF_FF_FF/serviceffff
/org/bluez/hci0/dev_FF_FF_FF_FF_FF_FF/serviceffff/charffff
- get_objects(interface='org.bluez.Adapter1'):
/org/bluez/hci0
- get_objects(interface='org.bluez.GattCharacteristic1'
base_path='/org/bluez/hci0/dev_00_00_00_00_00_00'):
/org/bluez/hci0/dev_00_00_00_00_00_00/service0000/char0000
/org/bluez/hci0/dev_00_00_00_00_00_00/service1111/char1111
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
b3 01 00 seems to be a generic "I'm happy" and the few others we've seen
are errors. So let's encode that and reconsider if it turns out to be false.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When starting from within the git directory, always use verbose mode. Because
you're debugging it, otherwise you wouldn't start from git.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
>$ flake8 --ignore=E501,W504 tools
tools/kete.py:35:1: E302 expected 2 blank lines, found 1
tools/kete.py:553:12: E713 test for membership should be 'not in'
tools/kete.py:599:42: E226 missing whitespace around arithmetic operator
tools/kete.py:599:61: E226 missing whitespace around arithmetic operator
tools/kete.py:615:25: E226 missing whitespace around arithmetic operator
tools/kete.py:615:32: E226 missing whitespace around arithmetic operator
tools/kete.py:624:49: E225 missing whitespace around operator
tools/kete.py:871:9: F841 local variable 'e' is assigned to but never used
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...)
Peter Hutterer