teach aenea about micState

[grahamc]

Adding the following Python code to a NatLink macro module allows for the host to receive notifications about the microphone state.

import aenea
import natlink

# Notify on change
def changeCallback(cbType, args):
    if cbType == 'mic':
        ProxyNotification("dragon mic: %s" % args).execute()
        aenea.communications.server.micState(args)

# Send the current state on startup
aenea.communications.server.micState(natlink.getMicState())

Dbus integration can be used with a simple Python3 program as follows:

import dbus
import dbus.service

from dbus.mainloop.glib import DBusGMainLoop
DBusGMainLoop(set_as_default=True)
import gi
from gi.repository import GLib
from pprint import pprint

def state_handler(state):
    global mic_state
    state = str(state)
    if state in ['on', 'sleeping', 'off', 'disabled']:
        print("microphone is: %s" % state)
    else:
        print("microphone is mysteriously: %s" % state)

loop = GLib.MainLoop()

bus = dbus.SessionBus()

bus.add_signal_receiver(state_handler,
                        dbus_interface='dictationtoolbox.aenea',
                        signal_name='microphonestate')

loop.run()

[calmofthestorm]

Hmmmm...I can see how this could be useful, but I'm concerned about adding a default dependency on DBus (I appreciate doing it on the CLI program rather than the libraries).

In the past, I've run into problems where DBus not running or glitching can cause programs which hard depend on it to freeze (due to the synchronous call to it) or refuse to start. My understanding is that DBus has become considerably more baked into the linux desktop in the past few years, so it's possible that it's no longer worth worrying about this.

One option would be to just merge it, and worry about issues when/if someone complains, if DBus integration is the future and we can count on distros to make it work properly. I've not had any serious issues with it in years.

Another would be to implement some form of graceful failure handling -- send the DBus command async for example, and only run one at a time. Another would be to implement a timeout, and if it's ever exceeded disable the DBus integration for the duration of the server (with a warning). Or we could simply add a config knob, default on or off.

What do you think? I'm open to being convinced DBus is fine here, and again, I do appreciate doing it by shelling out to the CLI rather than adding hard Python deps to Aenea itself.

[calmofthestorm]

Closing this out since it's been idle awhile. I'm open to considering this, but have some concerns about dbus dependence I'd want to discuss. I'm aware it ships on almost every system and thus "dbus is not installed at all" is rather unusual, but given how often I've had issues with programs that took a hard dependency on it breaking I'd want to have a graceful fallback.