I am working on some code to allow dbus aware applications to make requests of Tux to read out messages, flap wings etc.
This would provide a single point of access to Tux, instead of having multiple scripts simultaneously try to do conflicting things.

Is anyone else working on anything similar?


//M

Is the tuxdaemon itself not supposed to handle conflicting things ?

If not, what is the point of having the daemon run ?

The tux daemon provides access to the USB device and the API.. but many python programs can instantiate a copy of Tux and try to send commands, with mixed results.  If the radio link drops then reconnects, which copy should get control?  I am not convinced that the event handlers for connect and disconnect work properly yet.

The other advantage of using dbus is it allows easy access to system notifications. For example, plugging in a USB device raises an event that could be used to trigger Tux to say something.  The Evolution mailreader also sends a notification.. unfortunately, it does not say which message is new only which folder has the new message.

I think this is an excellent idea!