It’s becoming increasingly clear that it would be nice to be able to control Kaylee through some IPC mechanism. This first came up in #12 when thinking about how to give external programs the ability to tell Kaylee to speak. The solution I decided on there is to make a D-Bus method to tell Kaylee to speak a string, implicitly doing other things like pausing the recognizer while speaking.
This got me thinking about what else should be controlled by D-Bus. My conclusion was that I should create a D-Bus interface to Kaylee that’s flexible enough to allow the current GUIs to be rewritten to run as separate processes. With this done, it will also be a good idea to make Kaylee activatable by D-Bus, so running a GUI can start the daemon. This apparently can be achieved by more fun with systemd, which is the approach I plan to take.
It's becoming increasingly clear that it would be nice to be able to control Kaylee through some IPC mechanism. This first came up in #12 when thinking about how to give external programs the ability to tell Kaylee to speak. The solution I decided on there is to make a D-Bus method to tell Kaylee to speak a string, implicitly doing other things like pausing the recognizer while speaking.
This got me thinking about what else should be controlled by D-Bus. My conclusion was that I should create a D-Bus interface to Kaylee that's flexible enough to allow the current GUIs to be rewritten to run as separate processes. With this done, it will also be a good idea to make Kaylee activatable by D-Bus, so running a GUI can start the daemon. This apparently can be achieved by more fun with systemd, which is the approach I plan to take.
To make the D-Bus interface able to implement the current UIs, it needs to have methods for listen, continuous_listen, stop, and quit. I really don’t want quit to work if the daemon was run separately from the interface, though. I’ll need some way for the daemon to know it was activated by D-Bus, which I think should be doable by a secret command-line argument. The daemon will then need to know when it has no more clients connected to it so that it can shut itself down. I don’t know if there’s a better way for this to be done with D-Bus, but worst case I could make another method each client calls when it starts so the daemon can count them.
To make the D-Bus interface able to implement the current UIs, it needs to have methods for `listen`, `continuous_listen`, `stop`, and `quit`. I really don't want `quit` to work if the daemon was run separately from the interface, though. I'll need some way for the daemon to know it was activated by D-Bus, which I think should be doable by a secret command-line argument. The daemon will then need to know when it has no more clients connected to it so that it can shut itself down. I don't know if there's a better way for this to be done with D-Bus, but worst case I could make another method each client calls when it starts so the daemon can count them.
It’s becoming increasingly clear that it would be nice to be able to control Kaylee through some IPC mechanism. This first came up in #12 when thinking about how to give external programs the ability to tell Kaylee to speak. The solution I decided on there is to make a D-Bus method to tell Kaylee to speak a string, implicitly doing other things like pausing the recognizer while speaking.
This got me thinking about what else should be controlled by D-Bus. My conclusion was that I should create a D-Bus interface to Kaylee that’s flexible enough to allow the current GUIs to be rewritten to run as separate processes. With this done, it will also be a good idea to make Kaylee activatable by D-Bus, so running a GUI can start the daemon. This apparently can be achieved by more fun with systemd, which is the approach I plan to take.
To make the D-Bus interface able to implement the current UIs, it needs to have methods for
listen
,continuous_listen
,stop
, andquit
. I really don’t wantquit
to work if the daemon was run separately from the interface, though. I’ll need some way for the daemon to know it was activated by D-Bus, which I think should be doable by a secret command-line argument. The daemon will then need to know when it has no more clients connected to it so that it can shut itself down. I don’t know if there’s a better way for this to be done with D-Bus, but worst case I could make another method each client calls when it starts so the daemon can count them.