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.
Again, very rudimentary but we're planning on making kete a bit better anyway.
Also note that this doesn't make use of the tuhi.drawing module on purpose,
parsing the format twice avoids some bugs and also keeps tuhi-kete separate
from the tuhi daemon.
Part of #7
As we're planning to cache the data locally, the timestamps are a
unique-enough way that makes it possible to access a specific drawing.
And this way we can also delete some drawings without all other indices
shifting around.
Fixes#16
If we're losing the bus name (i.e. we can't get it on startup) there really
isn't much we can do other than fail miserably. But in passing signals around
we can't do exceptions, so we have to move the mainloop to Tuhi so we can
quit() it on error.
Fixes#25
Basically copied from the device's Listening approach.
While it's possible to have multiple clients searching at the same time it's a
niche case and the effort at fixing the race conditions that come from that is
likely not worth the effort.
Let's add multiple simultaneous clients when we have a real need for it.
TuhDevice.paired is set on every device update (RSSI changes!) and that sends
a GObject.notify() for the property. Filter those, otherwise
we're just spamming dbus with PropertiesChanged notify events even
though nothing has actually changed.
Peter Hutterer