Fold register_connection into register_device and (with comments) handle the
spark and slate here. This makes it easier to handle the Intuos Pro paper
later.
During the first attempt to register, we might not know before hand
the protocol of the device. Have a special class for it, and then
instantiate the correct protocol before continuing.
This makes the 'Protocol' entry in the config file mandatory
The Slate is more recent than the Spark. We better have the Spark as a
base class that we will never touch again and make the Slate depend on it.
When adding the Intuos Paper, we should make it a subclass of the Slate,
as the 2 protocols are similar.
The Intuos Pro Paper is close enough to the Slate but with some
subtleties. Instead of having a bunch of ifs, let's have nice subclasses
for the differences in the protocol.
We are already handling 2 protocols, one for the Spark, and one for
the Slate. That's one too many, and given that there are some subtleties
in the Intuos Pro Paper (see #56), we better start splitting the protocol
from the interface, so we can have different protocols for different
devices instead of having a bunch of 'ifs'
This isn't something we need in the daemon, it depends too much on what the
client expects so let the client save this data and handle the rotation
accordingly.
Note that the sensor in Sparks and Slates is in landscape format, i.e. every
picture is 90 deg rotated from what you'd expect.
Fixes#33 (wontfix)
"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
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.
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
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?)
Make the uuid property a GObject.Property so we can listen to it. Notify about
the uuid change at the end of the pairing process, then write that value into
the device's config file.
Ignore any requests to sync the device while the previous sync is still
ongoing. This should be the exception anyway, we shouldn't get another
"connected" signal from the device while we're syncing.
tuhi/wacom.py:18:1: F401 'sys' imported but unused
tuhi/wacom.py:22:1: F401 'tuhi.dbusserver.TuhiDBusServer' imported but unused
tuhi/wacom.py:23:1: F401 'tuhi.ble.BlueZDeviceManager' imported but unused
tuhi/wacom.py:52:1: E302 expected 2 blank lines, found 1
tuhi/wacom.py:140:13: E126 continuation line over-indented for hanging indent
tuhi/wacom.py:141:17: E131 continuation line unaligned for hanging indent
tuhi/wacom.py:592:1: W391 blank line at end of file
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
It didn't make quite sense to have y before x, and with some inverted
x value. The sensors are designed in the landscape mode, and the rotation
needs to be determined in the software.
Implement an orientation parameter to WacomDevice so we always have
normal X and Y
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
It's better to have a full log on one line. However, flake8 now complains.
I am not that happy with this situation, we should figure out a way
to selectively disable the length check for logger messages only.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Peter Hutterer