July 17, 2012
Weeks #7 and #8 contained the mid-term evaluation, which I passed (yay!). This event also signaling the mid-point of the project, there are still changes in the approach of the gamepad configuration panel implementation in GNOME Control Center.
The current idea
Currently the design proposal suggests the user could reconfigure the device’s buttons and axes if he or she finds them incorrectly configured (mapped). The mappings would then be saved via GSettings and loaded every time the device would connect to the system. Ideally the user would be able to report to the GNOME Bugzilla that he or she had to go through the configuration process and add to that report the data about the device and its new configuration.
These configurations would then be stored in some kind of a device list that would group the devices based on their axes and buttons layout. If the user would connect an unrecognized device, he or she could search through the different types of devices to find a layout that would suit his or hers device and report that to the GNOME Bugzilla. That device would then be added to the appropriate layout group.
Axis calibration would also be available for those more advanced users.
‘Stupid configuration … WTH?! … That’s it, I’m done with this!’
That’s exactly what some user that’s not that deep into technology and gamepad reconfiguration might think when he or she is forced into something not only time-consuming, but also completely unnecessary.
The new idea is to maintain a list of ‘supported devices’, that is a list of all the axes and buttons mappings for devices that have been tested and should work out-of-the-box. These mappings would then be applied to corresponding devices when they are connected.
In the case of an unsupported device the proper mapping would be reported to the GNOME Bugzilla and the list of supported devices expanded (the first part still needs some planning and work). That would basically mean that no reconfiguration would be either required or available for any gamepad device. The axis calibration would still be possible.
TODO in the second half of the GSOC period
With the Gamepad API support in WebKitGTK+ pretty much complete (by the way, the 1.9.5 release is out and you can test the feature there), the only thing to do is the GNOME Control Center panel implementation. The GNOME Settings Daemon plugin might become redundant in implementing the current idea, but that’s still to see.
The design proposal will be updated and represented to the GNOME designers, hopefully discussed and started being implemented. I’ll try to do the implementation in the tip-of-tree (jhbuild here I come) instead of doing it in the 3.4 branch and the porting it forward.
July 4, 2012
Weeks #5 and #6 were quite fun and productive. Here’s what was happening.
Support for Gamepad API landed
The support for Gamepad API for the Gtk port has landed in WebKit. The feature is currently disabled at compile-time due to the specification still being a work in progress. This might change in the future if API for enabling experimental features at run-time is introduced for WebKitGTK+. Currently there’s no release version (stable or unstable) available that includes the support, but the next unstable release (1.9.5) will have it as well as the next stable release series. Build instructions for the impatient are found on the project’s page in the Wiki (will be updated soon).
GNOME Settings Daemon plugin almost done
The GNOME Settings Daemon plugin is pretty much finished. The code (available on GitHub) is based on the 3.4 branch and will go through a review by my mentor, Carlos, and will eventually be rebased on the master branch. The plugin’s task is to apply any previously saved configurations to the device on its connection. Currently the axes and buttons mappings are applied, but the axes calibration data will be applied as well (support for this will be added parallel with support in the Control Center panel). Currently saving the configuration data is only available through the command line, using the gsettings application’s capabilities. This is extremely hacky approach though, and not a pleasant user experience.
Next two weeks
The next two weeks will be mostly focused on implementing the panel in GNOME Control Center. The code is available on GitHub. Also in this timespan is the mid-term evaluation.