Biweekly report #2

June 19, 2012

Weeks #3 and #4 have flown past, and again more could have been done. Student finals are currently getting in the way of productivity. Studying is no fun when you could be spending the time on a really cool project, and unfortunately I have a few more exams in the next two weeks, meaning I won’t be able to commit much more time to getting things done compared to these last two weeks.

Shifting priorities

It’s because of that I’ve decided to shuffle the expected timeline a bit, focusing for the next two weeks on getting the Gamepad API support finally landed in WebKit and implement the GNOME Settings Daemon plugin for storing the configured gamepad data. The GNOME System Settings panel will have to wait a bit, but hopefully I’ll still make some progress on its design in the next two weeks.

Review of the last two weeks

Patch for adding Gamepad API support was updated and now requires only some minor details to be polished before it can be landed.

Basic infrastructure implementations for the GNOME Settings Daemon plugin and GNOME System Settings panel have been created. Currently, the implementations are based on the ‘gnome-3-4’ branches – this makes it simple for pretty much anyone with the latest stable GNOME system to try them out. It also aids me as I don’t have to deal with the mess that can result when using JHBuild. This is of course just temporary, the implementations will move onto a 3.6 codebase once there are some decent GNOME 3.5 releases (I’m currently bound to Ubuntu and therefor would wait for some later 12.10 Alpha releases). Again, this is simply just to avoid the JHBuild – both Settings Daemon and System Settings (the Control Center) are large enough projects to require some extraordinary dependencies, making a successful compilation a matter of luck.

Both repositories are available on GitHub – GNOME Settings Daemon and GNOME System Settings.


Biweekly report #1

June 4, 2012

Yesterday marked the end of the first two weeks of working on the project. A notable progress has been made, but still not as much as I had hoped.

The focus of this two-week period was adding Gamepad API support to WebKitGTK+. The bug entry (at covering adding the support holds the current work-in-progress patch. The patch already contains a working implementation, it just needs polishing (mostly in the approach this implementation is done infrastructure-wise), with each version going through a thorough review by my mentor, Carlos. Each WIP patch contains the complete implementation, but the bug is still marked as depending on two more bugs – one is enhancing the build rules to include the necessary files while the other is working on properly handling WebIDL types required by the Gamepad API specification. Both bugs are near of being resolved so I hope they won’t hold up landing the feature support once it is complete and reviewed.

To test the current implementation I went on and created a small HTML app that displays the current gamepads connected and button and axis events currently being fired as the device is interacted with. The app is called ‘Gamepads, Gamepads Everywhere’ (meme) and its source code is freely available on GitHub.

Just as a side note, Carlos (the mentor) tested the implementation himself and notified me about an interesting problem he encountered when using the DualShock 3 controller. The DualShock device also has motion sensing capability, sensing motions of the device on 6 axes. Funny enough, the Linux driver reports these axes in the same way the axes for analog sticks and the D-Pad are reported. Some might think the usual ‘It’s not a bug, it’s a feature’, but I’m not, honestly. The specification doesn’t currently cover such axes, and this is causing Chromium to ship an implementation that overrides this driver behavior by using hardcoded mappings for specific devices. I’m planning to acquire the device (possibly with the Xbox controller as well) to test this out.

While working on the Gamepad API support in WebKitGTK+, the design process of the GNOME System Settings panel has fallen behind a bit. I’ve sketched some ideas about how the panel might look like and how the configuration process might work, but all that is still in paper form. The panel proposal is more or less finished and I’ll be seeking for some opinion as well as advice about the panel implementation and design approach from the senior GNOME designers. Because of that the focus for the next two weeks will be to get the design far ahead of the current state and to put the basics of the panel into a public place for the interested to try it out. Along the way the support in WebKitGTK+ will hopefully be complete and perhaps landed in the source repository.