Wiican Road Map (DRAFT)
Here it's revealed the current Wiican roadmap. There's no priority about which items will be finished first. If you feel you could contribute improving Wiican this way or with fresh ideas don't hesitate and talk with us at the wiican mailing list.
The true posibilities of Wiican are increased each time a user creates and shares a mapping for a new particular use. One way to attract potential "mappers" follows the rule of the social web: let the people participate creating and sharing mappings and set some incentives.
This is the proposal:
- Web mapping-repository where user could upload their .wii mapping package files
- Good indexing and tagging of mappings for easy searching
- Top downloaded and top rated filters
- Users could post comments about the mapping
- The web repository could be browsed into the Wiican mapping manager UI and the mappings could be transparently downloaded and imported into the user mapping catalog.
- Users could upload their mappings directly from Wiican mapping manager UI
Wiican aims to provide user and developer documentation. The user documentation will show the basis on using wiican and how to create mappings easily: tutorials, templates, examples. The developer documentation will describe the wiican dbus service and mapping manager modules for making it easier to understand for newcomer developers.
Gnome 3.0 comes with significant changes third apps are called to follow. In order to make of wiican a good gnome3.0 citizen some adaptations needs to be developed.
Wiimote status detection relies on HAL. Wiican listen the DeviceAdded and DeviceRemoved HAL signals and seeks for the input.product='Nintendo Wiimote'. Wiican uses wminput (the cwiid wiimote event driver) as backend, and wminput is responsible for set the input.product property as 'Nintendo Wiimote'.
The 'halsectomy' could be maybe performed by replacing the current code by using udev/devicekit or bluetooth directly.
Port PyGTK to the new introspection-based bindings
Porting to PyGObject dinamyc python bindings will gain all the new advantages for developers. Wiican isolates all the PyGTK GUI in the wiican.ui package so the first work will be to follow the IntrospectionPorting guide.
Migrate to GSettings
Wiican relies on gconf nowadays. In order for Wiican to become a gnome3.0 citizen, migration to gsettings is needed.
User friendly mapping editor
Nowadays the user needs to know the underlying wminput mapping language. Following one of the main goals of Wiican: to make easier for users to create their own mappings, the current mapping editor needs to be remodeled. Some ideas about:
- A template-based wizard: answering some questions about the required use for the mapping, the editor it's filled with a template the user needs to finish.
- WYSWYG editor: in a 'press any key for bind' basis, the UI shows a set of controls allowing the user to create the mapping.
Wiican for turning wiimote as MIDI instrument
By mapping the wiimote events to MIDI messages the wii-controllers could be used as musical instruments. The project wiimidi aims to develop a wiimote events midi messages driver that could be used as an alternative backend in Wiican.
Wiican for assistive technology
Wiimote could be seen as a cheap and easy to find alternative input device for people with physical disabilities. By mapping wiimote events to ATK actions the wii-controllers sets a fine tunned input-console for managing desktop and applications.
As JoanmarieDiggs suggested this could be performed in a 3-tier development:
- Auto-load maps based on the app with focus: by listening AT-SPI window:activate signal.
Map Wiimote keys to perform the action associated with a specific widget: should be able to do so via AT-SPI, looking at the name and role of AtkObjects and then either doing the associated AtkAction or alternatively getting the extents via AtkComponent and synthesizing a mouse click.
Map wiimote-events to execute a macro: a single wiimote-event activating a series of AtkAction. Maybe the Macaroon Accercisier component will help.