Wiican

It was hard, but the new mapping manager it’s fully funcional now!

As you can see, a new Import/Export buttons had been added. It means you could now share your mappings with your friends. Just export!: a tarball will be created containing the mapping info, the icon and the wminput mapping code itself.

That supposes a great change from wiican 0.2 series, where a mapping consist in one text file with wminput code and comments for info. Now a standard xdg DesktopEntry file saves the mapping info, so several languages could apply, and theme icons for mappings, and so on! Here an example file:

[Desktop Entry]
Name=Mouse
Name[es]=Ratón
Comment=Control mouse events with accelerometer and A+B buttons
Comment[es]=Controla eventos de ratón con acelerómetro y los botones A+B
Icon=gnome-mouse
X-Version=1.0
X-Authors=J. Félix Ontañón
Type=Wiican Mapping
Encoding=UTF-8

This is the mapping info file definition a mouse mapping. Translations for name and comment could be provided and the icon could take an absolute path, or even theme icon! This is how it looks in the new Mapping Editor dialog (Gnome human-interface-guide compliant):

Every field could be edited from the dialog.

I feel this mapping edition, creation and export/import facilities could make a community of wiican-mappers. In next versions i’ll try to provide a mapping repository, with links from WiiCan, so mappers could share and vote their mappings in a centralized site and new users will discover mappings for their apps.

Let’s take WiiCan to the web-social sphere!

By wiican revision 77 we have now a dbus session service that can run on demand when a client requires it. This still being a dbus api draft for wiican but fully functional as i’ve showed in yesterday post.

A full example as been commited, but let me expose some minor examples.

Behold! the most simple client example:

import dbus
 
if __name__ == '__main__':
    bus = dbus.SessionBus()
 
    wiican_iface = dbus.Interface(bus.get_object ('org.gnome.Wiican',
        '/org/gnome/Wiican'), 'org.gnome.Wiican')
 
    wiican_iface.ConnectWiimote('', False)
    print 'Press 1+2 to connect wiimote'

In wiican_iface we got the Wiican dbus service interface proxy so the ConnectWiimote method could be called. Behind, a wminput will be launched in a thread, in this case, the two args means no config_file (so default mapping will be loaded) and daemon-mode off.

# The status codes
from wiican.service import WC_BLUEZ_PRESENT, WC_UINPUT_PRESENT,
    WC_WIIMOTE_DISCOVERING
 
# Check the current wiimote connection status before trying to connect
cur_status = wiican_iface.GetStatus()
 
if not cur_status && WC_UINPUT_PRESENT:
    print 'Not uinput module present'
elif not cur_status & WC_BLUEZ_PRESENT:
    print 'Not bluetooth adapter present'
elif cur_status & WC_WIIMOTE_DISCOVERING:
    print 'Wiimote still in use!'

Here is a way to know the wiimote status on-demand. The status property contains a bitwise xor operation of the WC_* constants.

import gobject
from dbus.mainloop.glib import DBusGMainLoop
 
# A callback to receive wiimote connection status changes
def status_cb(new_status):
    # Only check if wiimote it's disconnected
    if not new_status & WC_WIIMOTE_DISCOVERING:
        print 'Wiimote its disconnected'
 
DBusGMainLoop(set_as_default=True)
 
wiican_iface.connect_to_signal('StatusChanged', status_cb,
    dbus_interface='org.gnome.Wiican')
 
gobject.MainLoop().run()

And finally you could be noticed of events about wiimote connection status by binding a callback function to the StatusChanged signal.

The dbus api still in hard development, so this examples can not be taked as final but a proof of concept. Maybe i’ll fill a blueprint describing it in Wiican Launchpad site.

Wiican dbus interface

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.

Hi everyone!

Was a long time since Wiican 0.2.1, other projects as CommieCC, Wiimidi and, recently Pluglib, catch my time. Now i’m watching to Wiican 0.3 hoping to take it to the new desktop standards:

• Get wiican riding the dbus
• Provide a way to launch wiican as service with no gui
• Integrate uinput module loading in new udev
• Support for several wiimotes at same time

Some people ask me for some features in launchpad, i think that the new approx will make it real. In next posts i’ll advance some development details.

Cheers!

Frets on Fire mapping for Wiican

gh