Finally, some sort of built-in TTS support. When a plugin emits a "tts"
signal, the Kaylee object will receive it and speak the given text
aloud. It even stops listening while it speaks to prevent Kaylee from
talking to herself. If no TTS is configured, it will print the text
instead, but since a default TTS setting is provided in the new
options.json.tmp, that shouldn't happen much.
Currently there's no way for the shell plugin to use TTS. The D-Bus
interface will change that once I get around to making it. Speaking of
D-Bus, UIs are broken again and I'm sure I can fix them once they're
separate processes talking to Kaylee by D-Bus.
After listening to HPR 1284 today, I realized that it's important to
keep configuration of what Kaylee *does* separate from other
configuration. Specifically, once TTS integration is done, voice
configuration will need to be separate from configuration of actions,
because it's common to have several computers with the same actions but
different voices. Therefore, I've moved all configuration about plugins
into a new file called plugins.json.
As part of the effort for resolving #12, I've started work on a plugin
API for Kaylee. While very much a work in progress, it will allow
Python plugins to be written, loaded from user configuration, and
hooked in to events from necessary portions of Kaylee to handle voice
commands.
Currently there is only one plugin, a partial implementation of shell
command support as existed previously. It works in that it executes
commands, but several old features are missing. Also, the GUIs are
probably broken, but I'm not worried about that at the moment.
Mostly working for the options file now. Still some difficulty with
command-line arguments, though; they're overriding the config file even
when not specified. If I made them simply not get stored at all when
not specified, there would be further problems when a configuration file
is not present. Maybe I should make a whole new class to handle this.
Clara Hobbs