Page heading

Summer of Code 2007 – RockBox Proposal

To develop a successful software product some goals must be reached. For instance, the source code should be clean, well organized and documented as much as needed to understand it. A very important point is also the user interface. It needs to be intuitive and good looking.

In this proposal I will present you my idea how to archive the goal of a nice looking user interface. A long time ago I had the idea of creating something like “skins” for Rockbox. The skins should describe (in XML) the way how meta-information should be drawn on the screen. The biggest drawback of this idea is the usage of XML. On the first look it seems to be the solution for the “skin”-project, but as we are working with embedded devices XML is not the best choice, because it can be slow and can use a lot of memory. So I thought about a nice idea how to solve this problem and worked out the following solution:

Compiled Skins for RockBox

The idea is to isolate the “rendering” of meta-information’s into a skin. For this we need to define a handful of interface – for every screen its own – and implement a basic RockBox skin. You may think now, that “skins” is a competitor or the current used wps. But I want to make use of wps in “skins”. So it is possible to easily change some Parts of the user interface without programming in C.

Lets have a look how “skins” could work in the radio screen.

I look like this at the moment (taken from http://download.rockbox.org/manual/rockbox-h300/rockbox-buildch5.html#x8-670005 - last viewed 27.02.2007)

So in this case the meta-information is:

• Station number and name
• Frequency of tuned station
• Mono/stereo
• Mode

Now the code in apps/recorder/radio.[ch] must work with some kind of skin manager, e.g.:

Struct screen_radio = g_skinMgr->getScreen(SCREEN_RADIO);

screen_radio.name = “SWR3”; screen_radio.number = 3; screen_radio.stereo = false; screen_radio.mode = SCREEN_RADIO_MODE_PRESET;

screen_radio.render();

NOTE: I have not defined any kind of software design for this proposal, as this will be work for SoC. The source part above shows no real code!

Now it’s the problem of the “skin” to do the rendering of the meta-information’s and not RockBox ones. We could apply this concept to every screen we render (main and remote). A skin could be something similar to a Codec or a Plug-in, which means that it could be loaded on-demand.

Things to do for the SoC

• Review every “rendering” process of RockBox
• Define interfaces (structs with function-pointers) for the user interface
• Begin writing a Proof-Of-Concept (maybe this should be done before SoC starts)
• Move currently used rendering code into an own skin called e.g. “RockBox”
• Try to create a eye candy skin to show some nice stuff

Comments

I would prefer to use a WPS-like language for rendering. Something that is interpreted by RockBox and doesn't require C knowledge. Plugins should also be able to define an interface, so that some rendering can be done even in plugins. -- TimoHorstschaefer - 27 Feb 2007

When a script language is needed, it's always worth to consider Lua. It's a rather powerful language whose purpose is to be included as an extension languages in other programs. It has a 100KB footprint, which is not too small (but not too high, maybe the parser can be extracted to a plugin). -- RaniHod - 27 Mar 2007