Wiican riding dbus: first steps
I’ve started the programming of wiican running as dbus session service, and that’s the first snapshot (only for geeks, i’m afraid).
The goal is to give third apps the chance to configure and use wiimote for their own purposes. In recent dbus versions the dbus daemon could launch the wiican session service by demand, so there will be no need to run wiican before the apps could perform the wiimote association routine.
Under the Connect() method a wminput instance it’s raised, the third app can connect to StatusChanged() signal so it can track the wiimote association routine steps. The status it’s a combination of wiican status codes:
WC_DISABLED = 0
WC_BLUEZ_PRESENT = 1
WC_UINPUT_PRESENT = 2
WC_WIIMOTE_DISCOVERING = 4
So WC_BLUEZ_PRESENT | WC_UINPUT_PRESENT means that the system it’s able to run wminput, and WC_BLUEZ_PRESENT | WC_UINPUT_PRESENT | WC_WIIMOTE_DISCOVERING means that the wiimote it’s in use.
This interface it’s only a proof of concept but fully functional. If you want to test it, download the wiican_dbus.py and wminput.py files and remember to install wminput and manually load uinput module with 0666 perms.