Better keep this in a public place where it won't vanish from our disks.
Note that this is a python 2 script (because btsnoop), and it should not
be part of the installation, ever.
Tuhi is not a permanent storage for drawings, this needs to be handled by the
client(s). To make sure no-one is tempted to use it as permanent storage,
always delete all but the last 10 drawings on startup.
Fixes#45
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.
Tuhi raise -EACCES if the UUID stored is not valid anymore.
Instead of shouting some obscure error, we should notify the
user that a pairing need to happen or the device will not talk
to us.
Also fix a small sign mistake in calling os.strerror() for general
errors
Fixes#6
workaround for cumberness of having to type timestamps.
Instead of having some fancy formatted timestamp, help the user
by displaying the translated value
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
We are using argparse in the various prompt function that already
provide a NameSpace class. We can just reuse it instead of rebuilding
everything.
Given that we enforce/parse the type of the arguments, there is no
need to do more processing.
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?)
Modified version from
https://stackoverflow.com/questions/384076/how-can-i-color-python-logging-output
Modifications (from that post) include:
* make flake8 happy by removing whitespaces and whatnot
* move everything into a class
* add the LIGHT_* colors
* remove the magic 30+ offset, assign the real color codes instead
* remove the $BG feature, we don't need background colors
fix ca82af78de ("tuhi: handle cold-plugged devices").
The point of deciding whether a device was in the pairing mode was actually
ignored when building the list of available devices.
Errors that occur during shutdown because one of the things hasn't been set up
in the expected way do not matter. For the shell we still require a manual
user exit though.
File "./tools/tuhi-kete.py", line 344, in stop
self.manager.disconnect(self.s1)
AttributeError: 'Searcher' object has no attribute 's1'
File "./tools/tuhi-kete.py", line 267, in _on_name_vanished
self.mainloop.quit()
AttributeError: 'NoneType' object has no attribute 'quit'
If a log message comes in the background, it will clear the current
command.
Rewrite the current line buffer from readline so we get more user
friendly.
We overwrite the current formatter to display or not
the prompt depending if we are in the prompt or not.
To prevent races between the background events and our
current configuration, we acquire/release the lock on
the current handler.
Only list and listen commands are currently implemented.
The Ctrl-C handling has been a little bit tricky. The default GLib
mainloop tends to add its own SIGINT handler, which prevents us to
gracefully handle the KeyboardInterrupt exception during cmdloop().
So we need to create the mainloop in TuhiKeteShellWorker directly,
but bypassing the GLib.Mainloop() python facility.
For the various commands, it is easier if we have a common interface
than just a simple function call.
Each current command runs something before the mainloop is created, and
then something after the mainloop is terminated. Having such a worker
allows us to have only one place where we start the mainloop, meaning
that the interactive prompt will not try to start it more than once,
and most above, will not kill it in the middle of a command while other
commands are still running.
Benjamin Tissoires